Question

I’m new to git and I’m a bit confused about the “right” way of using git rebase.

Is the idea that, once I finish the rebase and conflict resolution process, my history will look as if I didn’t change my mind along the way?

Let’s say, for instance, that I have commit A and commit B. Commit A makes some important changes but also introduces a function that I later remove in commit B. When rebasing, I encounter a conflict from the function introduced in commit A.

What is the “right” way to respond here? Should I edit commit A to avoid introducing the function altogether and then skip commit B entirely? If so, don’t I miss out on important context about the evolution of the code?

Answer 1

I am assuming that you rebase commit B onto commit A.

If there are conflicts, don’t change commit A since that represents code changes before commit B. Instead change commit B (the edits later in the history) to eliminate the conflict and to fix any bugs.

Generally, you can use merge or rebase as you like. If you are the only person on your git project, it doesn’t matter. Larger groups might have a preference. Some like rebase perhaps so it seems like everything is linear. Others prefer merge because it matches what really happened more.

Larger projects also might like to squeeze a branch into a single commit (with interactive rebase) before merging it back into the master branch (perhaps to simplify history).