4 ms·
If you haven't pushed, it's as easy as resetting the branch to the last good commit. If you have pushed, well, it's the same, then push -f, and then making sure
by mseebach 9y ago
If you haven't pushed, it's as easy as resetting the branch to the last good commit. If you have pushed, well, it's the same, then push -f, and then making sure that all your teammates pull the fixed branch. If that's a situation you regularly find yourself in, protecting master from direct pushes and only doing PRs is a good solution (GitHub, BitBucket and GitLab all have tooling for this).
- dkns 9y agoMaybe it's just me but I feel like if you work with multiple developers you should never, ever force push master. I'm wary of force pushing branches in general, unless that's a branch that only I work on.
- mseebach 9y agoIt's not ideal, at all -- and if someone else has pushed in the meantime, they risk losing the commit. But if you're in a situation where doing this would be a significant problem, you should probably not be pushing directly to master in the first place, instead relying on a PR workflow.
- sigjuice 9y agoWhy not simply push a second commit that reverts the broken commit? This will avoid rewriting history and messing up the rest of your team.
- mseebach 9y agoBecause that will pollute the history and diminish its value as a record of what happened in the code base. For instance, blame will no longer tell you when a line was changed, but rather point to the revert commit. Bisect breaks if it divides through the reverted commits. Of course, rewriting history is only feasible immediately after the mistaken commits, before anyone builds on top of them. If they've lingered, reverting is the right way. And again, if this is a repeating problem, fix it upstream (no pushing to master, only PRs).