from Hacker News

A Simple Explanation for Git Rebase

by bradrobertson on 4/16/14, 2:52 AM with 16 comments

• by golergka on 4/16/14, 5:26 AM

  I tended to use git rebase constantly before pushing, until I realized how toxic it really is.

  In the original commit before rebase everything seemed to be working; but someone changed something else in the code you were relying on without creating a direct conflict, and now all your rebased commits crash and burn. What's worse, you discover it much later, when original commits are long gone, and instead of one merge commit being the easy traceable breaking point, you now don't even quite remember which exact commits were rebased and have to check EVERYTHING.

  Or, and with merge commit you could've easily just check it right there with simple tests before committing — no such convenient option for rebase.

  The thing is, it's a leaky abstraction. Rebase workflow tries to present things simpler then they really are, and you end up paying a price for it.

• by tunesmith on 4/16/14, 7:12 AM

  I just never find rebase very relevant because we'll have team members collaborate on the same branch. If you want to collaborate on an in-progress story that has its own branch, you have to push your commits. You might be able to rebase on any commits you push into the branch, but when it comes time to merge the branch into the main line (which might have received several commits in the meantime), you have to stick with the timeline of those pushes, so you lose much of the benefit of rebase.

  Not sure why the author says that is weird - I can't think of an alternative if people are truly collaborating or pairing on a feature.

• by azinman2 on 4/16/14, 3:46 AM

  Thank you! I've always found this confusing and avoided it in my workflow. Assuming this explanation is correct, it makes a lot of sense and gives me a better workflow!

  Are there any other useful ways to use git for a small team outside of pull and rebase? One thing that's bugged me is undoing (possibly partially) previous pushed commits while keeping everything past.

• by klochner on 4/16/14, 6:07 AM

  simple but unenlightening - I guess you hope no one asks you what's really happening and just give up if you get a conflict.

  It's not that complicated - rebase applies your commits to another branch as if they were patches. Interactive rebase gives you the option of re-ordering/removing/editing those patches before they're applied.

• by middleclick on 4/16/14, 4:19 AM

  Can anyone document a simple workflow with three branches: main (public), development (public) and feature (private).