Mastering Git
Prepared by: Leo Mutuku
Topics
01 The Perfect Commit
02 Branching Strategy
03 Pull Requests
04 Merge Conflicts
05 Merge vs Rebase
#1 The Perfect Commit
Add the right changes
❖ Create a commit that includes changes from a single topic
Compose a good commit message
❖ Subject → Concise summary of what happened
❖ Body → More detailed explanation
- What is now different than before?
- What is the reason for change?
- Is there anything to watch out for?
#2 Branching strategies
❖ Agree on a branching workflow in your team - A
written Convention.
❖ Integrating Changes & Structuring Releases
❖ Long-Running & Short-Lived Branches
❖ Branching strategies
❖ GitFlow & GitHubFlow
A Written Convention (Agree on a Branching
Workflow in Your Team)
❖ Git allows you to create branches - but it doesn’t tell
you how to use them!
❖ You need a written best practice of how work is ideally
structured in your team - to avoid mistakes & collisions.
❖ It highly depends on your team/team size, on your
project, and how you handle releases.
❖ It helps to onboard new team members(“this is how we
work here!”)
Integrating changes and structuring release
Mainline Development (Always be integrating)
→ few branches
→ relatively small commits
→ high-quality testing & QA standards
C C C C
Integrating changes and structuring release
State, Release, and Feature Branches
→ different types of branches…
→ …fulfill different types of jobs
C
Feature branch
C
C
Dev branch
C
C
Main branch
C C
Integrating changes and structuring release
Long-Running & Short-Lived Branches
→ Exist through the complete lifetime of the project
→ often, they mirror “stages” in your dev life cycle
→ Common conventions: no direct commits
C
Feature
C
C branch
Dev branch
C
C
Main branch
C C
Integrating changes and structuring release
Long-Running & Short-Lived Branches
→ for new features, bug fixes, refactoring, experientments…
→ will be deleted after integration (merge/rebase)
C
Feature
C
C branch
Dev branch
C
C
Main branch
C C
Branch strategies : ONE
GitHub Flow
→ very simple, very lean: only one long-running branch (“main”) + feature
branches
Bugfix branch
C C C C
Feature branch
C C
C
Branch strategy: TWO
GitFlow
→ more structure, more rules
→ long-running: “main” + “dev”
→ short-lived: features, releases, hotfixes
C
C C C Release branch
C
Feature branch
C
C
Dev branch
C
C C
Main branch
#3 Pull Request
Not a core git feature - provided by host environment
Used for communicating about and reviewing code - without pull request you would jump to
merging your code…
A pull request invites reviewers to provide feedback before merging
A way to contribute to repository you don’t have access to - through forks where one of the
main contributor can review your code and approve you submission into the main repo.
#4 Merge conflict
❖ When they might occur
❖ What they actually are
❖ How to solve them
Merge conflict
How and When Conflicts occur
→ When Integrating Commits from Different Sources
$ git merge
$ git rebase
$ git cherry-pick
$ git pull
$ git stash apply
Merge conflict
Merging Changes in Git
→ When Contradictory Changes Happen
→ Updating the same file o
Merge conflict
How to Know when a Conflict has occurred
→ Failed merge
→ Updating the same file o
→ git status - will show the unmerged paths
Merge conflict
How to Solve Merge Conflicts
→ Undo a Conflict and start Over (git merge –abort,
git rebase –abort)
→ Solve the conflict - Simply clean up the file (talk to teammate who made
the changes and agree which code is correct)
—> Use git Desktop GUI
#5 Merge & Rebase
Not a core git feature - provided by host environment
Used for communicating about and reviewing code - without pull request you would jump to
merging your code…
A pull request invites reviewers to provide feedback before merging
A way to contribute to repository you don’t have access to - through forks where one of the
main contributor can review your code and approve you submission into the main repo.
Merge & rebase
How merge works
→ A Simplified Scenario
(2) last commit on branch A
C1 Branch A
(1) Common ancestor
C2 C3 Branch B
(3) last commit on branch B
Merge & rebase
How merge works
→ Fast Forward Merge Senario
Branch A
C1 C2 C3
Branch B
Merge & rebase
How merge works
→ A Simplified Scenario
(2) last commit on branch A (4) merge commit (last common
ancestor)
C1
(1) Common ancestor
C2 C3
(3) last commit on branch B
Merge & rebase
Rebase starting situation
→ initial state
C1 C3
C2 C4
Merge & rebase
Rebase
→ Step one
C3
C1
C2 C4
(3) last commit on branch B
Merge & rebase
Rebase starting situation
→ Step one
C3
C1
C2 C4
(3) last commit on branch B
Merge & rebase
Rebase starting situation
→ Step two
C3
branch A
C1 C2 C4
branch B
Merge & rebase
Rebase starting situation
→ Step two
branch A
C3
C1 C2 C4
branch B
Take note!
Do not use Rebase for commits you have already shared or pushed on remote repository
Use Rebase for cleaning local commit history before sharing it to your team repository
