[nanis]

I too have thought about this stuff. In many instances, the correct solution depends on the context of the work being done. Are many people working on interrelated parts of the same project? Or, is there a small group of people jumping from one project to the next in any given day with multiple people collaborating in branches at the same time?

> 3.0 Rebase encourages siloed development

You need a strong culturally enforced habit of "commit early, commit often ... rebase early, rebase often, push early push often" with all development happening in branches that are visible to everyone (GitHub, GitLab etc) to avoid this.

I conceptually like a main branch with a clean straight-line history with no merge commits and clear commit messages. It takes discipline. The discipline is helped by a cultural environment where anyone can request changes in any PR, where teams, not individuals, own projects, where clarity of the commit message is equally important as the code, and where is a strong preference for short-lived branches and small PRs.

I also recommend opening a PR as soon as a single commit has been made in a branch and announcing the PR in a dedicated channel so everyone has a chance to follow the development.

This kind of thing is not going to work in every type of project in every organization, but I have developed a preference for it.

[chousuke]

Personally, I like merge commits. I often merge feature branches even if I could do a fast-forward, because the merge commit explicitly documents the set of patches that made up a feature. The question isn't really about merge vs. rebase; you should use both.

There's absolutely nothing wrong with a merge commit that says "merge feature-xyz into master"; you get a neat side path in the commit graph that contains the changes that made up xyz. Once you merge a branch however, you should delete it. Don't merge branches multiple times, and don't merge master into your feature branches.

You want to think of features as sets of individual logical changes, ie. patch series. I nearly always rewrite the commits in a branch before I merge it, to create a clean patch series. That usually means I also rebase the changes, but it's not always necessary.