1114
Rebase Supremacy
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 04 Apr 2024
1114 points (98.1% liked)
Programmer Humor
19622 readers
1 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
How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.
In a small team at a small company it becomes my problem pretty quickly, since I'm the only one that actually has some clue about what git does.
This. When they get any sort of conflicts in their pull request, it becomes MY problem because they don't know what to do.
Heaven forbid my teammates read any documentation or make any attempt to understand the tooling necessary to do their job.
That being said, I taught my dumbass git-illiterate team members a rebase workflow, with the help of the git UI in Pycharm. Haven't had any issues with merge conflicts yet, but that might just be because they're too scared to ask me for help any more
I don't want squashed commits. It makes git tools worse (
git bisect,git cherry-pick, etc.) and I work very hard to craft a meaningful set of commits for my work and I don't want to throw all of that away.But yeah, I don't actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.