With git rebase, should I pretend that certain things didn't happen when resolving conflicts?

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).

Answer 2

In my opinion, it shouldn't matter. When you rebase commits it is usually because you have completed some peice of functionality or reached some sort of milestone and want to "rewrite" the history. In essence, you are more interested on a high level overview of what you did rather than going into detail.

If you want to highlight specific code changes as part of the rebase then put them in the commit message.

Answer 3

"if so, don't I miss out on important context about the evolution of the code"

Well yes, but that's the point of a rebase. A rebase rewrites history to how you wish it had been :-)

You don't mention above where your commits are, on the same branch being rebaseed with an interactive rebase or in separate branches.

I'll assume separate branches, the point of doing a rebase is that you are reordering the commits on one branch to be appended to the end of the other branch, if a conflict now occurs then you need to amend the commit as if it had been coded after the other commit, if that means a function doesn't see the light of day, then so be it.

If the temporal order of the commits is important to you for context, merge instead.