Session 12: Coach notes
Goal of this session
At the end of this session a ninja can:
- Explain what a branch is and why you would use one.
- Create a branch (
git branch/git switch -c), switch to it, and back tomaster. - Make commits on a branch without affecting
master. - Merge a branch into
masterwithgit merge. - Recognise and solve a simple merge conflict.
- Delete a superfluous branch with
git branch -d.
What is not expected: remote branches, pull requests, GitHub integration. Those come in sessions 13 to 15.
Preparation (30 min before the session)
- Set up a repo on the projector. Use the project from session 11 or make a demo repo with 2 to 3 commits on
master. You must be able to switch, branch and merge during the demo. - Prepare the merge conflict. The merge conflict demo (Step 5) is the hardest part. Walk through it yourself twice. You have to be able to explain the visual of
<<<<<<< HEADand=======clearly. - Terminal on the projector with a large font. CTRL+Plus just in case.
Schedule (3 hours)
| Time | Activity |
|---|---|
| 0:00 to 0:10 | Recap session 11: commits, log, status. What was it again? |
| 0:10 to 0:30 | Projector: what is a branch? Demo: making a branch, switching, seeing files disappear |
| 0:30 to 1:00 | On your own: creating a branch, adding files, switching, merging |
| 1:00 to 1:15 | Break |
| 1:15 to 1:45 | Projector: merge conflicts. What are they, what do they look like, how do you solve them? |
| 1:45 to 2:30 | On your own: creating and solving merge conflicts, cleaning up branches |
| 2:30 to 2:45 | Showcase: show your branches, log, and a solved conflict |
| 2:45 to 3:00 | Cliffhanger, take-home |
Common questions
“Why is the main branch called master?”
In our sessions the main branch is called master. That was the standard in Git for years. Since 2020 GitHub uses main by default, a more neutral word. Many new projects use main, older projects master. Same concept, different name. In this course we stick with master, but if you come across main online: that is exactly the same.
“Do I have to do every change on a separate branch?”
No. Small fixes (typos, comments) you can do directly on master. Branches are for things that need several commits or are risky.
“How do I know which branch I am on?”
git status shows it at the top. git branch shows all branches with an asterisk next to the active one. Make it a habit to check this before you start working, so you avoid writing code on the wrong branch.
“I lost commits after switching!” Your commits are not lost: they are on the other branch. Switch back and they are there again. This is exactly the point: branches isolate work from each other.
“Git says ‘Already up to date’ when merging”
That means there is nothing to merge, because the branch you are trying to merge has no new commits. Check with git log whether you did make commits on the right branch.
Explaining merge conflicts (visually)
This is the hardest concept of the session. Use an analogy:
“Suppose: you and your friend both write the same homework. You answered question 3 with ‘42’. Your friend wrote ‘37’. The teacher gets both versions and says: ‘I don’t know which is the right answer. You two have to work it out together.’
<<<<<<< HEADis your version.=======is the dividing line.>>>>>>> andere-branchis your friend’s version. Git says: ‘Here are both answers, pick one.’ You remove the markers and choose the right answer. Thengit addandgit commit, and done.”
Show the markers literally on the projector. It looks scary (<<<<<<<, >>>>>>>, =======) but it is just a choose-your-option menu.
Hints for Stretch and Expert
Stretch: git log --graph:
git log --graph --oneline --all shows a visual tree of your branches. Handy when you no longer remember how the branches fit together.
Expert: overriding a branch with git merge:
If you do git merge feature-branch while master has no new commits since the branch split off, Git does a fast-forward: it simply moves the master pointer to the last commit of the feature branch. No merge commit needed. If master does have new commits, Git creates a real merge commit.
Cliffhanger script
“Now you can have two versions of your code at the same time. But everything is still only on your laptop. Next time your code goes out into the big world. We make a GitHub account, put your repository online, and, coolest of all, we pull in code from other people. Your game. Online. For everyone.”
Why this session, now?
Session 11 gave ninjas one timeline. This session teaches them to split and merge. This is the core concept of Git: non-linear development.
Without branches:
- You don’t dare take risks with your code.
- Working together is impossible.
- You can’t go back to a previous version without losing your current work.
With branches:
- Experimenting is safe.
- You can work on several things at the same time.
- Working together becomes possible (sessions 13-15 build on this).