Introducing Git Merge and Git Rebase: Why and When to Use Them

Often, developers have a choice between Merge (merge) and Rebase (move). In Google, you will see a different opinion, many advise not to use Rebase, as this can cause serious problems. In the article I will explain what merging and moving is, why you should (or should not) use them and how to do it.



Git Merge and Git Rebase have the same goal. They are designed to integrate changes from one branch to another. Although the end goal is the same, the principles of work are different.

Some people think that you should always use Rebase, others prefer Merge. This has its pros and cons.

Git merge

Merging is common practice for developers using version control systems. Regardless of whether branches are created for testing, bug fixes, or for other reasons, a merge captures changes elsewhere. The merge takes the contents of the source branch and merges them with the target branch. In this process, only the target branch changes. The history of the original branches remains unchanged.

Pros:

• simplicity;
• keeps complete history and chronological order;
• supports the context of the thread.

Minuses:

• commit history can be filled (polluted) with multiple commits;
• debugging with git bisect can be tricky.

How to do it

Merge the master branch into the feature branch using the checkout and merge commands .

$ git checkout feature
$ git merge master
(or)
$ git merge master feature

This will create a new “Merge commit” in the feature branch, which contains the history of both branches.

Git rebase

Rebase is another way to transfer changes from one branch to another. Rebase compresses all changes into one “patch”. It then integrates the patch into the target branch.

Unlike a merge, moving overwrites the history because it transfers the completed work from one branch to another. The process eliminates unwanted history.



Pros:

• Simplifies a potentially complex story.
• Simplify single commit manipulations
• Avoid merging commits in busy repositories and branches
• Cleans up intermediate commits, making them one commit, which is useful for DevOps commands.

Minuses:

• Compressing features to multiple commits can hide context
• Moving public repositories can be dangerous when working in a team
• More work appears
• For recovery with deleted branches, a forced push is required. This leads to the update of all branches that have the same name, both locally and remotely, and this is terrible.

If you make a wrong move, the story will change, and this can lead to serious problems, so make sure you do it!

How to do it

Move the feature branch on the main branch using the following commands.

$ git checkout feature
$ git rebase master

This moves the entire branch of the function to the main branch. The project history changes, new commits are created for each commit in the main branch.

Interactive move

This allows you to change commits as they move to a new branch. This is better than automatic relocation because it provides full control over the commit history. As a rule, it is used to clear history before merging the feature branch into master.

$ git checkout feature
$ git rebase -i master

This will open the editor, listing all the commits that will be moved.

pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3

This defines exactly what the branch will look like after the move has been completed. By organizing objects, you can make the story as you like. You can use the fixup , squash , edit , and so on commands .

Which one to use?

So what's better? What do experts recommend?

It is difficult to make the only correct decision about what is best to use, since all the teams are different. It all depends on the needs and traditions within the team.

Make decisions based on team competency in Git. Is simplicity or rewriting a story important to you, or maybe something else?

What do I recommend?

As the team grows, it becomes difficult to manage or track changes in development by applying a merge. To have a clean and clear commit history, it is wise to use Rebase.

Advantages of Rebase:

• You develop locally: if you have not shared your work with anyone else. At this point, you should prefer moving over to merge to keep your history in order. If you have a personal repository plug that is not shared with other developers, you can rebase even after you've moved to your branch.
• Your code is ready for review: you have created a pull request. Others analyze your work and potentially pin it to their fork for a local review. At the moment you do not have to move your work. You must create a remake and update the branch. It helps to track requests for pull requests and prevents accidental breaking of history.
• The review is done and ready for integration into the target branch. Congratulations! You are about to delete your feature branch. Considering that from this point on, other developers will not fetch-merging these changes, this is your chance to change your story. At this stage, you can rewrite history and reset the original commits, and these annoying “rework” and “merge” merge into a small set of targeted commits. Creating an explicit merge for these commits is optional, but important. It records when the function has reached master.

Now you know even a little, but the difference between Merge and Rebase. I am sure you will make the right decision and will use what is right for you.

Do not forget:

code = coffee + developer