4 ms·

Chacon & Straub’s Pro Git, available for free online [1], is an excellent resource and has a lot of visual diagrams. [1] https://git-scm.com/book/en/v2 https:/

Chacon & Straub’s Pro Git, available for free online [1], is an excellent resource and has a lot of visual diagrams. [1] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

rectang 2y ago
I love this book. It's what helped me move from an intermediate Git user to an advanced one, and I've subsequently trained a bunch of people at different organizations by going through it. However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.
- Tijdreiziger 2y ago
  You’re probably right about that. I used a certain interactive online course when I was a beginner, but they’ve added “AI assistance for guided coding help”, so I hesitate to recommend it. FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc https://git-scm.com/doc
CamperBob2 2y ago
500 pages (excuse me, 501) to document a source control tool. Something went very wrong here early on. But, lacking a time machine and a handgun, it's clearly unfixable.
- Tijdreiziger 2y ago
  The first 6-7 chapters should teach you more than most Git users know (myself included, suppose I might be due a re-read!).
- skydhash 2y ago
  Which you can read easily in a week or two without much effort for something that is currently de facto for software development. The Emacs Manual has ~700 pages.
  - metabagel 2y ago
    This seems wildly optimistic.
- datadrivenangel 2y ago
  1, Source control can get very gnarly when you have multiple editors on a codebase, and 2, good and comprehensive documentation for software is often many times longer than the software it documents. Man pages are a lot longer than -h
skeeter2020 2y ago
I use this whenever I need to look up anything outside of our workflow, but don't believe internalizing the myriad of git details has a very high pay-off. There's probably higher value knowledge in your role that you should prioritize.
- rectang 2y ago
  The payoff comes when you develop a mental model of Git's data structure design, which is stuff like "a branch is a named pointer to a commit" and "the central data structure is a content-addressable store" — and most germane to this thread, "the source control tree is a diagram, and the operations one does to it are diagrammatic". (Thanks mjburgess!) Learning Git's infinity CLI options won't teach you that.
fsloth 2y ago
Does not still fix the root cause that Git is super-bad as an industrial tool - actions that should be trivial push-button activities become incomprehensible command line character soup. The fact there is a book on the subject speaks volumes about how bad it is.
- edflsafoiewq 2y ago
  Like what?
  - fsloth 2y ago
    VCS should be trivial push-button activity (and _is_ except with Git). There is no added value making a thing far less usable than could be. This is not git’s fault - it is what it is. But it is incomprehensible industry selected it as it’s de facto vcs.
    - edflsafoiewq 2y ago
      Give an example of an "action that should be a trivial push-button activity" that requires "incomprehensible command line character soup".
      - fsloth 2y ago
        All of them. A command line should not be the default option. Again, this is not to bash Git. It's a bash on the industry for selecting tool that requires engineers to spend time and effort on non-value adding part of their work rather than offering a solution so simple you would most of the time not even think about it.
- fragmede 2y ago
  If the existence of a book speaks volumes about how bad something is or is not, I have some bad news for you about what's inside libraries. What beloved subject doesn't have a plethora of books written about it?

Chacon & Straub’s Pro Git, available for free online [1], is an excellent resource and has a lot of visual diagrams. [1] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

rectang 2y ago

I love this book. It's what helped me move from an intermediate Git user to an advanced one, and I've subsequently trained a bunch of people at different organizations by going through it. However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.

Tijdreiziger 2y ago
You’re probably right about that. I used a certain interactive online course when I was a beginner, but they’ve added “AI assistance for guided coding help”, so I hesitate to recommend it. FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc https://git-scm.com/doc

CamperBob2 2y ago

500 pages (excuse me, 501) to document a source control tool. Something went very wrong here early on. But, lacking a time machine and a handgun, it's clearly unfixable.

Tijdreiziger 2y ago
The first 6-7 chapters should teach you more than most Git users know (myself included, suppose I might be due a re-read!).
skydhash 2y ago
Which you can read easily in a week or two without much effort for something that is currently de facto for software development. The Emacs Manual has ~700 pages.
- metabagel 2y ago
  This seems wildly optimistic.
datadrivenangel 2y ago
1, Source control can get very gnarly when you have multiple editors on a codebase, and 2, good and comprehensive documentation for software is often many times longer than the software it documents. Man pages are a lot longer than -h

skeeter2020 2y ago

I use this whenever I need to look up anything outside of our workflow, but don't believe internalizing the myriad of git details has a very high pay-off. There's probably higher value knowledge in your role that you should prioritize.

rectang 2y ago
The payoff comes when you develop a mental model of Git's data structure design, which is stuff like "a branch is a named pointer to a commit" and "the central data structure is a content-addressable store" — and most germane to this thread, "the source control tree is a diagram, and the operations one does to it are diagrammatic". (Thanks mjburgess!) Learning Git's infinity CLI options won't teach you that.

fsloth 2y ago

Does not still fix the root cause that Git is super-bad as an industrial tool - actions that should be trivial push-button activities become incomprehensible command line character soup. The fact there is a book on the subject speaks volumes about how bad it is.

edflsafoiewq 2y ago
Like what?
- fsloth 2y ago
  VCS should be trivial push-button activity (and _is_ except with Git). There is no added value making a thing far less usable than could be. This is not git’s fault - it is what it is. But it is incomprehensible industry selected it as it’s de facto vcs.
  - edflsafoiewq 2y ago
    Give an example of an "action that should be a trivial push-button activity" that requires "incomprehensible command line character soup".
    - fsloth 2y ago
      All of them. A command line should not be the default option. Again, this is not to bash Git. It's a bash on the industry for selecting tool that requires engineers to spend time and effort on non-value adding part of their work rather than offering a solution so simple you would most of the time not even think about it.
fragmede 2y ago
If the existence of a book speaks volumes about how bad something is or is not, I have some bad news for you about what's inside libraries. What beloved subject doesn't have a plethora of books written about it?