Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Simple Explanation for Git Rebase

infinitemonkeys.influitive.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: A Simple Explanation for Git Rebase

#11

Post by mickeyp »

golergka wrote: post #6

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…

Fast-forwarding your commits on top of master/develop was never a good idea.

Having a merge marker showing where the commits came from and the branch name is incredibly useful, but that's not a black mark against rebase -- only your organisation's lack of diligence to following a set of rules.

If you use something like Github's pull request system it will always create a merge commit when you merge a pull request; as it should be.

One thing you can do whilst rebasing to ensure the rebasing doesn't break against the master branch you're rebasing against is calling out to a shell command -- rebase will let you do this -- to run your unit tests between each rebase commit.

Re: A Simple Explanation for Git Rebase

#12

Post by golergka »

_ouxp wrote: post #7
golergka wrote: post #6

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…

If you have a reasonably good+fast test suite and you integrate often, this isn't a huge deal. Just run your tests after using rebase. If you have a failure, having a straight-line history makes it easier to do a bisect with your failing test and find the point of failure. Unrelated to your issue with git rebase, but addressing another common complaint, git rerere allows git to remember and reuse previous conflict re…

Unfortunately, I work on a project that (due to a various reasons) doesn't have any kind of automated testing, and it would be pretty hard to implement it. (But possible, and we definitely should do it in the future).

But thanks for git rerere! I've never heard about it.

Re: A Simple Explanation for Git Rebase

#13

Post by bradrobertson »

klochner wrote: post #8

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.

Good call I'll update the post to mention resolving commits. This was not intended to enlighten those who already know how rebase works.

Re: A Simple Explanation for Git Rebase

#15

Post by wahnfrieden »

mickeyp wrote: post #11
golergka wrote: post #6

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…

Fast-forwarding your commits on top of master/develop was never a good idea. Having a merge marker showing where the commits came from and the branch name is incredibly useful, but that's not a black mark against rebase -- only your organisation's lack of diligence to following a set of rules. If you use something like Github's pull request system it will always create a merge commit when you merge a pull request; as…

No one's arguing for rebasing commits that have already been pushed to remote.

Nice shell tip!

Re: A Simple Explanation for Git Rebase

#17

Post by dcadenas »

tunesmith wrote: post #10

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…

That's true but using branches is not always a good idea specially if you want to collaborate in big projects and have strong communication with your team.

Master can be used as a chat room (substitute english with code) and leave branches for very specific cases when that doesn't work. That's basically doing continuous integration. If you prefer, you can think of it as if you are still having branches with one commit each ;).

The important thing for CI is being sure that each commit is either hidden (through a feature toggle maybe?) or it doesn't break anything.

Post reply on HN