Git: Rebase – When and Where Not To Do

Posted on By Andre Dias
versioning

There are many good posts about the differences between pulling with and without rebase, merge and etc.
If you desire to refresh memory about this, try these:

git: the difference between git pull and git pull –rebase

Git Branching and Merge vs Rebase- 

This post intends to supply information on when and where not to do a rebase.
Through an example of our typical day life when things go wrong and the documentation let interrogation marks on your mind: and what does it happen then?


Scenario

Suppose that the master branch is very difficult to understand, having so many threads tangled among them that you start thinking about if “rebasing” wouldn’t help.
Please, for the sake of your own happiness and dignity, don’t.

Why?
The short answer is this:

First, you’ll change the original information and your team may not approve it.
So, ask them first.

Second, all operations involve risk and things may not happen as expected.
Murphy is elsewhere, unfortunately — or not, looking the other way around, you may concern that makes our life more exciting and challenging, after all, if everything always works well, life would lose that feeling of risk that turns life so exciting.

So, better to get prepared to handle “Murphy”! 🙂

ONE USE CASE AS AN EXAMPLE

Performing the master’s rebasing:

git checkout master
git pull –rebase

Usually, you may get a conflict to solve.
Basing on GitHub’s documentation, you perform the fix.

As supposed, any documentation must concern about the usual procedure supposing an optimist scenario and sometimes adding extra direction to some issues.
Issues are part of our IT daily life, always challenging us with unexpected ones.
Below, I transcribe parts of its documentation to make things easier (italic).

 

#Resolving merge conflicts after a Git rebase

When you perform a git rebase operation, you’re typically moving commits around. Because of this, you might get into a situation where a merge conflict is introduced. That means that two of your commits modified the same line in the same file, and Git doesn’t know which change to apply.

After you reorder and manipulate commits using git rebase, should a merge conflict occur, Git will tell you so with the following message printed to the terminal:

error: could not apply fa39187... something to add to patch A

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply fa39187f3c3dfd2ab5faa38ac01cf3de7ce2e841... Change fake file

Here, Git is telling you which commit is causing the conflict (fa39187). You’re given three choices:

  • You can run git rebase --abort to completely undo the rebase. Git will return you to your branch’s state as it was before git rebase was called.
  • You can run git rebase --skip to completely skip the commit. That means that none of the changes introduced by the problematic commit will be included. It is very rare that you would choose this option.
  • You can fix the conflict.

To fix the conflict, you can follow the standard procedures for resolving merge conflicts from the command line. When you’re finished, you’ll need to call git rebase --continue in order for Git to continue processing the rest of the rebase.

FIXING REBASE CONFLICT SUMMARY

To fix the conflict, you can follow the standard procedures for resolving merge conflicts from the command line. When you’re finished, you’ll need to call “git rebase --continue" in order for Git to continue processing the rest of the rebase.

1. To discover the conflicts, do:
git status

2. Edit the file that has the conflict and solve it.

<<<<<<< HEAD
The original code from the current state of the file before the rebase operation
=======
The new code to be merged from the rebase operation
>>>>>>> branch-a

FINISH THE REBASE OPERATION AFTER FIXING CONFLICTS

3. Add or stage your changes.
git add .

4. Commit your changes with a comment.
git commit -m “Resolved merge conflict by incorporating both suggestions.”

5. Finish rebase:
git rebase –continue

@FROM:
docs.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line

WHEN GIT REFUSES TO CONTINUE

The rebase operation takes place:

 

What if, after resolving the merge conflict, the “git rebase –continue” still rejects and continues returning that message: “the merge must be done”!
You think: I’ve already solved the conflict, then performed “git add”, after performed commit, but it is still refusing.
What do I do?

 

 

If no other idea comes to mind, well, it is when the third option comes into place: the skip option:
git rebase –skip

The file’s content is preserved as it is but there is a side effect — the track of that merge thread will not meet the target thread as usual, getting something like this:

 

On the right, we have the log before rebasing.
On the left, the log after rebasing with a skip operation, where it is lost the merge that originally had for “c0f92f1”.

CONCLUSION: some information was lost in the master’s history.
Something that is not really desirable.

WHEN SHALL I USE REBASE, THEN…

I think it is useful to rebase your working branch, putting on top of it your current commits.
It gives us the chance to handle conflicts as if we had an update (pull) before starting to make our changes in the code.
This enables us to a better understanding of what our team has been changing and how it was done out of our interference.

The “–continue” operation fits very well this approach.