4 ms·

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 easil

by d2p 8y ago

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.

sigi45 8y ago
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.
- swish_bob 8y ago
  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.
  - karlding 8y ago
    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.txt-pushdefault https://git-scm.com/docs/git-config#Documentation/git-config...
- d2p 8y ago
  > 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.
mort96 8y ago
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).
- woodrowbarlow 8y ago
  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.
- d2p 8y ago
  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 :)

by d2p 8y ago

sigi45 8y ago

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.

swish_bob 8y ago
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.
- karlding 8y ago
  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.txt-pushdefault https://git-scm.com/docs/git-config#Documentation/git-config...
d2p 8y ago
> 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.

mort96 8y ago

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

woodrowbarlow 8y ago
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.
d2p 8y ago
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 :)