Specializations exist because nobody can be an expert or even reasonably well informed about how everything works, even their own tools. I don't expect most professional engineers to understand the internals of their text editors or their compilers for that matter. Why should we expect it for something like a source control tool?
The reality is that in basically all profressional domains you are expected to be able to use, at a profressional level, the software required to do your job.
For developers that includes version control and package managers, amongst other things.
Do you need to know how git is implemented? Of course not. No more than you need to know how your compiler converts source code to executables.
...but understanding the basics of the tools (eg. what paths and layer groups are, to compare to photoshop), isn't something you can just wave your hands in the air and say 'not my problem'.
That isn't what I'm arguing; of course we must know how to use our tools. If that requires also understanding implementation details, even trivial ones (e.g., "it's a DAG"), or if the interface and words used to describe the usage are non-standard, awkward, or worse act to obscure what is actually going on, the tool and/or its documentation is poor.
For example: in this case, knowing what a branch is, how to create and delete one, and how to merge with one is necessary. Knowing that the branch identifier is a hash, called a "reference" or similar jargon and what that entails, internally, is superfluous and adds pointless complexity: if that's really required then git isn't good. I have more important things to think about as a developer than what internal machinery operates git.
The fact that commits are organized in a DAG is absolutely not an implementation detail. It's one of the core concepts of distributed version control.
It's also kind of silly to call git's terminology "non-standard". Git was the first truly widely used DVCS, so if anything, git's terminology is the standard terminology by definition.
> I have more important things to think about as a developer than what internal machinery operates git.
That could be extended to other tools like firewall configuration, TLS setup, library details, logging configuratoin, monitoring, etc. But you won't get very far in fixing any problems if you don't read documentation and investigate further.
