Hacker News Reader

Comment by ddevault | Hacker News Reader

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.

View on HN

Or well, simply use both. Feature branch, use merge - the feature is an important artefact, and there it is important for the history to show it.

Bug Fix branch, working on a shared branch, use rebase. The branching in those case is a side effect the exact time two colleague committed on the same branch. There is no information you gather from that, it is just a technical blip in the history.

Not quite sure the obsession people have in using only 50% of the tool they have because the other 50% could be misused.

Similarly, digging for a bug in several hundred commits is going to be shit. Hindsight is very deceptive with bug hunting - they always hide in plain sight, if you know where it is, it is easy to imagine "oh, I would have seen it immediately with a merge". Maybe, probably not.

You see that of that kind of overreaction in Management. There is a bug in production, we must introduce more testing, or more testing phase, or change the way we design the around that single experience. But sometimes, bugs just happen.

Rebases and merges don't work well together. By default, git rebase will get rid of merge commits. While there is an option to preserve merges (-p), it can lead to some strange behaviour while doing an interactive rebase - see BUGS section in git-rebase man page for more details.

I'd also argue that merge and rebase represent fundamental differences in what commits mean. The former being commits are history, and the latter being commits are features.

I'm a pretty basic got user, just wanted to say this was a really useful distinction for me to read.

> 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'?

Author of the article here. Yes, this is what I am describing. Sir_Cmpwn is describing the same workflow as I am.

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.

Yep, I use it to keep my feature branch up to date, too.

Reply on news.ycombinator.com