4 ms·

It's not unreasonable to force push a branch. Anytime you've rebased but already pushed you would need to do so. I've worked on an open source project where eve

It's not unreasonable to force push a branch. Anytime you've rebased but already pushed you would need to do so. I've worked on an open source project where every commit was required to pass all the tests, so if you submitted a PR that had any commit fail CI, you would have to alter history and force push. I also just like pushing to a branch on Github, even if I might rebase later. Circle CI is triggered through Github, so it's nice to have that triggered for me. Our staging servers (production data, your branch's code) are deployed from Github branches as well. Plus looking at diffs on Github is really helpful for me to spot errors—I'm not sure if it's the context switch away from my text editor, Github's diff UI, or what, but it works for me.

deleted 13y ago
[deleted]
ori_b 13y ago
> Anytime you've rebased but already pushed you would need to do so. And that's also unreasonable. Pushed history should be treated as immutable. If you broke the build, push a revert commit, fix the issue, and resubmit. And then fix your tooling to recognize rollbacks.
- Hovertruck 13y ago
  I tend to treat the history of the master branch as immutable. Working with a remote branch that needs to stay up-to-date with master has, in my experience, required rebasing and force-pushing the branch.
- pseut 13y ago
  In this case, the person probably thought he or she was pushing "feature-wip" or something similar after cleaning up that branch's history. Not necessarily unreasonable. If master is out of date then git push -f throws away any remote commits (under old behavior).