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 setting yourself up for failure in the `git bisect` case: when you step back to find the source of an bug you're tracking down, the worst possible case is that you find it's introduced by a merge and not present in either of the parents. That's much more likely if your merge commits contain fix-ups of their own, which in turn is much more likely if you've got overlapping branches. If you rebase-and-merge then the merge won't have any extra changes, and if you rebase-and-fast-forward then you won't have any merge commits at all.

Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity to revisit conclusions from debugging or experiments.

You can also use merge commits to describe sub-units of work in your feature branch. Just rename your branch to some subtask and merge that into your feature branch.

edit: towards the middle of the article, the author also opines "What motivates people to rebase branches? ... I’ve come to the conclusion that it’s about vanity. Rebasing is a purely aesthetic operation. The apparently clean history appeals to us as developers, but it can’t be justified, from a technical nor functional standpoint."

So we rebase, and we merge with merge commits. This way, the developer are forced to resolve conflicts one by one on their own branch, instead of sorting out a huge pile in one go on a shared branch.

What I like about git, though, is that you can choose different approaches. Discuss in your team what you find important and use git to support that. If finding bugs with bisect is your main thing, use git in a way that makes that as easy as possible. If your have other needs, you'll have to find other ways of using the tool.

Learning and understanding the tool to use it in the best way to satisfy your needs.

This highlights a bigger issue, many people don't learn their tools well enough.

I've been teaching my fellow senior engineers how to use git the last six months because they've only been using git GUIs until then. They're terrified of merge conflicts and they often make mistakes fixing them.

I'd rather educate people and let them make their own decisions once they can understand and justify the tradeoffs.

I'll add that another annoying thing about rebasing is that if you make multiple changes to the same piece of code that conflict with changes on master, when you rebase, you have to resolve each change independently instead of only the last snapshot. However, if the changes are in different places, I like the incremental conflict resolution process of rebasing instead of the one-shot merge commit.

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

For example when I'm working on a feature I tend to do n things at once, but I then want to create logical commits which separate the work into logical unit which could be reverted etc. as necessary. If in this process I notice that I've forgotten something (or for that matter, realise later than I've introduced a bug / broken tests) I'll tend to create a patch commit for that logical unit and then `git rebase -i HEAD~n` and then fixup that patch into the original commit.

Also, whenever I'm done for the day instead of stashing I: `git commit -am "wip"; git push; git reset HEAD~1 --soft` (i.e. push my changes up to Origin to avoid any localized mishaps with my PC resulting in a loss of work). I then force push to my feature branch.

I know that both of these "change history", but as long as they're isolated to my own feature branches I see no reason to avoid doing so...

Easy, just fixup the commit that (re)introduced the dependency.

> You pretend that the commits were written today, when they were in fact written yesterday,

The author and committer dates will differ accordingly.

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.

It's a pity the author doesn't mention some of those magnificent tools. Some tools I know/use:

  CLI: tig
  GUI: gitg, qgit (Linux)

say team a does 58 commits per day has 75 team-members and team b has 126 members that are doing 187 commits per day and there's team c, d , e .... n giving non conflicting input to your codebase.

the flow in this case would be to always rebase developer specific features on non-conflicting codebase before you are allowed to pullrequest your changes to central repo. Rebasing to master or to any feature branch developer needs to work will allow them to see any conflicting changes they have made directly in their repo (rebase conflicts and a way to solve those as they know what conflicts, they have introduced the conflicts) instead of merging it together and finding out that the repo they need to PR this stuff will utterly fail cause they are lagged behind or several developers have changed the same files.

in this case rebase flow brings the shit to developer to handle and gives them knowledge that it will break. This mainly happens cause they are not having the latest version of code whereas merge strategy will merge in the conflict and send it to others to discover that thy can't merge any more cause of other developers conflicts.

Merge strategy is not suitable in case where code is edited rapidly daily and some features take , weeks, years, are to be included. Whereas rebase strategy ensures that every developer will always send you changes that are not conflicting with up to date version of whatever is versioned.

Also, don't even get me started on `git revert`ing merge commits... Down that road lies sadness and disillusion.

It's also kind of a problem if underlying parts of the system that you depend on either are churning that much without that being communicated or if they have poorly-defined interfaces and are prone to accidentally breaking things that users depend on.

It's not entirely clear, but there may be some testing gaps too if bugs weren't found.

Maybe merge-based workflow helps a bit but it seems like the pain would still be there regardless.

Thanks to all others who explained technically what upset me so much.

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