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