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

Don't use Git rebase

medium.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Don't use Git rebase

#61

Post by nlawalker »

jmull wrote: post #48
ddevault wrote: post #32

There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.

> You should use it the other way around Yes, that's how I thought it was meant to be used. (At first I got confused reading this article because I assumed that's what they were talking about too.)

Now I'm confused... is that not what the author is doing?

>> the feature branch is reset to master, after which the commits are re-applied on top of feature

Is that not rebasing 'feature' on top of 'master'?

Re: Don't use Git rebase

#62

Post by rsp1984 »

There are many magnificent tools that can analyse and visualise complex Git history, both GUI- and CLI-based.

Just tell me one. All git tools I know do such a terrible job at this.

Re: Don't use Git rebase

#63

Post by kstenerud »

andrewaylett wrote: post #24

`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…

This would probably be ok for smaller projects. My current codebase takes an hour and a half to build, so a rebase to master will involve anywhere from 10 to 100 rebuilds (1-10 days worth), not to mention the whole process stopping on each merge conflict, which will stretch out the rebase time even more as Murphy's Law will place every conflict outside of working hours.

Re: Don't use Git rebase

#64

Post by rout39574 »

baq wrote: post #39
rout39574 wrote: post #12

Earlier quoted context omitted.

I would think squash a poor default policy; it destroys information in the granularity of commit, and in the commit messages.

Nothing is lost if there's no information there in the first place.

I agree; if your commits are poorly planned and poorly commented, then I don't see any particular reason to avoid squashing them.

But if your commits are poorly planned and commented, I would recommend trying to improve them, rather than reveling in the fact. ;)

Re: Don't use Git rebase

#65

Post by rout39574 »

rsp1984 wrote: post #62

There are many magnificent tools that can analyse and visualise complex Git history, both GUI- and CLI-based. Just tell me one. All git tools I know do such a terrible job at this.

Any examples of what you find terrible?

Ever tried magit? I don't know if you'd find it terrible, I find it not so bad.

Re: Don't use Git rebase

#66

Post by skybrian »

ddevault wrote: post #32

There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.

Neat! You get your choice of linear histories depending on how much detail you want.

But if you use GitHub pull requests and squash your commits, that seems almost the same? The history is there, just not in the repo.

Re: Don't use Git rebase

#67

Post by Sir_Cmpwn »

skybrian wrote: post #66
ddevault wrote: post #32

There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.

Neat! You get your choice of linear histories depending on how much detail you want. But if you use GitHub pull requests and squash your commits, that seems almost the same? The history is there, just not in the repo.

I don't like that approach because the upstream history should be authoritative and I don't like to model my workflow around GitHub.

Re: Don't use Git rebase

#68

Post by jibberia »

I use rebase because I often have long-running feature branches (maybe for a couple of weeks) and I want to keep up with changes on master. When I was new to git, I used to merge master into feature branches to achieve the same effect, but my pull requests were littered with commits already made to master.

Is there a better way to keep feature branches updated with changes on master?

Re: Don't use Git rebase

#69

Post by chrisjshull »

I'm really surprised no one (article included) has brought up the "Golden Rule of Rebase" (https://www.google.com/search?q=golden+rule+of+rebase), which boils down to "never rebase a shared branch". Git is an extremely powerful tool for collaboration, and it's frustrating when I see that undermined.

Re: Don't use Git rebase

#70

Post by nunez »

Rebase is incredibly useful for me because I commit on every save and squash my commits before submitting for PRs (if working on a team). I commit on every save for three reasons:

1. I can easily undo small mistakes this way,

2. It makes it easy for me to pick up what I've done the last time I worked with that codebase, and

3. It makes it easier for me to tell a comprehensive story when I'm ready to submit my PR.

That said, I do see the authors point about rebasing onto a branch with dependencies.

Post reply on HN