Hacker News Reader

Comment by d2p | Hacker News Reader

It's fairly common to do `git push --force` (or hopefully `--force-with-lease`) after operations like rebasing. This overwrites the remote history, so can easily lose work. Many people set some branches as protected, so they can't be force-pushed over accidentally.

View on HN

Isn't it a pretty bad idea to have a workflow which involves --force? If it's to keep history tidy, why not just develop on a separate branch and do squash merges?

I'll admit I haven't used git in extremely complex circumstances, but I've always viewed --force as something you do only if you really mess up, such as pushing secrets (and that should obviously be in addition to invalidating those keys and generating new ones).

the rebase strategy involves force-pushing to your topic branch and then ff-merging to master (or develop, or whatever). some people love it, some hate it, but force pushing is a necessary part of the strategy if the master branch has had new commits since you created your branch.

yes, force pushing can be dangerous, which is why (when you use the rebase strategy) you usually protect certain branches. force-pushing should only happen on your short-lived topic branches.

Working on a separate branch may still require periodically bringing in changes from master (eg. to resolve conflicts). The options are either a) a merge commit or b) a rebase. A rebase will require a `--force` push. Some people prefer merges, but personally I prefer rebasing - I like to keep my full history even when merging back to master, since it's not a lot of extra effort and it can be useful when tracking down issues in old code :)

Its not and it shouldn't.

I do often rebase on my local branch but i will communicate a force push on master to the whole team and will disable protection temporarily.

If thats the only reason, he should overthink his workflow.

People aren't talking about force pushing to master, they're talking about force pushing to another branch, but with master unprotected, and therefore, by accident, force pushing to master as well.

Isn't that situation only possible if config.push is set to matching? As far as I know, it's been set to simple by default since Git 2.0 [0].

[0] https://git-scm.com/docs/git-config#Documentation/git-config...

> Its not

It's not common to rebase?

> i will communicate a force push on master to the whole team and will disable protection temporarily

Isn't that exactly what this point was about? You have branch protection enabled for master because you think it's a good idea to avoid accidental force-pushes. These comments were exactly about not having the ability to protect branches.

I'm not really sure what you're arguing for/against.

Reply on news.ycombinator.com