[DanielShir]

I'm usually a silent reader of HN, but I can't help myself.

I definitely disagree with pretty much everything. The merits of merge commits have already been proven, and using rebases is basically rewriting history. If you want all work done precisely as happened in real life you should always use merge commits. Saved my ass a bunch of times.

Also, when something breaks after a merge, it's super easy to undo and to deal with - "Yo Don, your merge of feature X just broke feature Y. Run some tests".

I just recently moved to a new job where they love the "everything is on master" approach and that is absolutely terrible IMO. Everything is constantly broken, and developers always end up breaking builds and stepping on each others' toes. CI doesn't help in this case either because you always need to wait for some dev to fix the build. Wouldn't it be better to just undo a merge of some feature (i.e. reject the merge) and then let the dev fix that on her own time? Working just on master is just the wrong way of doing anything on a team with more than 2 people.

[krschultz]

The merits of merge commits have already been proven

That is an opinion, many people clearly disagree with it.

Using rebases is basically rewriting history

Yes. Why is that a bad thing?

If you want all work done precisely as happened in real life you should always use merge commits

Why is that important at all?

Saved my ass a bunch of times.

So has reflog.

I personally don't find any compelling rationale for why I need the git history to reflect what actually happened in time. That seems entirely incidental. Who cares if you made 10 commits on your branch or 2 or 1? Who cares if you actually wrote one part of a feature before another?

The purpose of having history is another way of communicating design intent to other people that look at the history, no more, no less. Therefore why shouldn't it be editable? It's like arguing that a typewriter and whiteout produced better books than a word processor.

I also use rebase to extract portions of the feature that are merge able before the rest. Or you can pull out sections of a branch when you are happy with them and branch off a few experiments on top of that solid base, finally merging in the one that works out best. Not employing those techniques is akin to not knowing how to refactor code.

[JanezStupar]

Indeed, from my observations people using rebase are usually working solo or in very small teams, or just like spending insane amounts of time fixing their broken code.

[Pyxl101]

The typical effective way to work with Git is to develop on master while running "git pull --rebase" regularly, and before you commit. Prefer to build up a feature as one commit, with "git commit --amend" or "git commit --fixup". Since you pull and rebase regularly, your code is closely in sync with all shipped changes, and if there are any conflicts you get to resolve them in small incremental pieces. When your change passes CR, push it.

The result is a simple, clear, linear commit history with a minimum of effort spent on branching and merging fuss. The fuss is rarely worth it. This model works for quite large teams. After a certain size, it might be better to split the package into several rather than add branching/merging complexity.

[icebraining]

Doesn't that prevent you from using commits while developing the feature?

[finishingmove]

You can make as many commits as you need on your feature branch. When you're done with the feature, you do `git pull --rebase origin master` (or whatever the main branch is) and squash your commits into one (or a few -- when it makes sense) using `git rebase -i`.

[Bahamut]

Better to squash before the rebase so you resolve conflicts once rather than x times...and hope there are no nasty merge commits to ruin the history.

[icebraining]

I know the workflow of rebasing a feature branch into one commit on master, but that doesn't sound like what Pyxl101 was talking about, regarding the use of "git commit --amend" and "git commit --fixup".

[mcv]

Rebasing is safe as long as you only do it to commits you haven't shared yet. Of course the risk is that if rebasing becomes your default, there's a risk you might also do it on a commit you already have shared.

As any time traveler knows, you need to be careful when you rewrite history.