[iainmerrick]

Isn't "protect your main branch" still the answer to this?

Your two feature branches would be unprotected so you can merge away if you like. When one of you wants to commit something to master, that's when you'd check for dodgy merges.

Also, "git cherry-pick" is a good alternative to merging for this use case.

[otherjason]

Protecting the main branch is definitely a good practice, but the other potential hazard is:

- Having a developer on your team that rebases their own feature branch

- Then tries to "git push", only for it to be rejected since a force push is required

- Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out previously

Our team uses merges because they are safe from this kind of problem, although a rebase workflow would have cleaner history. I wish that "git push --force" would not push all branches by default, and just fail unless a (remote, branch) pair or --all is given.

[danaris]

> - Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out previously

This is (part of) why, for most common operations, I use a Git GUI (SourceTree). Force pushing all branches can only be done by very explicitly selecting them all and initiating a force push; the default when pushing is to push only the currently active branch.

It's also overall much clearer and more intuitive to use than the Git CLI. I use it when I have to—there are things that I can't do through SourceTree, and a few things that are complicated enough that I just want to be 100% sure I know exactly what's happening—but for 99% of the Git operations I do, it handles them perfectly and without any worry that I've mistyped something or forgotten to specify a branch.

[lmm]

> Isn't "protect your main branch" still the answer to this?

No, the feature branches need to be protected or something, to enforce that they only rebase locally and don't rebase the parts that I've merged into my branch (and vice versa).

> Also, "git cherry-pick" is a good alternative to merging for this use case.

No it isn't, it means you get multiple unrelated commits for the same change, which causes conflicts and can be disastrous if a commit is deliberately reverted.