You will make a side line of work, then bring it home, and see exactly what git does in each case.
You already know the big secret: a branch is not a copy of your project. It is a bookmark in your photo album. Making one costs nothing and changes nothing.
Here is the whole dance, start to finish:
git switch -c my-idea Switched to a new branch 'my-idea' # ...edit files, take a photo, edit more, take another photo... git switch main Switched to branch 'main' git merge my-idea
git switch -c my-idea. The -c means create. Old-timers say git checkout -b my-idea; it is the exact same move with an older word. To hop between existing bookmarks, it is just git switch main.While you sit on my-idea and commit, that blue bookmark slides forward with each new photo. The green main bookmark does not move. It is waiting for you, right where you left it.
One surprise the first time you see it: when you run git switch main, the files on your disk change to match that bookmark. Your experiment seems to vanish. It has not. Every photo you took on my-idea is safe in the album. Switch back and the files reappear, exactly as you left them. Committed work is almost impossible to lose.
Then git merge my-idea brings the side work into main. There are only two things that can happen next. Let us watch both, using real save points from your own project.
Picture this: you went off on a branch and took three photos. Meanwhile, main did nothing. Nobody added anything to it. Main is simply three save points behind you, on the very same straight string of beads.
So what does "merging" even need to do? Press play and find out. These are real save points from your own project.
Look at what did NOT happen. No new photo was taken. Your files on disk did update, just like when you switch bookmarks, but the album gained nothing new. The beads are the same beads. Git just slid a label along the string until it caught up. That is the gentlest merge there is.
Now the more interesting situation: while you were working on your branch, main ALSO grew. Maybe you fixed something quick on main, or a teammate did. Either way, the string of beads forked. Now there are two loose ends.
This is the real fork from your own project. Both lines grew out of 836f2de. Press play to tie them back together.
This time git really does take ONE new photo. That photo contains both sets of changes: the launch work from one strand and the fixes from the other. And look at its sticky note: it lists TWO previous photos as its parents, not one. The fork is tied back into a single line, and nothing from either side is lost.
One question is probably forming in your head: what if both sides edited the same line of the same file? Good question. Git will pause and ask YOU which version to keep. That is a conflict, and it is a question, not an error. Next lesson is all about answering it calmly.
Here is the nice part: you do not have to know. You type git merge either way, and git looks at the string of beads and picks for itself.
| What the history looks like | What git does |
|---|---|
| One straight line, main just fell behind | Slides the bookmark forward (fast-forward) |
| Two loose ends, both sides grew | Takes one new tying photo (merge commit) |
Either way, the command is the same and your work from both sides ends up in the album. There is no wrong button to press here.
Back to the playground from lesson 5. (If you deleted it, just redo the quick setup from lesson 5 first.) You will make a branch, commit on it, and merge it back.
cd /tmp/git-playground git switch -c add-greeting echo "hi there" >> notes.txt git add -A git commit -m "Add greeting" git switch main git merge add-greeting # watch the output closely... git log --oneline
This one is the bookmark-slide case: main never moved while you were away. Git even tells you so. Look for the word Fast-forward in the merge output. No new photo, just a label catching up.
Q. When is the bookmark-slide (fast-forward) merge impossible?
Think about it: why can the bookmark-slide merge never have a conflict?