I gotta say I love when projects want you to rebase commits and generally smash everything in a branch down to a single commit ( love me a force push ).
Long as hell branches with multiple mainline merges ( or even worse spider merges into them ) just suck.
One weird thing that's happened to me a few times is that I'm in the middle of rebasing, I fixed any merge conflicts, try to continue, and it says "resolve all conflicts". I do "git status", it shows there is nothing to fix...
Rebasing is great for the case where you’re on a feature branch that has not yet left your machine, or at worst, that nobody else should have checked out from upstream for any reason. Right before you send up your PR to merge back to mainline, if you rebase to mainline then you won’t have a huge merge commit that is just “everything that happened to the mainline branch while I was working on this feature”. This eases the workload you are asking your PR reviewers to take on, and as such is a virtuous act.
The fact that rebase is a feature that only does what it’s supposed to during a specific phase of the lifecycle of a branch, and ruins things for everybody when used after that point, but is in no way documented as such nor constrained by any sort of controls to prevent you from making all your colleagues’ lives worse with a ton of force pushes and history changing, is peak git IMO.
Rebasing doesn't fuck up history in a way anyone should care about because
a) you shouldn't have long lived feature branches anyway so virtually nothing should be hanging off extant branches. Release branches can get cherry-picked to
b) you should really be using something like gerrit rather than force pushing and you can just run it in rebase/cherry-pick mode which does all of this automatically
c) there's little value in all the intermediate "quick fix" "forgot a file" commits that you lose in amend/rebase workflows
That reminds me of the question I would always ask fellow local tech folks at meetups back when that was a thing that happened, upon hearing them say “…and now we’re migrating to a microservices architecture, it’s really exciting”, to wit:
“Oh cool! What does your architecture do when the database goes down?”
Every time I was hoping to meet someone who was doing cool things with distributed systems. Without fail, I got instead an uncomfortable silence and a new conversation partner.
_
Your Ad Here! Reasonable Rates!
+1
admanunionize your workplaceSeattle, WARegistered Userregular
That reminds me of the question I would always ask fellow local tech folks at meetups back when that was a thing that happened, upon hearing them say “…and now we’re migrating to a microservices architecture, it’s really exciting”, to wit:
“Oh cool! What does your architecture do when the database goes down?”
Every time I was hoping to meet someone who was doing cool things with distributed systems. Without fail, I got instead an uncomfortable silence and a new conversation partner.
The difference between "we're migrating to a microservices architecture because it solves a clear problem we have" and "we're migrating to a microservices architecture because our CEO/CTO/tech lead* read a white paper over the weekend."
*I know we prefer to roast non-technical management but never underestimate the ability of devs to be self-destructive
Posts
Long as hell branches with multiple mainline merges ( or even worse spider merges into them ) just suck.
Like everything else KISS.
If you want a clean commit history, make a pretty commit message when you squash everything into a single merge commit.
The fact that rebase is a feature that only does what it’s supposed to during a specific phase of the lifecycle of a branch, and ruins things for everybody when used after that point, but is in no way documented as such nor constrained by any sort of controls to prevent you from making all your colleagues’ lives worse with a ton of force pushes and history changing, is peak git IMO.
Your Ad Here! Reasonable Rates!
a) you shouldn't have long lived feature branches anyway so virtually nothing should be hanging off extant branches. Release branches can get cherry-picked to
b) you should really be using something like gerrit rather than force pushing and you can just run it in rebase/cherry-pick mode which does all of this automatically
c) there's little value in all the intermediate "quick fix" "forgot a file" commits that you lose in amend/rebase workflows
“Oh cool! What does your architecture do when the database goes down?”
Every time I was hoping to meet someone who was doing cool things with distributed systems. Without fail, I got instead an uncomfortable silence and a new conversation partner.
Your Ad Here! Reasonable Rates!
The difference between "we're migrating to a microservices architecture because it solves a clear problem we have" and "we're migrating to a microservices architecture because our CEO/CTO/tech lead* read a white paper over the weekend."
*I know we prefer to roast non-technical management but never underestimate the ability of devs to be self-destructive