What’s going to f up my career from here on out is Git. I’m constantly needing assistance from others with it because I can never keep everything straight in my head with what’s going on “in there”. It’s always getting tangled up like old fishing line and I just have to cut the line and start fresh again. I honestly feel so stupid compared to other people who don’t have a problem with it. My brain just can’t keep track of all the different states local, branches, and master can be in at any given time, and across more than one developer. I’m probably alone so, yeah, go ahead and roast me. I probably deserve it for being so perpetually gobsmacked by it all.

I had this for ages, it was my dark secret well into my career. I bought “the little book of git” or something like that, spent a weekend familiarising myself with it and trying out every command on a couple of dud repos and I’ve been fine ever since. It is pretty simple, just a bit intimidating. Plus, a lot of scary shit like rebase you’ll probably never need, and if you do, so rarely that Googling it won’t be the sign of an amateur.

I tend to just keep it simple.
Create a feature branch, do the work, merge latest main into my branch to resolve any merge conflicts and run the tests, then PR/merge my branch back into main.

Very rare that I use any of the fancier stuff.

that's interesting. I personally never had problems with git at all, it almost immediately clicked for me. But throughout uni I met a couple of people who were completely bewildered and petrified when working with it. I never understood how that happens. The first step is to understand, that Git is literally designed to be version *safe*. You quite literally can't fuck up anything to such degree that it's irreversible unless you were assigned incorrect privileges by your admin, but even at that point, it's quite hard to take down master by accident since you shouldn't ever be working on top of master anyway (exceptions apply though).

Other than that it's literally just about having a copy of the code in your computer, and everytime you "push" you upload code and when you "pull" you download code.

everything else that happens is essentially just storing bunch of DIFFs between each push, and DIFFs happen to be easy to merge together, you just apply them in the same order

@Hazarth We have three things to track: an external Git service for our “gold master” code, the hosting service which has its own Git repo, and then our individual machines. In my case, I’ll forget that some commit event happened on one and merrily go about pushing my updates or pulling code only to realize too late that I’m creating merge conflicts galore or other nonsense. I hate it.

@stackodev merge conflicts aren't that scary, you just read through the code and apply whatever makes sense, and even if you fuck something up, the original code is still in the previous commits.

I mean it's slightly annoying when it happens, but I don't see conflicts as anything more than a chore, not really a problem.

the solution is to pull frequently when working on the same branch with someone else, but really the even better solution is to work on your own separate branch, and just merge whatever you source from to your branch whenever you feel like it just to ensure some continuity

I'd also add that, when I learned a little more, it turned out most of my agony had come from misusing my git client and checking out old commits when this wasn't the right thing to do: it's very easy to end up with a detached head - and the red warning text and, you know, having a fucking "detached head", make this sound a lot scarier and more broken than it is.

Equally, 'merge conflict' sounds like something is fundamentally broken when it's actually central to how git works, just means that it needs your help to decide what to keep and what to throw away in a file - and as @Hazarth says, git is designed to prevent you from breaking anything beyond repair, so don't panic.

What might help, is doing all your GIT needs on the command line until you feel like knowing whats going on before switching to IDE-integrated GIT management.

Also don't be ashamed reading the docs and browsing StackOverflow.
GIT is a surprisingly mighty tool and you don't know what you miss out on until you have managed to rewrite history at least once.

And keep in mind that as a dev you will get intimate with GIT a lot. So taking the time to actually git gud at using it will definitely be worth it.

@stackodev
First fetch all remotes,
Then rebase local branch on fetched remote branches having new commits,
Then push local branch to remotes.

That's because Git is an abomination. It's garbage. It's extremely clever internally, but the problem is that cleverness leaks out all over the place. That's bad. One day, the industry is going to realize this, and we'll move on to something better. I don't know what that is sitting here today, but I know it'll throw out all the complexity Git suffers from - or maybe there will just be such good UI's that you'll never notice it... either way.

But, all that said, it's also something you have to deal with in this industry whether you like it or not. So, you can hate it all you want (and I'm right there with you), but you gotta come to terms with it.

Fortunately, what TrevorTheRat says above is spot on. Keep it simple, and don't worry about anything beyond the very basics unless and until you need it and you can deal with it okay.

Did you try to use a GIT UI client?