1

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?

Aaron
  • 619
  • 6
  • 15

3 Answers3

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

ronalchn
  • 12,225
  • 10
  • 51
  • 61
  • I branched from origin/master, then made commit A, then made commit B. Commit A added a function that conflicts and commit B removes the function. If I leave commit A as-is (i.e. resolve the conflict by continuing to add the function in A, only to have it removed in commit B) then aren't I going to have to keep re-resolving that same conflict every time I rebase? – Aaron Aug 19 '12 at 01:03
  • no - because you would already have fixed it for the B branch, the B branch shouldn't conflict again - but it might for another branch (eg. C) which was not yet rebased to A or its descendants – ronalchn Aug 19 '12 at 01:12
  • Well, it's "fixed" in the sense that the subsequent commit removes the conflicting function, but why isn't the first commit going to conflict every time I rebase? After all, it will keep trying to add a function that conflicts. Does git somehow remember how I resolved the conflict the first time I rebased? Sorry if my question isn't clear, happy to try to clarify. – Aaron Aug 19 '12 at 01:18
  • (note that A and B are commits, not branches.) – Aaron Aug 19 '12 at 01:19
  • If you --amend commit A, it will conflict again. But generally, that's not what happens, you will create a new commit after A (on branch A?), and when you rebase B onto A's descendant, git will know that you removed the function in B. It is as if you took the diff of what B does, and reapply it to whatever you commit on top of – ronalchn Aug 19 '12 at 01:24
  • Would you mind weighing in on http://stackoverflow.com/questions/12023464/is-it-bad-to-git-rebase-a-local-branch-off-of-another-branch-that-is-itself-reba? I think it might be the cause of my confusion/problems. Thank you! – Aaron Aug 19 '12 at 01:33
0

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.

James
  • 80,725
  • 18
  • 167
  • 237
  • Hmm. I have been using `git pull --rebase` on a daily basis to keep up to date with what other developers are doing on origin/master. Is that a bad workflow? – Aaron Aug 19 '12 at 01:08
  • well, it simplifies the overall history when you eventually merge your changes back into master, so no it isn't bad. Note that even if you merge origin into your branch, the same conflicts will appear. BTW, if you are working with a lot of other developers, it's generally better not to work on your master branch, and use topic branches (so that the master branch reflects origin) – ronalchn Aug 19 '12 at 01:13
0

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

Tim Jarvis
  • 18,465
  • 9
  • 55
  • 92