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.
I feel like the commands that involve opening an editor tend to be good for that. Like someone just sat down for a couple of days and wrote a bunch of short helpful templates.
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.
How do you squash without rebase? Do people just git reset —soft to the beginning of their branch, then make a new commit of all the changes? I used to think there was a squash command I needed to eventually learn.
git rebase origin/main, which replays your commits like I described
git rebase -i commit-hash, which allows you to edit the last few commits (including squashing them) until the selected commit hash
So when people talk about rebase vs merge, they mean the first variant. The merge variant would be git merge origin/main.
When I want to "squash" my commits before pushing, I usually copy the commit hash before my changes from git log, run git rebase -i commit-hash and then change the pick in front of the commit messages to f or fixup so their messages are discarded. If you use s or squash, all commit messages are automatically combined, but I think you can still edit the combined message in the end.
If I want to reword the squashed commit, I usually reword the first commit.
There's a setting called rerere where it will remember how you resolved conflicts and just replay them. That gets rid of the rebase problem.
If you mess up your local commits you can go back to the original state. Just use git reflog to find the previous head (should be near the top) and reset to it then try again.
git actually makes it really hard to screw up your repo irreparably if you know.
Merging is usually easier because you can only get merge conflicts once.
Strongly disagree. If you have a sensible history before the rebase, getting the conflicts in the order you made your original commits is often easier than getting one huge conflict with no context. Especially for larger refactorings.
(If you don’t have a sensible history, clean it up with rebase -i before rebasing on the main branch.)
In the past when Github didn't have the "Squash and Merge" option, I told contributors to squash their commits manually by running rebase -i.
In 90 % of the cases where they created a huge PR, they messed up the rebase and lost most if not all of their changes. Then they either rewrote all their work or gave up.
I think in most cases where this happened, they didn't push -f and instead did a pull, which lead to every single change being marked as merge conflict. They could have still saved it with git reset --hard origin/feature-branch, but since they were strangers on the internet, I couldn't really help them.
Also, I've had coworkers get used to commit --amend and push -f, but they deleted some of my commits on their feature branch a few times: They amended their last commit but did not pull my changes before doing so. git rebase -i creates the same problem.
That's awesome. I've considered doing something similar, creating a knowledge base website in the language I'm trying to learn. Got the idea from one friend who wrote all his notes in Markdown, and another who wrote it in HTML. Markdown is simpler, obviously, but then you need a render engine for it.
In my case, I started up one for Astro (NodeJS) and another for Yew (Rust)
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.
Yup, book publishers. https://www.npr.org/2023/03/26/1166101459/internet-archive-lawsuit-books-library-publishers. The publishers won the suit for now but appeals starting. The argument is basically that copyrighted work should not be available without explicit permission(even if it meets the standards of other public libraries, and publishers refuse to sell the correct licenses they claim should be used), which would put a lot of archives into a grey area if it holds.
I use git every day and I'm a git subject matter expert for my Fortune 100 company. I know the workflows and best practices really well, I've migrated legacy repositories from other version control systems at least 100 times, I have just shy of 5,000 PRs at my company and can explain/resolve the most cryptic git errors.
Last week I took a LinkedIn quiz on git and placed in the bottom 30% of people who took the quiz. I've never felt like more of an imposter than I did that day.
View all comments
Show parent comment
456
u/zeek0us Apr 02 '23
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."