7 ms·
I think you misunderstood my post, if you squash merge as I suggested your main branch is linear as with a rebase. Your PRs and the the working branches behind
by andrewvc 4y ago
I think you misunderstood my post, if you squash merge as I suggested your main branch is linear as with a rebase. Your PRs and the the working branches behind them should just use merged however. Come merge time the diff is turned into a single commit
- chociej 4y agoWell of course it's as good as a rebase -- it is a rebase.
- __blockcipher__ 4y agoIf you squash into a single commit upon merge, ignoring for the moment the fact that as a blanket rule that's a bad pattern, you've now eliminated one of the core arguments against rebasing. The merge commit adds no value if the branch itself is a single commit. Just rebase your squashed-into-one-commit branch ontop of latest master and push that to master instead. Now you have one commit representing your whole PR, with no pointless merge commit. I really discourage the squashing upon merge approach entirely though, because that's just a bandaid for lazy and/or misinformed developers to cover up the fact that their whole git workflow is completely borked.
- deleted 4y ago[deleted]
- mixmastamyk 4y agoSeems you don't understand merge commits, they are nothing special. Just don't: https://news.ycombinator.com/item?id=33518496 https://news.ycombinator.com/item?id=33518496