Jarrod Spillers Blog - Latest Comments in git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

miguel — Mon, 24 Jun 2013 23:34:49 -0000

while i know what you meant, it doesn't make cttekin wrong. the argument is git gives you opportunities to shoot yourself in the foot while everyone runs around saying "blast away! shoot as many bullets as you want! git's got you." This, coupled with the shockingly bad advice gives you when encountering errors (first time i used it, all i was told to do was "git push" when I finished my code, i tried and it told me i had to say "git pull" before i could push... so blindly i listened and lost a whole days work XD ) makes it hard for me to blame noobs for certain mistakes... anyways THANK YOU SO MUCH FOR THIS ARTICLE

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

nacengineer — Wed, 10 Apr 2013 15:24:49 -0000

FWIW to be fair this wasn't git. Its the same as doing "rm -rf" on a directory in linux. You can blame Linux all you want but "With great power, comes great responsibility". Also due to the distributed nature of git the chances are very high someone else has those commits in their local repo.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Sam Gleske — Wed, 10 Apr 2013 12:13:39 -0000

Correct, the commits are still hanging around. As long as you don't run a git garbage collect (git gc) then you should be able to recover any "lost commits" which aren't referenced within any branch and just hanging out in the ether... Here's more about garbage collecting that provides a decent description in the comments.

http://stackoverflow.com/qu...

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

kavyak — Mon, 25 Mar 2013 02:56:47 -0000

That explains many of my questions..thanks!!

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Steven J. Dale — Thu, 14 Mar 2013 11:03:30 -0000

The visual style of this post is great. Thanks for taking time to do that. Often git related posts are missing this, and are confusing to follow.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

David Tanner — Thu, 28 Feb 2013 17:56:10 -0000

We have also lost commits because we were all sharing the master branch. It is always hard to transition from one methodology to another, and sometimes any excuse will do. Hence the very vocal fear I am sure.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Igor Ganapolsky — Thu, 14 Feb 2013 11:25:06 -0000

I agree with Cttekin. While courage is paramount to using Git, you can easily get confused and not know what git commands to execute next when you rebase another developer's branch.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Asymptote — Thu, 14 Feb 2013 09:16:32 -0000

Minor nit: "pull –rebase" should be "pull --rebase". That is, two normal dashes, not one extra-wide "em" dash.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Ashish Sajwan — Wed, 13 Feb 2013 07:38:00 -0000

had enuf of tutorials/theories...time to do it in real...

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Cttekin — Thu, 31 Jan 2013 22:40:04 -0000

Actually we did lose commits because of rebase, because of the exact reasons author describes.
When a shared branch is rebased and pushed, other people working on the same branch get orphaned. They try to push their changes, and git doesn't let them and says "their branch is diverged" - At this point, most new developers don't understand what this means, and just force push their local changes - this push actually is the evil and makes the changes get lost...
Follow the author's last advice - never rebase a shared branch.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Guest — Mon, 03 Dec 2012 14:33:46 -0000

Thanks, this is exactly the explanation I needed.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Enno — Wed, 21 Nov 2012 17:26:46 -0000

I'm just trying to understand the way git works, how to use it and – especially – why. If often read "Don’t rebase branches you have shared with another developer." I'm probably not getting it right, but I hope you can help me with this.

The master branch is shared with other developers, of course. Since I shouldn't rebase branches I have shared with other developers, I should never use rebase on master branch, right?

Well, I know it's not right. You even showed an example, that explains rebasing on the master branch. But I'm confused. 'Only non-shared branches' seems to be wrong criteria for using rebase, since the master is shared.

Where does my thinking go wrong?

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Qun — Tue, 13 Nov 2012 04:20:13 -0000

Both are helpful for me.
From the post, I know where I'm lost.
From Eric's comment, I know my way back.
Thank you.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

ak — Wed, 07 Nov 2012 13:43:54 -0000

A little misleading... rebase doesn't uncommit anything, all your original commits are still there if you want to go back. Rebase just creates brand-new commits that emulate what you did in the old commits, only this time starting from the newly updated base.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Bob Kerns — Sun, 23 Sep 2012 02:54:32 -0000

I'd write up MY own tutorial, but I don't think I could do as good a job, so I'll settle for criticizing yours... :)

Seriously, though, nice post, but buried in Eric's criticism is a useful point for teaching Git.

Courage.

It's possible to get yourself pretty confused with Git at first. But it is *really* hard to lose anything. Rebasing won't do it. Git generally remembers anything it has ever seen, whether it's part of the current history or not. If you did 'git add MyNewWonder.java' on a first draft, never committed, then blew it away -- Git remembers. Git will remember in that case for 30 days -- and yes, I've recovered files that way.

Screw up a rebase? Do git reflog, find a state you like, and do 'git reset --hard <sha>' and you're teleported right back.

With Subversion, ClearCase, and the like, you're making a record of every stumble you make -- or else you're only capturing what you want others to see.

With Git, you capture anything and everything -- and then you organize it to tell a clear and accurate story, and push that.

