Beej's Guide to Git

There are tools for the UI part. Most people I know only use command line git for doing stuff where GUIs give up (i.e. fixing repos in weird states). Usually, checking out a clean clone and switching to that will do the same without the GUI, just takes a bit longer if you know the command line fixes.

The issues most people seem to have with git are common version control issues. Version control is actually hard, even if it's just "what has changed", once you start going beyond two users editing a file at once. When three people edit a file at the same time, there's going to be complexity when those changes need to be applied back, and that's where you start getting into branching/merging/rebasing.

Just like some people simply cannot get functional programming/object oriented programming/imperative programming to click in their head, others will never truly grasp version control. It's a paradigm of its own. People who know lots of data structures like to trivialise version control into data structures ("it's just a list of ...") but the data structures are the chosen solution, not the problem.

Another complexity issue is that git is actually pretty smart, and will fix most problems automatically in the background. Often, when you need to manually operate on a git repo, you're in a situation where git doesn't know what to do either, and leaves it up to you as the expert to fix whatever is going on. And frankly, most people who use git are nowhere close to experts. The better Git tooling gets at fixing these situations for you, the worse your situation will be once you need to manually correct anything, and the worse your perception might get.

I have no good advice for you on how to work Git better. All I can say is that I'm very productive with Jetbrains' IDE integration, others seem to prefer Visual Studio Code's git integration, and then there's the Tortoise people. Find whatever tool works best for you and hope you'll have a random epiphany one day.

When working together with other people using Git, I commit fast and often. My commit messages can be anything from "jdwqidqwd" to "add widget frubble() method" while I'm working. Sometimes repeated several times over, sometimes I remember to hit the "amend" checkbox. Basically, whenever I'm somewhat satisfied with the state of my program, I commit, finished or not. Everything in a nice, local, separate branch, pushed occasionally to make sure I don't lose any data.

And then when everything works, compress commits into a few big commits with squash, and actually try to merge that back into the main branch.

> I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function.

For me, that would easily be three commits in my dev branch (one with a first implementation of the function, one with a refactor to a class, then another one back to a single function) and when the function is finished, one squashed commit in a merge request. If everything goes right, it's as if the class file was never there.

It has to be said, relying on squashing doesn't work well when you're working in a team that doesn't pay too close attention to merge requests (accidentally merging the many tiny commits). You also have to be careful not to squash over merges/use rebase wherever possible so your squashed commits don't become huge conflicts during merge trains.

When I work on my own stuff that I don't share, I don't bother squashing and just write tons of tiny commits. Half of them leave the code in a non-compiling state but I don't necessarily care, I use them as reference points before I try something that I'm not sure works.

There is something to be said for carefully picking commit points, though. While finding the source of a bug, git becomes incredibly powerful when you can work git bisect right, and for that you need a combination of granularity and precision. Every commit needs to have fully working code, but every commit should also only contain minimal changes. If you can find that balance, you can find the exact moment a bug was introduced in a program within minutes, even if that program is half a decade old. It rarely works perfectly, but when it does, it's a magical troubleshooting tool.

Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work.

If you insist on memorizing commands for all these tasks (of which there are many), indeed, you're going to struggle and decide you need a 30 section guide. But you don't, and want to whine about it.

> I don’t even disagree, just wanted to say fuck git, I guess.

Pretty much.

If I had 5 cents for every commit in a feature branch with the commit message "wip"...

i feel that the big problem with git is how it applies names to procedures that are MUCH easier to understand unnamed. you can have a model of the current repo state, and the state you wish to reach. instead of just coding this difference on the data structure level, as imperative statements or functional expressions, we’re forced to translate them into a sequence of weird names and flags representing conversions into intermediate states.