Git Merge and Git Rebase: A Practical Guide to Branch Integration

2025-02-28 15:13:02.955314

This chapter explores two fundamental Git commands, git merge and git rebase, used for integrating changes from one branch into another. We will examine their functionalities, illustrate their usage with a practical example, and discuss the scenarios where each command is most appropriate.

Introduction to Branch Integration in Git

In collaborative software development, it is common practice to work on new features or bug fixes in separate branches, isolating changes from the main codebase until they are ready for integration. Git, a distributed version control system, provides powerful branching and merging capabilities to manage this workflow effectively.

This chapter focuses on two primary methods for integrating branches back into the main branch (often master or main): git merge and git rebase. Understanding the nuances of these commands is crucial for maintaining a clean and understandable project history.

Scenario: Feature Branch Development

Let’s consider a common development scenario:

You start with a master branch, representing the main, stable version of your project.
A feature branch is created from the master branch to develop a new feature. This allows for isolated development without directly impacting the main codebase.
While you are working on the feature branch, the master branch continues to evolve as other developers contribute changes.
The goal is to eventually incorporate the completed feature from the feature branch back into the master branch, while also integrating any changes that have occurred in master since the feature branch was created.

This scenario presents the challenge of combining changes from two diverging branches. Git offers git merge and git rebase as solutions to this challenge. Let’s explore each of these methods in detail.

Git Merge: Combining Branch Histories

git merge is a command used to integrate changes from one branch into another. It creates a new commit in the target branch that represents the combined changes from both branches.

Git: A distributed version control system that tracks changes in files over time, allowing for collaboration and version management in software development and other projects.

In our scenario, we have a master branch with commits m1, m2, and m3, and a feature branch branched off from m2 with commit f1. We aim to integrate the feature branch into master.

Demonstration: Git Merge

Let’s walk through a practical example using the command line.

Project Setup: Assume you have a Git repository with master and feature branches as described.

Repository: A directory containing all project files and the complete history of changes tracked by Git.

You can verify your current branch and the branch structure using the following command in your terminal:
```
git branch
```
This command will list all branches, with an asterisk (*) indicating the currently active branch.
Examining Commit History: To visualize the commit history of a branch, use the git log command.
```
git log
```
Commit: A snapshot of the repository at a specific point in time, representing a set of changes. Each commit has a unique identifier and metadata like author and timestamp.
- On the master branch, git log will show commits m3, m2, and m1.
- On the feature branch, git log will show commits f1 and m2.
Branch: A lightweight, movable pointer to a commit. Branches are used to isolate development work and manage different versions of the codebase. In this example, master and feature are branches.

Master Branch: The primary branch in a Git repository, traditionally representing the main, stable development line. It is increasingly being referred to as the ‘main’ branch.

Feature Branch: A branch created specifically for developing a new feature, branched off from another branch (often master or main).
Adding a New Feature Commit: Switch back to the feature branch using git checkout:
```
git checkout feature
```
Checkout: The operation of switching between branches or commits in Git, making the selected branch or commit the current working state.

Make changes to your project files to implement the feature. For demonstration purposes, let’s assume you add content related to “f2”.
Committing the Feature Changes: Stage and commit your changes with git add and git commit:
```
git add .
git commit -m "f2"
```
Add: In Git, the process of staging changes, preparing them to be included in the next commit. git add . stages all changes in the current directory and its subdirectories.

Commit (command): The command used to save staged changes to the repository’s history, creating a new commit. The -m flag allows you to add a commit message directly in the command line.

Now, git log on the feature branch will show commits f2, f1, and m2.
Merging the Feature Branch into Master (Squash Merge): To integrate the feature into master, first switch back to the master branch:
```
git checkout master
```
Then, use the git merge command with the --squash option:
```
git merge --squash feature
```
Squash Merge: A type of merge operation that combines all changes from a branch into a single new commit in the target branch, simplifying the history.

The --squash option is used here to consolidate all commits from the feature branch into a single commit on the master branch. Without --squash, git merge feature would merge all commits from the feature branch, preserving the entire feature branch history in the master branch.
Completing the Merge Commit: After the squash merge, Git stages the changes but does not automatically create a commit. You need to create a commit manually:
```
git commit -m "Feature and master merged"
```
This creates a new commit on the master branch that includes all changes from the feature branch, effectively merging the feature into master in a single commit.
Verifying the Merge Result: Use git log on the master branch to see the updated commit history. You will see the new merge commit on top, followed by m3, m2, and m1. The changes from the feature branch are now incorporated into the master branch’s codebase.

