Teamwork with Git: branches and workflows
You practise working in one repository as a team: branch strategies, code review and keeping remotes tidy.
Level 201 · 17 lessons · 15 practice labs
Lessons
Branch strategies
- Why a team needs a branch strategy
- Trunk-based work and short-lived branches
- Feature, release and hotfix branches
- Branch naming and clean-up
- Short task: set up a branch layout for a small team
Kinds of merge
- Fast-forward and merge commits
- Squash merging
- Three-way merges and hard conflicts
- Faster conflicts with mergetool and rerere
- Short task: merge three branches and resolve their conflicts
The team and remotes
- fetch vs pull and tracking branches
- Several remotes: origin and upstream
- The fork and patch flow: format-patch, am
- Review-friendly commits and change descriptions
- Protecting main: rules and hooks
- Short task: send a patch to another repository and apply it
Wrap-up
- Capstone: prepare a release for a three-person team with branches
Practice labs
- Prune merged branches: Delete the local and remote branches already merged into main, leave unmerged ones alone, and show the result with git branch --merged and git branch -r.
- Branch names that break the convention: Rename Blue Harbour Cargo’s branches to the team’s feature/ and fix/ convention locally and on the remote, and prove with git branch -vv that tracking still works.
- A hotfix that never reached main: Find the fixes that went into the release branch but never came back to main, carry only the missing ones over and show no other fixes are missing between the two branches.
- A merge commit for every feature: Following the team rule, merge the feature branch into main with a merge commit instead of a fast-forward and show the branch is visible in git log --graph.
- Squash a noisy branch into one commit: Squash-merge a branch full of tiny commits into main as one well-described commit and show the branch can then be deleted safely.
- A branch that kept going after a squash: Move the branch that kept getting work after its squash merge onto main so only the new commits travel, and prove the old conflicts don’t come back on the next merge.
- Resolve a conflict with a merge tool: Configure a terminal merge tool for git mergetool, resolve the pending conflict with it and show no .orig files are left behind.
- The same conflict every time: Enable rerere, resolve the conflict on the long-lived branch once, undo and redo the merge, and prove the conflict resolves itself the second time.
- A moved folder and edited files: Merge Selvi Schools’ repository where one branch restructured the folders and the other edited files at the old paths, proving with the test script that every change reached the new paths.
- Sync a fork with upstream: Add the original repository as upstream to your fork, sync main with it, update your own remote and prove both remote branches point to the same commit.
- A patch series that doesn’t apply: Apply a patch series made against an older version with git am, finish the patches that stop on context drift using a three-way merge and show the authors are preserved.
- Branches tracking the wrong place: Fix branches pulling from the wrong place because their tracking settings mix origin and upstream, attach each to the right remote and report ahead/behind counts with git branch -vv.
- Block direct pushes to main: Write a pre-push hook that stops direct pushes to main and show with two attempts that pushing a feature branch still works.
- A ticket number is required: Write and test a commit-msg hook for Caravan Travel’s team that rejects commits without a ticket number but lets merge commits through.
- What slipped into main without review: Find commits that landed on main directly instead of through a merge by walking the first-parent history, list them with author and date and explain in a short note how the protection was bypassed.
About this course
You practise working in one repository as a team: branch strategies, code review and keeping remotes tidy.
What you will learn
- Branch strategies
- Kinds of merge
- The team and remotes
- Wrap-up
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run in your own Kali Linux terminal that opens in the browser. Nothing to install; the lab starts clean in every lesson.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.