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!
So you’re going to git gud?
git out
git your pants
- 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 happenedI 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!
Literally.
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.
This has been the best git tutorial I’ve come across so far. Nicely interactive and gamified. https://learngitbranching.js.org/
This is great, but I just want to say that the best way to use git is to simply stop doing so much in one branch. Branches should not last longer than a week, ideally
Just rebase your life already
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_nameto 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.
this is bad advice. Never force git to do anything. If you’re forcing something you’re doing it wrong.
you can always
git fetch -a; git merge -X theirs remote-branchor rebase your branch.I hear what you’re saying.
First, I hard disagree with you. Overwriting my local version of code is a parachute - not an ideal landing, but better than merging by hand.
Also, my comment was not an attempt to teach everything about git, just to explain what is happening in simple terms, since git requires a lot of experience to understand what those messages mean.
If I get a big conflict and I know my change is trivial, I feel perfectly okay doing git fetch git reset --hard whatever and then reapplying my simple change as a new commit. Sort of a bootleg rebate.
If you use a squash workflow, you’re going to be force pushing a ton.
Never force git to do anything. If you’re forcing something you’re doing it wrong.
This is bad advice. Better advice would be “know and understand your tool, and know the consequences of your actions”.
When we switched from svn, we had to figure out git with submodules… that was fun
Learning git is very easy. For example, to do it on Debain, one simply needs to run,
sudo apt install lazygitLazyGit may actually be black magic from Satan to tempt programmers into sin. And to that I say: ‘where is a goat I can sacrifice to my dark lord?’
Wow this looks great. Amend an old commit dealing with a rebase? Sign me up!
git rebase -i origin/main(or whatever branch you’re rebasing on), then read the instructions that come up in the editor windowRead… instructions? I love teaching people that git very often prints out what you should do next.
git: “to continue, resolve conflicts, add files, and run rebase —continue”
dev: …time to search stack overflowAll that said… just use lazygit. It does help to know CLI git first to put things in context, but if you do, no need to punish yourself every day by not using a UI.
I’d still probably prefer the usual CLI for setup, commits, pushes etc. but this looks like a godsend for any branching/rebasing operations!
deleted by creator
sublime merge is pretty great, but having a working familiarity with the underlying tool is invaluable when shit inevitably goes sideways while collaborating
Pro tip: If your code gets flogged by git, you can always get revenge with
git reflog😉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.
lazygit or tig are terminal interfaces for git. very nice, best of both worlds imo. every action shows the git command ran at the bottom, and its a lot easier to see at a glance the status, diff, log, etc.
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
It’s not THAT complicated but I wouldn’t call it dead simple. When you understand how git works internally yeah it’s pretty simple but people usually start with the idea that it’s a tool to put your code on a server to synchronize with other people and only later learn that you have both a local and a remote (or multiple remote) tree and how the tree really works.
I think the problem is most git 101 tutorials teach it wrong, IMO the best git tutorial is this: https://wildlyinaccurate.com/a-hackers-guide-to-git/
Unfortunately it’s pretty dense so it’s gonna scare off a lot of newbies.
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.
deleted by creator
