How to Check If a Git Branch Is Fully Merged into Main

GitGitBeginner
Practice Now

Introduction

In this lab, you will learn how to effectively check if a Git branch has been fully merged into another branch, specifically focusing on the main branch. This is a crucial skill for maintaining a clean and organized Git repository.

You will begin by using the git branch --merged main command to identify branches that are fully integrated into main. Following this, you will verify the results using the git log main ^branch command to confirm that all commits from the target branch are present in main. Finally, you will test these methods with a partially merged branch to understand the different outcomes.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL git(("Git")) -.-> git/BranchManagementGroup(["Branch Management"]) git/BranchManagementGroup -.-> git/branch("Handle Branches") git/BranchManagementGroup -.-> git/checkout("Switch Branches") git/BranchManagementGroup -.-> git/merge("Merge Histories") git/BranchManagementGroup -.-> git/log("Show Commits") git/BranchManagementGroup -.-> git/cherry_pick("Cherry Pick") subgraph Lab Skills git/branch -.-> lab-560045{{"How to Check If a Git Branch Is Fully Merged into Main"}} git/checkout -.-> lab-560045{{"How to Check If a Git Branch Is Fully Merged into Main"}} git/merge -.-> lab-560045{{"How to Check If a Git Branch Is Fully Merged into Main"}} git/log -.-> lab-560045{{"How to Check If a Git Branch Is Fully Merged into Main"}} git/cherry_pick -.-> lab-560045{{"How to Check If a Git Branch Is Fully Merged into Main"}} end

Use git branch --merged main

In this step, we will learn how to use the git branch --merged command to see which branches have been fully integrated into another branch. This is a very useful command for keeping your repository clean and organized.

First, let's make sure we are in our project directory. Open your terminal and navigate to the my-time-machine directory:

cd ~/project/my-time-machine

Now, let's create a new branch called feature-branch and switch to it. We'll simulate making some changes on this branch.

git branch feature-branch
git checkout feature-branch
echo "Adding a new feature" >> feature.txt
git add feature.txt
git commit -m "Add new feature"

You should see output similar to this after the commit:

[feature-branch a1b2c3d] Add new feature
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

Now, let's switch back to the master branch and merge the feature-branch into it.

git checkout master
git merge feature-branch

You should see output indicating a successful merge:

Updating e1f2g3h..a1b2c3d
Fast-forward
 feature.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

Now that we have merged feature-branch into master, let's use git branch --merged to see which branches are now fully merged into master.

git branch --merged master

This command will list all branches that have had all of their commits incorporated into the master branch. You should see both master and feature-branch listed, indicating that feature-branch is now fully merged into master.

Understanding which branches are merged is important because it helps you identify branches that can be safely deleted, keeping your repository tidy. It's like knowing which side quests in a game you've completed and can now ignore.

Verify with git log main ^branch

In the previous step, we used git branch --merged to see which branches were merged into master. Now, let's use a different command, git log, to verify this from another perspective. The git log command with the main ^branch syntax is a powerful way to see commits that are in main but not in branch.

First, ensure you are in the my-time-machine directory:

cd ~/project/my-time-machine

Now, let's use git log to see the commits that are in master but not in feature-branch.

git log master ^feature-branch

Since we fully merged feature-branch into master in the previous step, all commits from feature-branch are now also in master. Therefore, this command should show you the commits that were originally only on the master branch before the merge. It should not show the commit "Add new feature" that we made on feature-branch.

You should see output similar to this, showing only the initial commit(s) from the master branch:

commit e1f2g3h4i5j6k7l8m9n0o1p2q3r4s5t6u7v8w9x (HEAD -> master)
Author: Jane Doe <[email protected]>
Date:   Mon Aug 7 10:00:00 2023 +0000

    Send a message to the future

If feature-branch were not fully merged, this command would show the commits that are on master but not on feature-branch, as well as any commits that are on feature-branch but not on master. The fact that the "Add new feature" commit is not shown here confirms that it is now present in master.

This git log main ^branch syntax is a great way to visually confirm if all commits from one branch are present in another. It helps you understand the relationship between different branches in your repository.

Test with Partially Merged Branch

In the previous steps, we saw how git branch --merged and git log main ^branch work with a fully merged branch. Now, let's see what happens with a branch that is partially merged, meaning some, but not all, of its commits have been integrated into another branch.

First, make sure you are in the my-time-machine directory:

cd ~/project/my-time-machine

Let's create a new branch called partial-feature and switch to it:

git branch partial-feature
git checkout partial-feature

Now, we'll make two commits on this new branch:

echo "Adding part 1 of the feature" >> partial.txt
git add partial.txt
git commit -m "Add part 1"
echo "Adding part 2 of the feature" >> partial.txt
git add partial.txt
git commit -m "Add part 2"

You should see output similar to this after the commits:

[partial-feature a1b2c3d] Add part 1
 1 file changed, 1 insertion(+)
 create mode 100644 partial.txt
[partial-feature e1f2g3h] Add part 2
 1 file changed, 1 insertion(+)

Now, let's switch back to the master branch and merge only the first commit from partial-feature. We can do this using git cherry-pick. First, we need the commit hash of the "Add part 1" commit. You can find this by running git log partial-feature and copying the hash of the first commit.

git checkout master
## Replace <commit_hash> with the actual hash of the "Add part 1" commit
git cherry-pick <commit_hash>

You should see output indicating the cherry-pick was successful:

[master i1j2k3l] Add part 1
 Date: Mon Aug 7 10:05:00 2023 +0000
 1 file changed, 1 insertion(+)
 create mode 100644 partial.txt

Now, let's use git branch --merged master again:

git branch --merged master

You should see master and feature-branch listed, but not partial-feature. This is because partial-feature still has the "Add part 2" commit which has not been merged into master. git branch --merged only lists branches where all commits are present in the target branch.

Finally, let's use git log master ^partial-feature:

git log master ^partial-feature

This command will show you the commits that are in master but not in partial-feature. It should show the initial commit(s) from master, the "Add new feature" commit (which is now in master), and the "Add part 1" commit (which we cherry-picked). It should not show the "Add part 2" commit, as that commit is only on partial-feature.

This demonstrates how git branch --merged and git log main ^branch can help you understand the merge status of your branches, even when only some commits have been integrated.

Summary

In this lab, we learned how to check if a Git branch is fully merged into another branch, specifically main (or master). We started by using the git branch --merged main command, which lists all branches whose commits are fully incorporated into the main branch. This is a quick way to identify branches that are ready for cleanup.

We then explored a more granular verification method using git log main ^branch. This command shows commits that are in main but not in the specified branch. If this command returns no output, it confirms that all commits from the branch are present in main, thus verifying the full merge. Finally, we tested these methods with a partially merged branch to understand the difference in output and further solidify our understanding of how to accurately determine the merge status of a branch.