Hacker News new | ask | show | jobs
by hashkb 3633 days ago
I force push master when I know it's safe. If you aren't confident, don't do it. Don't piss off your coworkers. But this dogma is ridiculous.
1 comments

But how can you know it's safe in a collaborative project? What if someone else merges a PR right before you push?
--force-with-lease instead of --force. It does the same thing as force but checks to make sure the branch hasn't changed since you fetched it. Still very likely to piss off your co-workers, though.
This.
The problem is not if someone merges a PR before you push, but if someone branches off of the current tip of master, works on it, you remove that tip, and your colleague now is based on a history that doesn't exist, has to resolve your conflicts.
They're the same conflicts they'd have to fix if I pushed a new commit or merged a PR; assuming I made the same changes to code when I force pushed.
1. Rebase onto master.

2. Pull master just before you push.

3. If there are new commits, rebase onto master again.

If everyone on the team follows these 3 rules, it won't get too messy to untangle.

Unless I'm missing something, there's a race condition between "check if there are new commits to pull before force pushing" and "new commits come in". This workflow might work for a very small team but for a larger team it is bound to cause problems.
He may have editted his comment, but it doesnt mention `force`. As written, there is no race condition.
Right. As logn as you døn't force-push, then you can rebase until the problems are all gone. Although, this 3-step solution works best with proper team communication and planning.
You've probably seen it in other comments, but if not, `--force-with-lease`
`git push --force-with-lease`
You can use chat. Say "@channel I need to fix to master, nobody merge for a minute".
Bluff ;) - tell them they did something wrong. It's their fault. They don't know how to use git.

There's an xkcd about this I think.