I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have. I used to barely understand git, but after a couple of years working at a company that relies on a rebase workflow, I'd like to think I largely understand how it works. Its nice to recognise pretty much every operation on this cheatsheet.
Is it common that developers still have issues with git after using it professionally for a couple of years? Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P.
> knowledge makes it hard to comprehend the difficulties other people have
The phenomena you describe is known as the Curse of Knowledge [1]
Wikipedia gives an example: A knowledgeable professor might no longer remember the difficulties that a young student encounters when learning a new subject for the first time. [2]
Exactly zero of my mathematics professors, and a large portion of my CS professors managed to adequately account for this. The professors of mine who did manage it remain firmly in my memories as great people and great teachers, while the one's who didn't inhabit an area between complete memory erasure, and disdain for how hard they made my life. This is at the very core of what it means to be a teacher, not just knowing the material, but knowing how to teach the material. I consider many of them to be failures at their main job for failing to navigate the curse.
> In the middle of delivering a lecture, Hardy arrived at a point in his argument where he said: "It is now obvious that..." Here he stopped, fell silent, and stood motionless with furrowed brow for a few seconds. Then he walked out of the lecture hall.
> Twenty minutes later he returned, smiling, and began: "Yes, it is obvious that..."
> I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have.
Once the mind had bootstrapped itself to a concept, it is very hard to empathize with your past self unless you took cares to document the difficulties while still in the confused state, articulating as much detail and as many fallacies encountered as possible.
I always liken it to Wittgenstein's analogy -- don't throw away the ladder after having climbed up upon it!
A version control tool shouldn't take YEARS of usage to be productive, to me that's a red flag. Some engineering tools are just complex because what we're doing might need that flexability so the tools provide a myraid of options or workflows.
But writing software, tracking your changes, being able to back out your changes and getting your changes integrated into a code base should be as low activation energy as possible to be productive.
But again, git wasn't created for "you and me", it was created by one guy for his project, the fact "mere mortals" are using it is kind of our fault.
I understand the commonly used core concepts of git pretty well, and using that knowledge, I can do exactly what I want using Git GUIs (IntelliJ these days). With CLI I can do pulls and commits at most.
What I like most, and isn't available in most UIs, is the ease of selecting individual lines you want to commit. Allows you to make very clean isolated commits most of the times.
> Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P.
I work at a company where every developer uses Sourcetree, a GUI for Git. I don't really have a need to remember Git commands (and what arguments they take) anymore after using a GUI. For me, it is sufficient to know what Git commands do without knowing the semantics.
I can confirm the part about rebase workflow, it really forces you to understand the git model. I sincerely recommend every dev to try it at least once. It also got me into custom power tools for git, like incremental rebase, dual blame, etc.
Too late to edit but I just realized we probably mean very different things by "rebase workflow". I meant making extensive use of Git history editing even on public branches, (with tags serving as backup). I guess the common meaning of "rebase workflow" is just using rebase instead of merge.
Largely we rebase so that all PRs are defacto Fast Forward merges. Rebasing on publicly visible branches (PRs and the like) is common, although rebasing major branches (Master or a release) is not. We're small enough that we can get away with that if we must, though (usually if someone breaks something badly).
Basically, developers rebase all the time on their own branches, and rebase over their target branch (fixing conflicts) so that the PR is fast forward.
Agree on the git model thing, I feel like I have a reasonable idea of how git functions under the hood now, so I can figure out what most operations should do, even if I haven't used them before.
Is it common that developers still have issues with git after using it professionally for a couple of years? Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P.