So you're going to git gud?
this post was submitted on 09 Nov 2023
1227 points (98.2% liked)
Programmer Humor
32054 readers
1267 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
if u ever get a tricky merge conflict, just git push --force. this automatically works out the right code to keep (your own)
Also, a way to never have to work again!
Except if you're an employer in a very small company.
Source: my boss did this at the first company I worked at.
- git pull
- git reset --hard HEAD
- try not to cry
- cry a lot
git reflog, you can get your old commits back
But I want to pretend none of this ever happened.
git can we just pretend the last 30 minutes never happened
I feel like that would get more use than people want to admit.
lemme rebase the main branch onto my branch.
two minutes later
1 merge conflict of 57 [abort] [continue]
this is easily fixed by copy pasting the files into a new directory and never opening git again out of fear
Project managers hate this one weird trick!
One key thing that can help you wrap your head around rebasing is that branches get switched while you're doing it; so, say you're on branch feature and do git rebase master, for any merge conflict, whatever's marked "current" will be on master and what's "incoming" is from feature.
There's also git rerere that should in theory remember a resolution you do between two branches and reuse it every time after the first; I've rarely used it in practice; it would happen for long lived branches that don't get merged.
Pro tip: If your code gets flogged by git, you can always get revenge with git reflog 😉
Learning git is very easy. For example, to do it on Debain, one simply needs to run, sudo apt install lazygit
load more comments
(4 replies)
Git is a great invention but it has a few design flaws. There are too many ways to confuse it or break it, using commands that look correct, or just forgetting something. I ended up writing simple wrapper script codebase to fix it. Since then no problems.
It was conceived for experts so the new user experience is shit and the UI is not intuitive. But it has become such a widespread standard that it is very hard to completely overhaul the UI.
TBH compared to the old versioning system people used to use like SVN and Mercurial. Git is a godsend. Just taking your time in learning and not using a GUI client works wonders in learning how it works. Especially when all the GUI clients are basically a collection of commands being executed so if you fuck things up on CLI you know what happened vs using GUI.
load more comments
(1 replies)
Even for experts the user experience is shit. Too much has to be done manually when the default should be automatic, like fetching before pull, recursing when working with repos that use submodules, allowing mismatched casing on case insensitive filesystems, etc.
Submodule commands are such mess, which is sad because it is a great feature.
load more comments
(1 replies)
load more comments
(1 replies)
This has been the best git tutorial I’ve come across so far. Nicely interactive and gamified. https://learngitbranching.js.org/
load more comments
(1 replies)
Just rebase your life already
...not by choice, because if I don't I'll lose my job
Great meme, and I'm sure op knows this, but for anyone else who is curious...
007 in theory means:
- 00: you have already committed your code to your local code base
- 7: When you try to merge your code with everyone else's there are 7 files that others have worked on since you last refreshed your local code base.
To resolve this, you need to go file by file and compare your changes with the changes on the remote code. You need to keep the changes others have made and incorporate your own.
You can use git diff file_name to see the differences.
If you have made small changes, it's easier to pull and force an overwrite of your local code and make changes again.
However multiple people working on the same files is usually a sign of organizational issues with management. Ie, typically you don't want multiple people working on the same files at the same time, to avoid stuff like this.
If you're not sure, ask someone that knows what they're doing before you follow any advice on Lemmy.
load more comments
(4 replies)
Lol what's git?
It's what americans from a rural area say when they want you to go away.
is what people who don't know vim and rsync have to use to mimic 1% of our power
I just did myself an eye injury due to rolling them so much
A very complicated way to do
My project
My project (1)
My project WORKING
My project (2)
My project (2) (1)
Lol
load more comments
(1 replies)
I prefer rebasing on destination branch before merging. When merging you get all the conflicts at the same time. When rebasing you can address conflicts from one commit at a time. Untangling multiple small knots is easier than one huge spaghetti. Also commit history will be much cleaner.
Go, Team Rebase!
When we switched from svn, we had to figure out git with submodules.. that was fun
If you can't use git I don't see how you're gonna do with other things. It's dead simple.
Solving merge conflicts or rebasing is not simple
Do it enough times and it stops being scary.
Using a tool like VSCode to perform the actual merges on individual files also helps because it shows what "yours" and "theirs" changes are from a user perspective, not a git perspective
load more comments
(1 replies)
It's doable once you know what you're doing. I can do it all via the cli, but I personally use gitkraken most of the time and it's just so much easier and more ergonomic.
I also see a lot of the Devs who insist they know what they're doing create horrible messes of their branches super easily via the commit tree. People should just use whatever works best for them to get the job done.
If it was dead simple you wouldn't need to learn 10 new concepts and google commands regularly even after using it for a couple of years. You probably forgot how you struggled at first. I have taught it multiple times and I see how beginners struggle.
load more comments
(1 replies)
I would actually say it's VERY complicated but in daily work you probably need like 5 commands and those aren't hard at all.
So many orphaned branches... Poor things.
This week? I've been using it for years and I'm still learning it
Honestly, just use a GUI. Graphical user interfaces were designed for a reason. I usually use SourceTree or the Git functionality built in to Visual Studio or VS Code.
It's good to know how things work under-the-hood (e.g understand Git's object model, some basic commands, etc) but don't feel like you need to use the command-line for everything.
In my experience, using GUIs is how people fuck themselves, and then I have to unfuck them via the command line.
Git's interface is bad, yes. It has a step learning curve, yes. But I truly think the only real way to overcome those obstacles is to learn how git works, learn all the nitty gritty details, not hide from them.
I use a GUI (GitKraken) to easily visualise the different branches I'm working on, the state of my local vs. the remote etc. I sometimes use the gui to resolve merge conflicts. 99 % of my gut usage is command line based.
GUI's definitely have a space, but that space is specifically doing the thing the command line is bad at: Visualising stuff.
load more comments
(2 replies)
view more: next ›