
Merging vs. Rebasing - nns
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/
======
barrkel
Clean project history is overrated.

If you work on a sizeable team with code review before merge workflow, the tip
of the repository will be moving faster than is pleasant or safe to rebase,
and every so often, commits will exist in multiple different branches (in
order to prevent blocking development pending a code review). You do not want
to be rebasing commits such that they appear in multiple different branches
with different hashes etc. It's a recipe for pain. And being blocked until
code is reviewed and merged is hardly more productive.

Even working like this, git bisect works just as well to find a commit, and
git log on an individual file works just as poorly as it always does (e.g.
changes in merge conflict resolution are hidden by default).

Rebase if the commits only exist in your local repo. That's fine. But no more.

~~~
sdegutis
> _Clean project history is overrated._

I go back and forth on this issue.

On one hand, I like having commits that do one thing. Makes it easier to
"read" a project's history, to revert things, to track down bug introductions.

On the other hand, I like having a history of the mess of how I actually
implemented something, because it's more accurate and more detailed, both of
which help when I go all _DETECTIVE-MODE: ACTIVATE_.

But on the _other_ hand, the mess often includes such uselessly awful commit
messages, and lots of terrible code that only existed for like 2 hours until I
realized it was the wrong way to do it, and scrapped it. That's kind of a red
earring.

So I don't really have a firm opinion on it anymore. I just go with whatever I
feel that day. That said, I'm a team of 1 and have been for about 4 years, so
it doesn't matter too much in my case.

~~~
AlexCoventry

      > I'm a team of 1 and have been for about 4 years
    

What kind of work do you do?

~~~
sdegutis
I work full time on a pretty standard low traffic online store web app written
entirely in Clojure.

~~~
AlexCoventry
Ah! I remember you from #clojure. Been reading some Uncle Bob recently, turned
on to him partly because I remember you speaking about him.

------
jcoder
Rebasing isn't just about a clean project history, IMO. I'd much rather find
out about a merge conflict I've created when applying a small commit to the
tip of master, than when smashing two development histories together.

~~~
t1amat
There is nothing stopping you from merging the mainline history into your
feature branch to pull in the latest changes. In fact you should be doing this
every-so-often for any long-lived feature branch, but always before merging
into the mainline.

~~~
jcoder
I do integrate every so often. By fetching master and rebasing on it ;)

------
breatheoften
For our (smallish, fast moving) team we disabled history rewrites on all
branches on the server, have all the developers manage their git workflow
using the (very awesome) osx app called gitup, and have everybody rebase and
resolve conflicts before pushing. We always rebase and only merge in unusual
circumstances where preserving the merge conflict resolution decisions might
make sense (which almost never occurs). Everybody on our team including very
junior developers and designers are able to quickly pick up this workflow and
almost never have problems - and when they do it's always obvious that they
should get help from someone -- and typically this is exactly the scenario
where some analysis is needed -- so its a good use of time for a second pair
of eyes.

~~~
vkjv
I'd be interested to know how this scales on a larger team. Looking at the
number of open PRs on some of our repos, I would guess doing this in a larger
organization would cause an unnecessary amount of busy work when everyone
scrambles to rebase after each merge.

~~~
breatheoften
I think it would scale pretty far based on my experience with the process on
our team. I'd see more blockers to scaling team size coming more from other
factors rather than the merge strategy -- things like the quality of tests and
probability of problematic merge conflicts -- which I think would depend
ultimately more on the code organization/team-member communication than the
merge strategy.

I think Facebook uses a souped up version of this strategy (based on how I
interpret their presentation on it anyway). It seems like the engineer ships
off a commit, and then it goes into a review branch where it gets
automatically rebased against master continuously while waiting for review.
When it passes review it goes onto master as the newest commit -- if a
conflict happens before the review completes or during the final rebase then
the engineer is notified to resolve the conflict and push again -- I think
review needs to happen again in this case -- but it makes sense to do so as
the first review was done without awareness of the change that caused the
conflict ... I'm sure I don't describe their actual process accurately but I
think it something along these lines ...

------
aokyler
Where I work we merge with the no fast forward option - this keeps an accurate
git feature topology where merges are represented as their own commit. We've
found it gives us the best of best worlds: adding clarity/readability to the
history while avoiding problematic rebases.

I haven't personally really noticed any downsides with that approach, can
anyone else think of any?

