[lmm]

Rebasing unpushed commits is ok. But I have yet to see a workflow that provides good enough guardrails to make it something you can do safely.

[saagarjha]

Protect your main branch?

[lmm]

One of the great advantages of git is being able to pull from other people's feature branches, not just master. So protecting just master isn't good enough.

[saagarjha]

Yeah so you have them go through the workflow that doesn’t ruin things, like pull requests?

[lmm]

I don't want to have to go back and forth with someone to pull their branch. I want to just be able to pull anything they've pushed.

[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.

[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.

[NewJazz]

I'll often just do a

   git reset --hard origin/branch-name

[lmm]

Right but that doesn't help if you've done your own work on top of their changes.

[from-nibly]

--force-with-lease

And only on working branches. I do this every single day.

[lmm]

Not good enough, that can mean you rebase changes that someone else has based further work on (but hasn't pushed it yet, or has pushed it to a different branch).

[from-nibly]

Why are you having people base their work off your in progress work? Git is not the issue with what you are describing.

[lmm]

> Why are you having people base their work off your in progress work?

To collaborate more closely and reduce (or get ahead of) conflicts. The whole point of using git at all is to be able to base your work off other people's in-progress work; if you're not interested in doing that then Subversion works better.