GIT WORKFLOWS / LESSON 05
Session Management.
Managing long-running development sessions

Loading the lesson…
Loading activities…
GIT WORKFLOWS / LESSON 05
Managing long-running development sessions

Loading the lesson…
Loading activities…
Real projects take time. Sometimes days, sometimes weeks. You work on something, close the laptop and come back later... and then what? How do you remember where you were, and how do you keep from losing the thread on what you were doing?
Good session management is just being organized enough that future-you can pick up exactly where past-you left off.
When you work on a project over a bunch of days, a lot slips through the cracks.
This is totally normal! Our brains are not great at holding a pile of details. That's exactly why we need systems.
Claude Code has a built-in way to pick up where you left off. When you start it up in a project, it can bring back your earlier conversations.
When you're done working, you don't have to do anything special. Just close Claude Code. Your conversation history saves automatically.
Next time you start Claude Code in the same project, use the resume flag.
That pulls up a list of your past conversations so you can pick the one you want, and then Claude remembers what you were working on.
If you just want the most recent conversation from this folder, skip the list.
Now you can jump right back in. Say something like "Let's continue working on the login feature" and Claude will have the context from before.
Claude's tools are only half of it. Here are some habits that keep you organized.
Before you stop for the day, spend two minutes writing these down.
Put the notes somewhere you'll actually see them. A comment in your code, a note in a TODO file, even a sticky note on your desk (low-tech counts).
Your Git commits are basically a diary of your project. Good commit messages help you remember what you did and why.
Bad commit message
Good commit message
Always commit your work before you end a session. Even if it's not finished, stage it and commit with a message like this one.
WIP stands for "Work In Progress." It tells future-you (or your teammates) that this isn't done yet.
Each branch should be about one thing. When you come back after a break, you can tell what you were doing just by checking your branch name.
Output like this tells you a LOT.
You can see you've got a few things going, and right now you're on the mobile login bugfix.
Bigger projects need some way to track what's left to do. Here are a couple simple approaches.
The simplest one is dropping TODO comments right in your code.
Most code editors highlight these. You can also search for them.
Make a TODO.md file in your project.
That gives you a quick overview the moment you come back to the project.
When you come back to a project, take a few minutes to get your bearings.
Read whatever notes you left yourself. What were you working on? What was the plan?
See what's changed since your last commit.
That shows your uncommitted changes and your most recent commits.
Which branch are you on? Is it the right one?
If you're using Claude Code, fire it back up.
Give Claude a quick summary of what you want to work on.
Sometimes you've got several projects going at once. Here's how to keep them straight.
Keep each project in its own folder. Sounds obvious, but it really helps.
When you're working on more than one project, use separate terminal windows or tabs. Label them with the project name if your terminal lets you.
Even inside one project, use branches to keep tasks apart.
You can hop between them as needed, and each one keeps its own history.
Sometimes you come back to a project and have NO idea what's going on. Here's how to get unstuck.
git log shows what you didclaude --resume to continue an earlier Claude Code conversationCongrats, you finished the Git Workflows module! Here's what you can do now.
These skills carry over to pretty much any project you'll ever touch. Next up is the Hosting module, where we look at why apps lean on outside services and then get your app live on the internet...