I don't really understand struggles with git. I learned ~10 commands 15 years ago which have worked fine for me. I don't think I deeply understand git internals but it does what I need so not compelled to dig deeper.
- not understanding branch pointers / staging / committing corrently. E.g. [add file] [modify file again] [commit] - what just happened? (IMO these things could have been named better). Also reset vs revert vs restore - easier to use these if you've internalised branch pointers etc
- git pull fails because it says it would overwrite a file you've never heard of - how is that file on your local? Is it ok to delete it?
- times when you (or your colleagues) need to rewrite history (rebase / squashing etc) - require a pretty good mental model of what is going on to both diagnose issues and to fix them
I think much of the confusion comes from git log which is a lie. People want git log to be an accurate representation of what occurred.
This scales for monorepos with thousands of engineers, too.
* a solid understanding of interactive rebasing, including `fixup` and `reword`.
* `git add -p` for adding partial sections of files
* `git commit --amend` for patching the last commit
* `git commit --fixup [COMMIT_ID]` for attaching patches to commits further back in history.
* `git stash` for pausing progress while you fix up an old commit.
* `git rebase -i --autosquash [COMMIT_ID]~` to apply the fixups
* topic branches that never get too big or drift too far from the mainline, because rebasing often becomes infeasible when repo snapshots are too far apart.
* A low enough error rate that you don't screw everything up when rewriting history (which is a reasonable critique and argument for why you shouldn't attempt this in the first place).
I can usually manage this, and efficiently enough that it's worthwhile — and my colleagues appreciate that my PRs are easy to follow. But as a reviewer, I don't insist on other people putting in the same investment.
If you need to do exploratory work and need to share that with someone else, yeah, you will have lots of noise in these commits. Yes, maybe some of those commits wont even build depending on how long your build takes. One approach is to do a "clean room" style re-write with better quality commits (ideal) or likely some rebasing and cherry-picking might be needed - both of which are better than merging all of the noise to the repo.
Taken to the extreme, one could consider every character typed to be what "really happened" but of course no one wants that.
I agree with rebase on shared branches however, that requires coordination and understanding of everyone using the branch. Sometimes, long running shared branches are needed but it generally something to try to avoid.
Which is precisely _not_ a "just memorise these commands" approach to git right?
Also re: your general snark - try a bit more empathy? I'm sure you are an experienced dev but we are talking about people LEARNING git, they don't have the same points of reference as you do today.
Today there is "git switch" which people say is good for beginners. I have too much git checkout muscle memory.
Do you know how to build a working computer from individual transistors or understand the physics behind it (I happen to know these things personally)? If not, better crack open your modern physics text and study particle in a box, along with the requisite differential equations, calculous and linear algebra just in case you might run into a problem one day.
I will say though that I get really nervous reverting sometimes, making sure I’m using the right command to reset etc can be confusing.
Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. But this is also one of these examples. If I remember correctly, there are other options to sync your remote after you did a rebase, but force push is just the easiest. So I rather take 5 seconds to make sure I typed exactly what I wanted and that everything is fine and that just works.
Edit: I was just brainstorming a bit about it and thought that probably some of the unknown magic git features were just implemented by a motivated dev that just wanted to explore what's possible. But on the other hand, there are most likely some very very obscure configurations and edge cases in the wild where people actually need those features. But most people will likely never need them, so I myself won't bother understanding "everything"
It sounds like you recognise that this is an irrational fear but in case you don't: this is an irrational fear.
I freed myself from the fear of losing data after a rebase when I learned to restore from a commit in `git reflog`. So long as your work made it into an actual commit at some point, everything is recoverable from the local repo's history[1].
[1] Ignoring giganto repos that actually trigger garbage collection.
If I was a beginner, I'll try to get some proficiency early on rather than having to learn the hard way when you're on the middle of a project. It's a good investment.
I've also found that learning crafting nice commits made me a better programmer. It seemed difficult at first but now it's second nature (and I assume that in most teams, one is expected to submit small and self-contained commits anyway).
Same here - I've been using it for a long time without any real deep understanding of it and still no issues. I _do_ believe that there's a "hidden" layer of collaborative functionality that I'm missing out on, but since everybody I work with uses git the same way I do, I suspect that if I did know what I was missing out on, I'd just be frustrated that I wasn't able to take advantage of it.