So you’re going to git gud?
git out
git your pants
deleted by creator
Highly recommend bookmarking https://ohshitgit.com, it’ll steer you right 👍
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 happenedI feel like that would get more use than people want to admit.
Pro tip: If your code gets flogged by git, you can always get revenge with
git reflog😉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
featureand dogit rebase master, for any merge conflict, whatever’s marked “current” will be onmasterand what’s “incoming” is fromfeature.There’s also
git rererethat 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.
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!
The ease with which I can only commit separate hunks with lazygit has ensured I use it for commits, too. And once I’ve opened it to do the commit, I may as well also press
P.Is this what people who haven’t been introduced to #magit use?
Never tried magit, but it doesn’t matter. It couldn’t possibly be good enough to be worth using an inferior editor.
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
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.
I’m pretty sure Mercurial is newer than git, or at least from the same generation.
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.
Yes you couldn’t change something so widely used. Look what happened with python 3.
Fortunately there’s already a tradition among Git users of building a UI on top of the git UI. My project is just a slightly better version of those. It lays a simple sensible interface on top of the chaotic Git interface.
Yeah. It’s got no abstraction between the UI and the implementation. You just want to manage code versions, but to use Git, you need to learn how to manage history graphs.
…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_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.
deleted by creator
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.
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 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”.
Lol what’s git?
git gud. HA, GOTTEM
Yes you did
It’s what americans from a rural area say when they want you to go away.
It’s the thing you use to create a local copy of the main code base, and then merge your changes back in.
OP hasn’t done anything, and there’s 7 conflicts between his code and main. Presumably because someone else merged their changes in the time between when OP pulled his local copy and tried to push his (non-existent) changes.
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
deleted by creator
Literally.
Oh, you haven’t seen my
lack ofskill then.Show me.
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!
