this post was submitted on 04 Apr 2024
1113 points (98.1% liked)
Programmer Humor
19564 readers
557 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yeah it is something people should take time to learn. I do think its "dangers" are pretty overstated, though, especially if you always do
git rebase --interactive, since if anything goes wrong, you can easily get out withgit rebase --abort.In general there's a pretty weird fear that you can fuck up git to the point at which you can't recover. Basically the only time that's really actually true is if you somehow lose uncommitted work in your working tree. But if you've actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.
You can get in some pretty serious messes, though. Any workflow that involves force-pushing or rebasing has the potential for data loss... Either in a literally destructive way, or in a "Seriously my keys must be somewhere but I have no idea where" kind of way.
When most people talk about rebase (for example) being reversible, what they're usually saying is "you can always reverse the operation in the reflog." Well yes, but the reflog is local, so if Alice messes something up with her rebase-force-push and realizes she destroyed some of Bob's changes, Alice can't recover Bob's changes from her machine-- She needs to collaborate with Bob to recover them.
Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.
But it's a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That's not what it's for. It's for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.
If “we work in a way that only one person can commit to a feature”, you may be missing the point of collaborative distributed development.
No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don't rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.
Trunk-based development is the industry-standard practice at this point, and for good reason. It's friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.