Getting started with git merge vs rebase
You should understand git merge vs rebase to do efficient branching between repos. Git merge preserves the history, whereas git rebase rewrites it.
Git merge is best for handling commits that affect several developers. Git rebase, on the other hand, is crucial in creating a more organized, linear local repo.
Assume you work on an application's new feature. You create a branch and switch into it from the main branch then implement the new features.
While working on the task, you create multiple files, add and commit them. Lastly, you check out the main branch and merge the commits using the commands:
git merge <branch>
You then push the changes to a remote repo.
Working with git rebase follows a similar pattern. You switch to a feature branch, create the file(s), add and commit them. You check out the main branch and pull changes. You then return to the feature branch and do a git rebase using the commands:
git rebase <branch>
Unifying commits comes with side effects that may be contrary to your target outcome. However, that should not worry you because understanding git merge vs rebase is all you need to clear the errors.
For instance, git emerge creates a dumpy history, and you can use git rebase to organize the spaghetti commit history. On the other hand, using git rebase may lead to conflict errors when collaborating on a project with many developers. Git merge comes in to avoid those errors, as you will see in this tutorial.
Now that you know why you should understand git merge vs rebase, let us take an in-depth view of the two git technologies below.
Lab setup to explain git merge vs rebase
Let us create two remote repos to ease distinguishing git merge vs rebase. I am creating a repo called git_merge
on Github to illustrate the power of git merge and git_rebase
Grab the repo URLs.
then head to the command line and clone the repos.
cd into git_merge or git_rebase depending on whether we handle git merge or git rebase.
You should initialize either repo if you did not create a README.md file on Github.
git init
Create two files file1.txt and file2.txt, in each directory.
touch file1.txt file2.txt
Git status shows we have two untracked files.
git status
Let us stage and commit files.
Run
git add .
to stage the files.
Running
git status
we see the file changed from red to green, meaning git tracks the files.
Commit the changes using the message:
git commit -m "commit-2: add file1 and file2"
We can view the commit history by running
git log
to see the full commit hash and history or
git log --oneline
to see a shorter version of the commit history
We have two commits in the history to practice git merge vs rebase.
Let us start working with git merge.
Example-1: How to use git merge
We are currently in the main branch. Create a branch called git_merge using
git branch git_merge
then check it out using the command
git checkout git_merge
Alternatively, you create and check out the branch by running the command
git switch -c git_merge
Add more files
touch file1_merge.txt file2_merge.txt
Add the files to the staging area
git add .
and commit the changes
git commit -m "commit 3 - merge 1"
We have the git_merge branch's one commit and the main branch's primary commits, initial commit, and commit 2.
Let us return to the main branch and continue committing more changes, assuming more developers work on the same repo as you.
Check out the main branch.
git checkout main
Add another commit
touch file3.txt git add . git commit -m "commit-3: add file3"
Check the history.
git log
Run
git merge git_merge
Our code editor opens up, asking us to insert a commit message. Let us go with the default one, save and close the editor.
Recheck the commit history
git log
Git took our commits from the git_merge branch and bundled them into a single commit before making it the final commit in history. Our history is a mixture of commits from the main and thegit_merge branches.
The problem with git merge
The resulting history looks jumbled up. Now imagine the disorganized history we would have if we had tens of developers creating thousands of commits in history daily.
To evade such a mess, we employ git rebase to reorganize our commit history. Before moving to the git rebase section, let us push our changes to the remote repo.
git push
Head over to the remote repo on Github, refresh the browser, and inspect the repo. Our changes got pushed successfully. Let us explore rebase to have a more solid understanding of git merge vs rebase.
Example-2: How to use git rebase
Head over to the command line and cd into git_rebase folder we created in the lab setup section.
Run
git log
command to view the commit history. Currently, we have two commits in the main branch.
Let us make and check out a new branch
git switch -c rebase_branch
Add extra files.
touch file1_rebase.txt file2_rebase.txt
Stage the files.
git add .
and commit the changes
git commit -m "commit 3 - rebase 1"
Check history
git log
Assume other developers pushed more changes in the main branch's history while we worked on the git_rebase branch. Let us return to the main branch and create more changes to mimic the scenario.
git checkout main
Introduce another commit in the history
touch file3.txt git add . git commit -m "commit-3: add file3"
Check the history.
git log
Check out the rebase_branch branch again.
git checkout rebase_branch
Now is the time to git rebase with two aims; confirm whether there is a conflict between the two branches' history or join changes between the branches. Here, we shall only focus on joining commits because we are sure there are no file change conflicts between our branches.
Run the command
git rebase main
This time around, our code editor does not open up to ask us for a commit message. Instead, we get a successful rebase message.
Let us analyze the effect of git rebase.
git log
Git forwarded our commits in the git_merge branch by inserting the commits from the main branch before our current commits. The repo is now more understandable.
Also, rebasing the main branch maintains the linearity of the commit history, as you can see here.
git checkout main git rebase rebase_branch git log
The problem with git rebase
Although git rebase creates a cleaner history, it is not advisable to use it when pushing changes to a remote repo, where several developers constantly collaborate. The team should then use git pull --rebase as shown below:
git pull --rebase
when rebasing remote branches. Better yet, it would help to use git merge.
Conclusion
The most straightforward way to distinguish or choose between git merge vs rebase for your project is to consider the ease of handling a remote repo and the level of history organization you need.
Git merge is best in pulling and pushing changes without caring about the linearity of the commit history. Git rebase is conducive in situations where you want to create an organized repo or check merge conflicts before joining changes between repos.
