Module 4
4.6: Git & Github
Module 4
4.6: Git & Github
In this section, we will explore different ways to merge branches in Git. Merging is a key part of collaborating on code, and understanding the various merge strategies can help you manage your workflow efficiently.
A regular merge is the default way Git combines changes from one branch into another. When you merge two branches, Git creates a merge commit that has two parent commits: one from each branch. This preserves the history of both branches.
Example Scenario:
You have the master branch with commits M1 → M2 → M3.
You have a feature branch that was created from M2 and has its own commits: F1 → F2.
Steps:
You want to merge the feature branch into master.
Run the following command:
git merge feature
Result:
The master branch now contains: M1 → M2 → M3 → Merge Commit → F1 → F2
Git creates a merge commit to combine the histories of the two branches.
Why use Regular Merge?
Use regular merge when you want to preserve the full commit history of both branches. It’s useful for teams collaborating on a project and when you want to maintain a clear history of all work done.
A squash merge combines all the changes from a branch into a single commit. It doesn’t preserve the individual commits from the feature branch, but instead, it squashes all the changes into one commit that is added to the destination branch.
Example Scenario:
You have the master branch with commits M1 → M2 → M3.
You have a feature branch with commits F1 → F2.
Steps:
To squash the feature branch into a single commit, run the following command:
git merge --squash feature
Commit the changes with a new message:
git commit -m "X" # Where X is the combined commit message
Result:
The master branch now contains: M1 → M2 → M3 → X
The changes from F1 and F2 are combined into one commit X.
Why use Squash Merge?
Squash merge is ideal when you want to keep the master branch history cleaner. It’s helpful when working on small features or experiments that you don’t need to track in detail.
It reduces the clutter in your commit history, making it easier to track main milestones in the project.
Rebase is a powerful command that allows you to reapply your changes on top of another branch. It essentially rewrites the commit history and creates a linear history. This can be helpful for keeping the commit history tidy.
Example Scenario:
Your master branch has commits M1 → M2 → M3.
Your feature branch has commits M1 → M2 → F1 → F2.
Steps:
First, make sure you’re on the feature branch:
git checkout feature
Then, rebase your feature branch on top of the master branch:
git rebase master
Result:
Your feature branch now looks like this: M1 → M2 → M3 → F1' → F2'
The commits F1 and F2 are now placed on top of M3, making the history appear as if the feature branch started after M3.
Why use Rebase?
Rebase is useful for linearizing your commit history and making it appear as if the changes were made sequentially. It’s typically used in feature branches before merging to master, especially when you want to avoid merge commits and keep a clean history.
Be cautious with rebase, especially when working on shared branches, as it rewrites history and can cause issues for others working on the same branch.
A rebase merge combines the changes from the feature branch on top of master without creating a merge commit. It’s essentially the combination of a rebase and a merge but without the clutter of a merge commit.
Example Scenario:
Your master branch has commits M1 → M2 → M3.
Your feature branch has commits M1 → M2 → F1 → F2.
Steps:
To perform a rebase merge, run the following command:
git merge --rebase feature
Result:
The master branch now contains: M1 → M2 → M3 → F1 → F2
The feature branch commits are applied directly on top of master, creating a linear history without a merge commit.
Why use Rebase Merge?
Rebase merge is ideal when you want to keep a linear history and avoid creating unnecessary merge commits. It’s a good choice for projects that prioritize clean commit histories.
Use it when you want the feature branch commits to be integrated into master without introducing the complexity of a merge commit.