The result is the difference between a log and a novel. Yet you've got all those notes and drafts saved away that you'd never dare commit to SVN.

With Git, you can play around with new characters, and even reorder the plot, all in the safety of your own garret, until it's time to send it off to the publisher.You don't dare do that sort of thing with SVN. It's not your post that scared Eric's coworkers. Not really. It's their experience with SVN, and I think we're doing new users a favor by encouraging them to experiment freely.I wish I'd had that advice when I'd started out.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Kev — Tue, 04 Sep 2012 05:32:07 -0000

Hi, Could you please explain this a bit more "Also, the picture is wrong. In the "after" picture, the red and blue commit should be side by side above the black commit, and the green commit should be above them. The black commit is, both before and after, the parent of the red and blue and the green commit is the child of the red and blue.

Thanks
"

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Kev — Mon, 03 Sep 2012 13:43:01 -0000

Finally an article which suggests what to use when. Xcellent xplanation.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Jrod — Mon, 13 Aug 2012 10:33:46 -0000

In the amount of time you just spent criticizing my post you could have written up a wonderfully thoughtful tutorial of your own. Sorry for scaring your developers... hopefully they are not still hiding under their cubicles.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Eric Pabst — Mon, 13 Aug 2012 08:49:42 -0000

This article unnecessarily scared some of the developers at our organization who are transitioning from subversion.

From what I have seen, once developers become accustomed to Git, Git eliminates fear. I commit (locally) much more frequently since there is no risk; I understand what I'm pushing remotely before I do so; I can rebase or merge remote changes according to the need; I can easily share commits with other developers for peer review, etc.

From reading your article it makes it sound like the commits are at risk of being lost when using rebase, like as if something goes wrong such as your computer crashing or a merge conflict goes awry that the commits could be lost. That is not the case. git preserve the branch you were on until the rebase successfully completes. In the meantime you can always do a "git rebase --abort" to undo the rebase. After it commits, you can use git reflog to see all of the commits that were supposedly "lost" or "uncommitted" from any recent rebase (since the last garbage collection which for me is less than once a month). You can easily create a branch for any of those commits using "git branch foo <sha1>" and look at it, switch to it, etc. I have NEVER lost a single commit doing a rebase after over 2 years of using git heavily. When there are no conflicts (usually the case) then everything happens totally smoothly. When there is a conflict, either I easily resolve it or else I "git rebase --abort" and react to the kind of conflict I got such as reordering or squashing the commits using (git rebase --interactive). If several of my commits conflict, I may use "git merge" so that I only have to resolve conflicts once, in which case the noise in the history is worth it.

I don't think that it was clear to git newbies that the only time you're recommending not using git rebase is to rebase onto someone else's commit that has not been pushed to origin. In our organization, that is such a corner case that it hasn't even come up in the last year for me. The only reason I can see to do this is if I am really confident that the commits will be pushed to origin/master soon. When they are not my commits, it's much more likely that the author will push them there before I gain such confidence. The very fact that he hasn't pushed them to origin/master implies that he isn't confident, so why should I be? Even if I thought his changes were sound, he could still squash other changes into those commits for tidiness or other reasons at which point I'd have to rebase onto those new commits before I could push. Actually, unless he gave me permission to push his changes, I couldn't push to origin/master at all until he pushed his. Since I hate waiting, I'm VERY unlikely to do that. I'd just assume work on something else that doesn't cause me to be blocked by another developer.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Eun Woo Song — Mon, 16 Apr 2012 14:22:25 -0000

very well explained! Thank you!

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Anthony Your — Sat, 03 Mar 2012 09:07:09 -0000

excellent explanation for those coming from other systems.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Bryan Henderson — Tue, 29 Nov 2011 18:17:52 -0000

Also, the picture is wrong. In the "after" picture, the red and blue commit should be side by side above the black commit, and the green commit should be above them. The black commit is, both before and after, the parent of the red and blue and the green commit is the child of the red and blue.

"empty" is sloppy terminology anyway, because commits don't contain things - they kind of look like what are patches in other code control systems, but a Git commit is just metadata. The merge commit may be "empty" in the sense that the files you modified may exhibit no difference (git diff) between the red and green code levels.

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

Aleksandar Kostadinov — Sat, 10 Sep 2011 15:29:57 -0000

Thanks, as far as I understand you should never rebase a branch shared with another person, because initial commits disappear and get replaced with brand new ones. Then it becomes a hell to merge with the person that has pulled from that branch because he will have your disappeared commits and git will look at them as new ones although they have been actually superseded. Correct?

P.S. as far as I'm reading, general recommendation is to follow established workflows and NOT EVER TRY TO BE SMART if you are not :)

[1] Disclaimer: I'm learning git today

Re: git merge vs git rebase: Avoiding Rebase Hell - Jarrod Spillers

jvlppm — Sun, 17 Apr 2011 17:06:16 -0000

They're not empty commits, the merge commit have both codes merged