Setup for Rebasing Conflict

Introduction

Before learning about the setup for git rebase conflict, let us learn about rebasing, merging, merge conflict, and the difference between merging and rebasing. But first, let us start with the version control system and git.

A version control system is a tool in software development that tracks the changes in the code, documents, and other important information regarding a certain code base (or project), etc. There are two types of Version Control systems: Centralized Version Control Systems (CVCS) and Distributed Version Control Systems (DVCS).

Git is a distributed Distributed Version Control System that tracks the changes in the code, documents, and other important information regarding a certain code base (or project), etc. Git is free and one of the most widely used version control systems. We can use Git through the command line as well as through its graphical user interface (GUI). The command line or terminal version of Git is known as Git Bash on the other hand the GUI version of Git is known as Git GUI. Git tracks the changes in a project and saves a certain state that is known as commit. A commit is a snapshot of the file's current version (s). So, we track these commits and can revert to a certain commit if we want.

Git Merge and Git Rebase

Git merge is used to merge multiple commits of various branches into a single branch. In order to merge branches, it uses the head points from the commits, finds the base commit that applies to all the branches, and then merges commits to combine the modifications from each commit sequence. Merges in git can be done in one of five ways: Fast Forward, Recursive, Ours, Octopus, Resolve, and Subtree. Both public and private branches may use it. Additionally, it produces a graphical history so that the user can comprehend the commits and merging.

Alternatively, Git Rebase can be used to append the feature branch to the end of the master branch. It is a tool for editing, rearranging, rewriting, etc. the current commits. Unlike the git merge command, which merges the changes all at once, the git rebases command forces the commits to be merged linearly. The existing commits can be edited, rewritten, reordered, etc. using the interactive merging capability offered by git-rebase. It verifies the root commit and executes a series of one-by-one commits at the end of the master branch commit.

Learn more about git merge vs git rebase here.

Merge Conflicts During Rebasing

As we know that when we use the git rebase command, the history of the commit is rewritten on the other hand, if we use the git merge command then the history of the commit is preserved. Merge conflict is a problem that arises during merging and rebasing in Git. So, it must be handled with care as it can cause major problems.

What exactly is Merge Conflict? Well, a Merge conflict is an issue that arises when we try to merge two branches that have been edited at the same time and in the same file (refer to the image provided below for more clarity), then git will not be able to merge them as git cannot identify the version that needs to be used for changes.

In case of a merge conflict, Git stops the merging process just before performing the merge conflict so that the user can resolve the conflict manually.

Regular Rebase

Let us learn how a regular git rebasing works. Suppose we have an ongoing project and we have created another branch (namely the test branch) for the development process. We have some commits made in the master branch as well as in the test branch. Now we want to rebase the commits of the test branch to the master branch, we can run the following git rebase command.

Now if we want to continue with the changes made then we can run the command:

On the other hand, if we are not happy with the current change and we want to ship this change, then we can run the command:

Using Rebase Abort and Skip

As we have discussed that at the time of git rebasing we may encounter some situations known git merge conflict and git asks us to resolve the conflict before moving forward to rebasing.

Now, if we want to completely abort or undo a certain rebase process, we can use the git rebase command along with the --abort flag. The git rebase --abort does not remove the merge conflict but what it does is that it helps us to undo a fully rebased branch to its original state before the rebase was performed. It can also abort the rebase process so that we can continue with the rebasing later onwards.

In simpler terms, the git rebase --abort command resets the HEAD of the commit to the original branch. If we specify the branch name during rebase operation then the HEAD pointer will be reset to that branch on the other hand if we do not specify any branch at the start (of the rebase operation) then the HEAD pointer will be reset to where it was previously when the rebasing was started.

Now the --skip flag of the git rebase command is simply used to restart the rebasing process by just skipping the current patch of the commit.

Finding Out the Commit Causing the Rebasing Conflicts

Let us understand the scenario in which we have a branch having some commits in the branch causing merge conflicts and we need to pick the conflicting commits. Suppose we have two branches namely main and feature.

Suppose that we had some bugs in our project and we need to fix them so we fixed them and after committing those changes, we shifted our branch to the feature branch. A normal merge cannot work here as it will break our project. A merge conflict may arise in such situations. In such scenarios, we first check the logs (using the git log command) to check all the commits performed in the history. After checking out the logs, we need to switch to the branch that contains the changes. Now for switching to that branch (here feature branch) we can use the git checkout <branch-name> command. And finally, we get our desired commit causing the rebasing conflicts.

Now, after checking out into the feature branch, we need to identify the commits that we want to rebase (merge) in our main branch. Let us assume that we have found two commits namely edc8ae and cefb7bb that are not yet in the main branch. Now to merge these two commits in the main branch we can use the git rebase command and append the commit ids of both commits.

Using Git Push Force After Rebase

The git push --force is a crucial command that is used to perform more complex operations. Suppose we were performing squashing of commits or resetting of commits or rebasing of commits, we must use the --force flag to update the remote branch. So to force an update on the remote branch, we use the --f or --force flag along with the push command.

If we force a rebase even if the current branch is up-to-date with the remote and main branch then the command without the --force flag would return without doing anything.

Interactive Rebase

Let us discuss interactive git-rebase. The git interactive rebasing is a tool that is used to edit, reorder, rewrite, etc. the current commits (basically modify the commits). We must know that we can only perform the interactive git rebasing on the current branch (the branch that we are currently working on).

To perform interactive git rebasing, we can use the git rebase command along with the -i flag, here the -i flag stands for interactive.

The command of interactive git-rebase.

If we use the above command, git Bash will open an editor for us. Refer to the image provided below.

We can see a lot of options contained in the editor. Some of the useful options are:

1. Pick (-p): It is used to include the commits as by default, we are provided with the table of commits arranged in ascending order (by date). We can rearrange the pick command to change the order of the commits before starting the rebasing.
2. Reword (-r): It is used to halt the rebasing and it allows us to change the commit message before continuing the rebasing.
3. Edit (-e): It helps us to edit the commit.
4. Squash (-s): It helps us to combine two or more two commits into a single commit. It also allows us to specify a new commit message to the changes.
5. Fixup (-f): It is used to discard the commit message, and use the older commit message to the changes.
6. Exec (-x): It is used to run shell-related commands against a commit.
7. Break (-b): It is used to stop the rebasing at a position.
8. Drop (-d): As the name suggests, it is used to drop the current commit.
9. Label (-l): It is used to specify or add a name to the position of the current head.
10. Reset (-t): It is used to reset the head of the commit to a label.

As we know that the git interactive rebasing is used to edit, reorder, rewrite, etc. the current commits. On the other hand, the normal git rebasing is used to move the feature branch (a development branch) to the tip of the master branch. Both of the commands can be used as alternatives to the git merge command.

The major difference between the interactive git rebasing and normal rebasing is that if we perform the normal rebasing, the rebase command will check the root commit and perform a series of commits one after the other at the tip of the master branch commit. On the other hand, if we perform the interactive git rebasing then the rebase command will open a shell editor and allows us to change as well as modify the commits.

This can also be visualized as we cannot (user cannot) provide feedback during commits in the normal git rebasing but in the interactive git rebasing, we can provide feedback as well as perform several functions like commit reordering, commit removal, etc.

Rerere

Git rerere stands for reuse recorded resolution and this feature asks us to allow Git to remember how we have resolved a major or hunk conflict so that whenever there is a similar situation then Git can automatically resolve such merge conflicts.

To enable this rerere functionality, we can run this simple git config setting.