7 ms·

rebase for lyfe! Just don't force push on master.

by leekh 10y ago

hashkb 10y 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.
- epmatsw 10y ago
  But how can you know it's safe in a collaborative project? What if someone else merges a PR right before you push?
  - sdegutis 10y ago
    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.
    - realbarack 10y ago
      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.
      - reubano 10y ago
        He may have editted his comment, but it doesnt mention `force`. As written, there is no race condition.
        hashkb 10y ago
        You've probably seen it in other comments, but if not, `--force-with-lease`
        sdegutis 10y ago
        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.
  - to3m 10y ago
    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.
  - TheCoelacanth 10y ago
    --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.
    - hashkb 10y ago
      This.
  - abrezas 10y ago
    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.
    - hashkb 10y ago
      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.
  - hashkb 10y ago
    You can use chat. Say "@channel I need to fix to master, nobody merge for a minute".
  - juandazapata 10y ago
    `git push --force-with-lease`

rebase for lyfe! Just don't force push on master.

by leekh 10y ago

rebase for lyfe! Just don't force push on master.

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.

epmatsw 10y ago
But how can you know it's safe in a collaborative project? What if someone else merges a PR right before you push?
- sdegutis 10y ago
  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.
  - realbarack 10y ago
    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.
    - reubano 10y ago
      He may have editted his comment, but it doesnt mention `force`. As written, there is no race condition.
      - hashkb 10y ago
        You've probably seen it in other comments, but if not, `--force-with-lease`
      - sdegutis 10y ago
        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.
- to3m 10y ago
  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.
- TheCoelacanth 10y ago
  --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.
  - hashkb 10y ago
    This.
- abrezas 10y ago
  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.
  - hashkb 10y ago
    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.
- hashkb 10y ago
  You can use chat. Say "@channel I need to fix to master, nobody merge for a minute".
- juandazapata 10y ago
  `git push --force-with-lease`