------
VoiceOfWisdom
We've started using mercurial evolve at my company. It feels like the best of
both worlds. I can rebase and get all the nice clean history I want, but under
the hood the original work is still there. It also allows for safely editing
public history, without getting into a weird state where you edited a commit
that someone else committed on top of.

------
leekh
rebase for lyfe! Just don't force push on master.

~~~
hashkb
I force push master when I know it's safe. If you aren't confident, don't do
it. Don't piss off your coworkers. But this dogma is ridiculous.

~~~
epmatsw
But how can you know it's safe in a collaborative project? What if someone
else merges a PR right before you push?

~~~
TheCoelacanth
\--force-with-lease instead of --force. It does the same thing as force but
checks to make sure the branch hasn't changed since you fetched it. Still very
likely to piss off your co-workers, though.

~~~
hashkb
This.

------
dahart
I quite like that this outlines the benefits of both non-judgementally, and
provides guidelines about when to use each in different situations. I've seen
too many discussions where people argue that one is better than the other,
when as I see it, they are two different tools and they both have legitimate
uses. There's a little overlap, a few cases where your own preferences can
allow you to choose freely, but by and large they don't really contend with
each other. You can largely have a clean and accurate history _and_ a feature
branch workflow with PRs, while using both rebasing and merging.

------
kentosi
Did anyone else to the following when they were new to git and had to rebase?
1 - Rebase. If no conflicts, great! otherwise, 2 - Abort rebase and merge.

:-)

When I started using git I remembered feeling overwhelmed by rebase because
with a merge you only resolved conflicts once, whereas with a rebase you had
to continually fix conflicts without knowing when it would end.

It took me a while to finally understand how rebase properly worked and I can
finally use it correctly now.

------
mcguire
Note: if you want to bring upstream changes into your fork, as in [1], use a
rebase instead of a merge. Otherwise, you will be fighting with merge commits
from now on.

[1] [https://help.github.com/articles/syncing-a-
fork/](https://help.github.com/articles/syncing-a-fork/)

------
epmatsw
Not sure how I feel about the not rebasing PRs rule, especially with CI on PRs
becoming more common. I'd much rather have a PR get rebased than have an extra
"Fix whitespace to satisfy linter" commit.

~~~
wwalser
It says to merge PRs but also mentions that rebasing the branch being pulled
first is a good practice. This would be a fast forward merge, effectively
serving the same purpose as a rebase, no?

As for the example of a "linter" commit, I feel that lends itself more
naturally to teaching git commit, git commit --amend, or rewriting history.
Which the OP is not about.

------
hashkb
This article has been written a million times already. It's another holy war.
Vim, spaces, rebase. The sad part is that IMO merge people are on that side
because they are afraid of rebase or don't understand it.

~~~
tapan_k
Why is this downvoted? (serious question)

Where can I find the "code of conduct" for HN?

~~~
dahart
One can only speculate on why either downvotes or upvotes occur, but it's
fairly safe to assume someone disagreed with something said in the comment.

The comment complains that the article provides nothing new and is feeding the
rebase-vs-merge holy war. I would disagree with that, and it suggests to me
the commenter didn't read the article. It's usually considered bad form to
make comments on the headline without reading the article. This article in
particular steers clear of all the holy war aspects of the rebase-vs-merge
debate. I didn't downvote, but I speculate that's why it got downvoted.

In the HN FAQ is a link to guidelines:
[https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html)
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

One of which is "Please resist commenting about being downvoted. It never does
any good, and it makes boring reading." which is why you'll rarely see
discussions about downvotes, and why usually speculation is all you get. ;)

~~~
hashkb
I read it. I thought it was a blog post and not part of their guide; so I can
take back the timeliness/repetitive part of my complaint.

I'm not complaining that it's feeding the holy war, just pointing out that it
is one. My complaint is that we try to solve these issues with dogma, rather
than expecting everyone to have a strong understanding of git, at which point
all of the problems just sort of stop happening.

~~~
dahart
Then I'm another example in a long line of examples that demonstrate that
speculation doesn't always produce high quality results.

I've seen the holy war too, and I was impressed that this article took special
care to stay completely out of it. I didn't see any dogma at all in this case,
I saw helpful suggestions educating people about git and about when to make
the call.

~~~
hashkb
Whatever, speculation is WAY more fun than empathy. (-:

