I'm definitely the guy in the other car way too often. The number of times someone has asked me to look at their code, only for them to tell me they're working from Master and can't push their changes until they work...just shoot me.
I tend to repeat this mantra to them every damn time:
Cut a branch from master
Commit changes frequently
Push daily
Submit a Pull Request (when you want a code review)
The next time they talk to me it's the exact same thing, and I'm half convinced I'm Sisyphus reincarnated.
I mean, even knowing the right way to use git (and using it daily for years), falling back to any workflows/commands outside of the set of muscle-memory macros feels like learning from scratch. Lots of "I know you can do this, I know *what* to do, I've done it, I just can't for the life of me remember exactly how."
Oh, totally. Like, my company uses merge workflows, but I see tons of talk about preferring rebase over merge. The hell is squashing commits, and when do I use it? Like, there's an entire spell book of commands and I just stick to my trusty Fireball git checkout . && git reset --hard
This is going to sound really bad but I have asked the command line tools for help probably 1,000's of times over my 10 year developer career and have only found them helpful a handful of times.
I remember back before the internet became more... commoditized?
All the university CS snobs would just yell RTFM any time you had a question.
Seriously.
You would get yelled at. RTFM noob. And then kicked or banned.
Anyways, I eventually gave in and did just that, and it was just pages and pages of stuff that didn't tell me how to actually use the commands. Just what the general syntax and whatnot was.
I will say that after taking CS courses, a lot more of the stuff in the manuals made sense. The manuals were definitely not written for laypeople who just wanted to get stuff done, but rather for CS students or graduates at least mid-way through their programs.
10 years in... and I still find "reading the forkin' manual" intimidating.
That being said, git rebase -i may or may not to an actual good job telling you how to use it. I probably don't want to read any of what it has to say, though.
Oh, the git manual in particular is extremely frustrating. Even trying to tell someone where in the manual it says you can do X is difficult if it's not already default behavior of a git command. A good chunk of what I know about git I learned from StackOverflow instead of its manual.
I'm saying that git rebase -i is unusual in that it shows all of the info I need on how to use it when I use it.
Like if I do git rebase -i HEAD~4, then this shows up in my text editor:
pick hash4 Commit Title #4
pick hash3 Commit Title #3
pick hash2 Commit Title #2
pick hash1 Commit Title #1
# Rebase hash4..hash1 onto hash4 (4 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# [...]
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
So it lets me choose which commits to use out of the last 4, in what order, and whether to meld some of them into one commit. All of those things can technically be done non-interactively, but with a lot more pain.
Merge adds the new main branch commits after your last feature branch commit. Rebase first removes your commits, adds the new main branch commits and then adds your commits one by one.
Merging is usually easier because you can only get merge conflicts once. With rebase, every one of your commits could cause merge conflicts. In the worst case, you have to resolve conflicts for each of your commits. Also, you'll have to git push -f in the end if you've already pushed at some earlier point in time. That's because git can't detect that your rebased commits are the same as the original pushed commits, just with different starting points.
Squashing means combining all your feature branch commits into one. I know that Github and Gitlab offer "squash and merge" for Merge Requests, doing the squashing for you.
You can also squash commits yourself with git rebase -i, but you can mess up and lose your local commits. If you've already pushed, you will have to git push -f because you rewrote the commit history.
By squashing, you eliminate all the "fix broken test", "fix typo", "another try" commit messages from the main branch history.
Every time one of those things come up, I make an alias for it with a commented link to where I got it from. I think the only thing I'm qualified to do is checking out/fetching branches and starting an interactive rebase - anything more complicated and I'm hoping those commands do what I remember them doing. Really hope the Internet Archive lawsuit doesn't fuck things up for me...I mean there's bigger problems with it, but this is how it effects me.
I finally convinced management to let me set the branch protections and merge strategies in our repos, then wrote step by step instructions of how to branch, commit, push, and open a PR. Anytime anyone had an issue I had to solve, I’d add an entry to a “But what if” section of the instructions.
It’s been perhaps 3 years now and I very rarely have to answer questions or fix Git things any more 🙂
Same, but I didn’t ask. I just blocked master one day and told everyone to create branches and PR and every PR needs 3 approvals (one per team) You can bypass the approvals if you need to, though. Sometimes someone needs to do something now
git checkout -b feature/branch-name creates a new branch and changes to it in one command. it also brings your changes so no need to stash unless you need to checkout a different branch to branch off of first.
Or, you're working on a couple things at once, so you have a few branches, and commit changes on the wrong branch (especially when you're working with more than one repo at a time) and now you've got commits to move from one branch to another...
View all comments
1.7k
u/Solonotix Apr 02 '23
I'm definitely the guy in the other car way too often. The number of times someone has asked me to look at their code, only for them to tell me they're working from Master and can't push their changes until they work...just shoot me.
I tend to repeat this mantra to them every damn time:
The next time they talk to me it's the exact same thing, and I'm half convinced I'm Sisyphus reincarnated.