It is time. I have to admit it.

I don't understand Git.

I just memorized some basic commands: git commit, git push, git push -u origin master, git clone, git checkout [-B], git merge. That's it, that's the full list. I use them like they're some kind of magic spells that do what I need. Everything else, those intricacies like rebasing, resetting, HEAD and all that shit, is beyond me.

I'm not a real programmer. Real programmers know Git.

I don't even vaguely pretend to be a Git expert, but rebasing is useful and opens many more doors to using other Git tools, and this guide helped me a lot in figuring it out: https://git-rebase.io/

I openly admit to anybody who cares that I don't know how to use git.

I understand the concept, but every time I try to merge something I get a bunch of errors or conflicts, or some other message that says that I can't do it because of XYZ. And then there's stashing changes which I don't really understand.

Genuinely, for me and the small team I'm in it's just easier to rename a file index-old.js :D

Use a GUI git client. Fork is a great one that I can recommend.

I don‘t know git commands either but guess what? I don‘t have to. Fork does it for me.
Of course you still need to understand the concepts of branches, head, merging, etc. And GUI clients make easier to learn and understand with the power of visualization.

Knowing git CLI doesn’t mean anything.

@kiki indeed lmao

Git is imho quite over-engineered nevertheless but yeah

Take a look at this: https://onlywei.github.io/explain-g...

It allows you to "visualize" the main GIT commands and you can also experiment freely.

No need to worry about that as long as you don't need it, it's a simply a tool which helps you accomplish some goal.

Using Fork too. I use Git, but never managed to remember the commands.

There are a ton of 'Git explained visually' out there that explains it pretty good.

Mit missing semester channel on YouTube has a nice lecture explaining concepts git uses.

Rebasing is painless in most cases

Also, Sublime Merge makes most of git interaction very easy. You can even look at the actual git commands it uses while doing things.

Git is technically sound. Proof: Github is successful.

Git's UI is a messy piece of shit. Proof: Github is successful.

@kiki, as somebody who's used Git almost religiously for about a decade now, I heard you loud and clear... I'm still learning about all it's quirks now, many of which are _not_ new to Git itself. 🤦

Using a GUI is most definitely helpful, but in the interest of not killing a Git repository, it is still important to understand what goes on "under the hood".. otherwise, when that magic "merge" button complains about not knowing which change to pick, well.. yeah. GL,HF, I guess?

In all seriousness though, I would suggest that you pick a good smooth Git GUI (Fork is brilliant, Sublime Merge is very good, avoid GitKraken though, it will drive you insane), and then use that to follow the actions and make sense of what it's doing to your repository.. once you can comfortably flip between branches, even in the middle of changes, then you will likely start to enjoy using it. 🖖

@kiki yeah, I can relate. My personal rule of thumb though, just because of terminal being what it is: if it involves staging anything _for_ a commit, I use a GUI... I actually do love building a commit line by line. 🤓

It’s hard to learn if someone doesn’t actually explain it to you in person

Good GUI tools make it easier to understand what is happening. That way you learn to git gud with the CLI also.

https://ohshitgit.com/

You’re welcome

@buttonfreak you sir, are a gentleman and a scholar .

It's normal that it takes a long time to learn new commands beyond the essentials.

It's fine to combine CLI with GUI. For example:

If I need to stage or stash ALL files I use the CLI. But if I wanna add a few files only, I use a GUI like vsCode. If I wanna peek at multiple files in an old stash I use a GUI like Fork.

Learning how to handle merge conflicts and rebasing is very useful if you're working in a team.

But not gonna lie, it's a time investment.

Rebasing is a little world of it's own with multiple status steps, not to mention needing some VIM skills.

If you find yourself wanting to remove your 3 last commits and make a more succint commit msg I think an easier first step is to learn `git reset HEAD~3` ...but of course this is only ok in your own branch as you then might need to `git push --force` which you don't do in master.

The versioning control tool being more complex than the programming language is beyond insane

Any kind of version control system is really, really complex. Due to the decentralized design of git, it has a bunch more layers of complexity when compared to the old school version control systems like Subversion.

It takes time to get to know git, I only felt comfortable after 6 months of using it, I feel confident after years, yet still it boggles my mind from time to time. (WTF you mean the meaning of theirs and ours is switched during a rebase!?) Biggest compliment was becoming the go-to guy for every git problem in one company.

As developers, we need to work with loads of technologies. You can't be a master of all. You don't need to be the git guru within your team, others will fill the role, and most of them will help you to learn it.

Git error messages are some of the most helpful ones I've ever seen. And its documentation is vast. There are also some online playground offering deep dives in how it works if you're interested learning more.

nobody understands git.
not even the git who made git understands that git anymore, i bet.

i use gui for g(it), and also just use basically the same list of basic functions you mentioned, plus stash.

and i vaguely understand the concept/idea behind what it does, but how exactly, and why it gives the errors it gives (except merge conflicts, those i get), and why the magic incantations google whispers to me to fix the errors work...

... no idea.

When people started talking about distributed versioning, and I studied the alternatives at the time, I chose Mercurial for my company. The history is immutable, and simple to use. We are with him until today, 12 years.

@codingfreedom I never tried Mercurial because git was awesome. What would be the benefits choosing Mercurial over git?

@Lensflare At the time this discussion was more open, with the success of git this was forgotten. Basically GIT is great when you have a big project with a lot of contributors that you don't know about. History manipulations like rebasing and deleting branches are very useful in these cases. Mercury does not. The history will stay there forever, without the possibility to "squash". Nobody deletes branch (git push -d). That is, it is much more real for small companies like mine. In addition to simplicity. NGINX uses Mercurial, and all Sun (R.I.P) too, like Solaris, Hotspot and etc.

Well you can try it out those more advanced commands whenever you got a bit of time, this way you'll know more about git. Rebase and reset are legit useful, though kinda abstract. :)

No shame about it, some "programmers" just copy their uncompiled/untested code directly on the web UI of their repos without a care in the world for consequences so you are much more advanced than they are.

I think I have actual PTSD from git from the last company where I used it. I messed up so many things with it that it’s still haunting me in my nightmares. SVN was a lot easier IMHO. Maybe not as powerful, but easier.