Don't use Git rebase

Re:Don't use Git rebase by ddevault on Saturday September 16, 2017 @06:54AM (#15264041)

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.

[ Parent | on HN ]

Re:Don't use Git rebase by gutnor on Saturday September 16, 2017 @07:55AM (#15264213)

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.

[ Parent | on HN ]

Re:Don't use Git rebase by keeperofdakeys on Saturday September 16, 2017 @08:22AM (#15264320)

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.

[ Parent | on HN ]

Re:Don't use Git rebase by oddlyaromatic on Saturday September 16, 2017 @08:50AM (#15264424)

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

[ Parent | on HN ]

Re:Don't use Git rebase by jmull on Saturday September 16, 2017 @08:14AM (#15264285)

> 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.)

[ Parent | on HN ]

Re:Don't use Git rebase by nlawalker on Saturday September 16, 2017 @09:06AM (#15264481)

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

[ Parent | on HN ]

Re:Don't use Git rebase by fredrikmorken on Sunday September 17, 2017 @09:06AM (#15269420)

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

[ Parent | on HN ]

Re:Don't use Git rebase by skybrian on Saturday September 16, 2017 @11:23AM (#15265023)

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.

[ Parent | on HN ]

Re:Don't use Git rebase by Sir_Cmpwn on Saturday September 16, 2017 @11:40AM (#15265111)

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

[ Parent | on HN ]

Re:Don't use Git rebase by trumbitta2 on Saturday September 16, 2017 @08:12AM (#15264276)

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

[ Parent | on HN ]