Advantages and Considerations of Squash Merge

Simplified History: Squash merge creates a cleaner and simpler history in the master branch by condensing all feature branch commits into one. This can be beneficial for readability and understanding the high-level evolution of the project in the main branch.
Loss of Feature Branch History in Master: While simplifying the master branch history, squash merge loses the individual commit history of the feature branch within the master branch. If detailed tracking of feature development within the main branch history is desired, a regular merge without --squash might be preferred.

Git Rebase: Rewriting Branch History

git rebase is another command for integrating changes, but it operates differently from git merge. Instead of creating a merge commit, git rebase reapplies commits from one branch onto another. It essentially “moves” the starting point of your branch to a different commit.

Rebase: In Git, the process of changing the base commit of a branch. It reapplies commits from one branch onto another, creating a linear history.

Demonstration: Git Rebase

Let’s rewind our project to the state before the merge and demonstrate git rebase.

Project Reset: Assume you are back in the state where master has commits m1, m2, m3 and feature (branched from m2) has commit f1.
Rebasing Feature Branch onto Master: Ensure you are on the feature branch:
```
git checkout feature
```
Execute the rebase command:
```
git rebase master
```
This command tells Git to rebase the feature branch onto the master branch.
Understanding Rebase Operation: Git performs the following steps during rebase:
- Finds Common Ancestor: Git identifies the last common commit between the feature and master branches, which is m2 in our case.
- Saves Feature Branch Commits: Git temporarily saves the commits unique to the feature branch (in this case, f1).
- Replays Master Branch Commits: Git resets the feature branch to be based on the latest commit of the master branch (m3). Now, the feature branch effectively starts from m3.
- Applies Saved Commits: Git then reapplies the saved feature branch commits (f1) on top of the new base (m3).
Examining Rebased Branch: After rebasing, git log on the feature branch will show a modified history. You will see commits f1 and m3, effectively making m3 the new base for the feature branch. The master branch remains unchanged at this point.
Adding Another Feature Commit (f2): Continue working on the feature branch and add another commit:
```
git add .
git commit -m "f2"
```
Now, git log on the feature branch shows f2, f1, and m3.
Rebasing Master onto Feature (Fast-Forward Merge): To integrate the rebased feature into master, switch to the master branch:
```
git checkout master
```
Now, rebase master onto feature:
```
git rebase feature
```
In this case, because the feature branch is now directly ahead of the master branch in terms of history (due to the earlier rebase of feature onto master), Git performs a “fast-forward” rebase.

Fast-Forward Merge/Rebase: A merge or rebase operation where the target branch’s head can simply move forward to the head of the source branch because there are no diverging changes to reconcile.
Verifying Rebase Result: After the rebase, git log on the master branch will show the commits in a linear sequence: f2, f1, m3, m2, m1. Both master and feature branches now point to the same commit (f2).

Advantages and Disadvantages of Git Rebase

Linear History: Rebase creates a linear, cleaner project history without merge commits. This can make the project history easier to follow and understand, particularly for complex projects.
Rewritten History: Rebase modifies the commit history. This can be problematic in collaborative environments, especially in public repositories. Rebasing public branches can cause confusion and conflicts for collaborators who have already based their work on the original commits.

Important Caution: Rebasing Public Branches

Do not rebase commits that have been pushed to a public repository or shared with collaborators.

Rebasing changes the commit history, effectively creating new commits with the same changes but different commit IDs. If others have based their work on the original commits that you rebase, their history will diverge from the rewritten history, leading to conflicts and potential data loss.

Rebase is generally safe and beneficial for local feature branches that have not been shared. It is a powerful tool for maintaining a clean and linear history in your personal workflow.

Conclusion

Both git merge and git rebase are valuable tools for integrating changes in Git.

git merge is a non-destructive operation that preserves the entire history of all branches, creating merge commits to explicitly show branch integrations. Squash merge offers a way to simplify the history in the target branch by collapsing feature branch commits.
git rebase rewrites history to create a linear sequence of commits, making the project history cleaner but potentially causing issues if used on public branches.

The choice between git merge and git rebase depends on the desired project history and the collaboration workflow. Understanding the implications of each command is crucial for effective Git usage and team collaboration. For collaborative projects, especially with public repositories, it is generally safer and more conventional to use git merge to avoid rewriting shared history. git rebase can be a powerful tool for personal workflows and maintaining clean, linear history in local feature branches before merging them.