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.
Yeah learned this the hard way.
I've had juniors who didn't believe this, so just to say it: If you know what you're doing, practically any Git problem is recoverable.
The one major exception is if you delete your local changes before committing them.
Yeah.But many of them are extremely annoying. Specifically screwing up rebase. It is recoverable, but very annoying.
That said I have seen juniors make two other common mistakes.
I'm fed up with these two. Yesterday I had to cherry-pick to solve a combination of these two.
Maybe I'm just a wizard, or I don't know what y'all are talking about, but rebases aren't special. If you use git reflog it just tells you where you used to be before the rebase. You don't have to fix anything, git is append only. See where the rebase started in reflog, it'll say rebase in the log line, then git reset --hard THAT_HASH
Pushing without fetching should be an error. So either they got the error, didn't think about it, and then force pushed, or someone taught them to just always force push. In either case the problem is the force part, the tool is built to prevent this by default.
Continuing after merge should be pretty easy? I'd assume rebase just does it? Unless the merge was a squash merge or rebase merge. Then yeah, slightly annoying, but still mostly git rebase -i and then delete lines look like they were already merged?
See all this is fine for someone with good experience in git. They know how to solve the screw up. But wih junior devs, who don't know much about it, they will just get confused and stuck. And one of the senior has to involve and help them solve. This is just annoying because these can be avoided very easily. Until they understand the pattern of how everyone operates with git, it just creates issues.
To me first time causing this issue is completely fine. I will personally sit with them and explain then what went wrong and how to recover. Most of them will repeat it again, act clueless and talk like they are seeing this for the first time in their life. That is the difficult part to me.
May be I'm just old school, and a grumpy old person, even though I'm not that aged.
IntelliJ has local history for that case.
git reflog
git re-flog is what you do with those idiots who mess up the repo so that someone else has to come in and fix it again.
Reflog, when flogging isn't enough.
Seriously, once you commited something to the repo it's hard to lose it. Unless you delete .git. But a this point frequent pushing has your back.
I know git can be hard to grasp in the beginning. It was hard for me too. I highly encourage everyone to put in the effort to understand it. But if you don't want to do that right now just use it. Just commit and push. It will pay off.
Git repository operations are (almost?) always recoverable. git reflog is your friend.
The filesystem operations are another story. Handle with care.
Wait, what does reflog do?
Think of it like your browser history but for Git. It’s a list of the SHAs related to your recent operations.
And because Git is a content-addressable data store, a SHA is basically like a URL. Even if a branch no longer exists, if you know the SHA it pointed to then you can still check out the exact contents of that branch. The reflog helps you find that.
Goddamit... It's ref log, not re flog. I thought this was related to blame and never touched it lmao
I guess "git sanasaryan-han-torture" was an overkill sometimes...
Special shout out to the person who committed a gigabyte memory dump a few years ago. Even with a shallow clone, it's pretty darn slow now.
We can't rewrite history to remove it since other things rely on the commit IDs not changing.
Oh well.
Sounds like a flawed workflow, if this didn't go through at least code review. Was it committed directly to master?
Curious to know what kind of system relies on hashed not changing? Technically the hashes don't change, but a new set of commits is made. The history diverges, and you can still keep the old master if you need it for some time, even cherry pick patches to it..
You know... A version control system... That class of software that makes it possible for you to recover from any error you commit.
With Jujutsu (which is compatible with git), you can just
jj undo
Been using it for over a year now and not being scared of trying operations is such a boon. It helps so much with learning when you know you can just roll back to an earlier state.
I've had zero issues with it so far and no one at work noticed anything different, other than there being a bit more rebase spam on PRs.
That is so cool. Why doesn't git have this already?
I mean, by definition, it does. It just involves parsing through the git log and a bunch of unintuitive, archaic commands.
Isn't it the exact opposite?
I learned that you can never make a mistake if you aren't using git, or any other way for having access to old versions.
With git it is really easy to get back to an old version, or bisect commits to figure out what exact change was the mistake.
The only way I understand this joke is more about not wanting to be caught making a mistake, because that is pretty easy. In other methods figuring out who did the mistake might be impossible.
This is not about mistakes in the Git-managed code. This is about mistakes in the Git commands themselves. Anything that involves merging/rebasing/conflict resolution can potentially be botched. These mistakes are usually fixable, but:
Went to tech elevator boot camp, was a decent experience even if I don't find myself doing exactly what I was expecting to do. Life is that way though.
Anyways, my first week I fucked some git stuff up so bad I became the go to guy when anyone had any git issues because I had to learn so much to undo my egregious error. I don't remember now exactly what it was but it took some serious git magic to sort.
Just saying that point 1 is very true. And yeah don't make mistakes in git.
As long as you never touch the rebase button, you'll be fine. Probably.
Don't be afraid of rebases, they are an essential tool in Git.
This particular fear can only be addressed by understanding.
…button
... and force push.
If you ever find yourself in a situation where rebase or a force push seems to be the solution, take a step back, clone your repo in a new directory and copy the changes into you're new checkout - 'cause you gon' and screwed somethin' up, son.
I rebase and force push daily. I like squashing all my commits, and our main branch moves quickly so I rebase off that often. Zero issues for me.
Same. And even if you were to fuck up, have people never heard of the reflog...?
Every job I've worked at it's been the expectation to regularly rebase your feature branch on main, to squash your commits (and then force push, obv), and for most projects to do rebase-merges of PRs rather than creating merge commits. Even the, uh, less gifted developers never had an issue with this.
I think people just hear the meme about git being hard somewhere and then use that as an excuse to never learn.
I rebase and force push PR branches all the time. Master is moving quicker than my PR.
Skill issue
We need version control for the version control.
git gud, son
git reflog is your friend
The worst thing you could do is delete your local git repo.
