This intro is easy to follow, and explains things well. I only work on smaller projects at the moment, but it is a little embarrassing to admit that the closest thing I have to version control is some combination of dropbox and time machine recording my old files.
I will probably start by having Xcode create and manage a local repository, but it is also useful to know what is behind that.
The main gripe I have with many git tutorials is how quickly I am exposed to git internals, before even describing how to do basic things like "get the last commit id" or " find where a file changed". I am only slightly interested in the tree structure used to store my data, and as a beginner much more interested in cooperative work flow with a group of developers.
To me, it is one of Git's strengths, that it's internal data structure is simple enough to describe and understand, and doing so brings great clarity to the rest of its operations. For example, knowing that "creating a branch" is literally just writing 40 bytes to a file makes them much more approachable.
But the parent's point is that this internal data structure is irrelevant to the absolute beginner, who is trying to figure out how to use git, as opposed to figuring out how git works under the hood. It is great that the internal data structure is fairly simple, but that does not necessarily mean it should be brought up so early in tutorials. It can be a turn off to people who are learning version control tools for the first time.
From my experience, most people issues with git is because they do not really understand how it works (or try to apply what they've seen with other cvs).
Now I agree that having to understand internals might be seen as an engineering failure, however
* internals are pretty quick to cover
* for students learning software development, I thought it would be interesting to see that you can have very few low-level objects that offer powerful high-level actions
I can see where those things would be interesting for students learning software development, but not everyone who uses git is doing that type of development. To be fair, I am coming at this from the standpoint of someone who uses git for science, rather than software development. Yes, I use it to track changes in code, but vast majority of that code is scripting analysis procedures (so knowing about internal data structures does not directly help me do my job). I also use git to track changes in LaTeX manuscripts. So, while your first point is arguably universally applicable (that knowing the internals would help me use git), the second point does not apply to everyone.
I am not suggesting that all tutorials should jettison an early discussion of the git internals, but merely suggesting that including such a discussion early on, may not be appropriate for some audiences.
> To be fair, I am coming at this from the standpoint of someone who uses git for science, rather than software development
As a software developer, I would rather spend my time on the task at hand (my own development) rather than git internals. I don't understand why so many people apologize for the (imo) poor user-experience that git provides...
> To me, it is one of Git's strengths, that it's internal data structure is simple enough to describe and understand
I find it's _not_ simple enough to describe and understand, and that it almost seems _necessary_ to know it, which takes up cognitive attention/space. I feel like it's a failure of design (poor abstraction, or simply bad engineering) that these sorts of introductions are rehashed over and over and over again. I suspect Git is only popular because
1) Cult of Linus
2) Github
Otherwise, there are other capable more pleasant tools to use...
Yes, things are generally only existent if they are either popular or good (or very new). There's git, and there's mercurial in the world of DVCS. Which is popular? Which is good?
Like with most things, popularity is not derived from what you expect, yet popularity exists for good reason. Git may or may not be perfect, depending on your point of view. However, it's more than sufficient to do the job, and it does the job pretty darn well. The other factor is that it's popular because.... it's popular.
Yes, it's a good idea to take on git because other people use it. It's not a personal tool like your text editor where you can lord over your little realm and customize the crap out of it. git is a collaboration tool.
> Like with most things, popularity is not derived from what you expect
I listed what I suspect...
> yet popularity exists for good reason.
Are you talking about cause or effect ? Does it matter ?
> Git may or may not be perfect, depending on your point of view.
It's not, _nearly_ certainly regardless of ones PoV
> However, it's more than sufficient to do the job, and it does the job pretty darn well.
It's used a lot, and mostly works, sure.
> The other factor is that it's popular because.... it's popular.
What "other factor" is this? I was talking about what I consider weak points and poor engineering -- I'm not denying it's popular... it's practically a verb (people say "git" where "source control management", or "distributed source control management" is what they mean...)
> Yes, it's a good idea to take on git because other people use it.
Network effect, I get it...
> It's not a personal tool like your text editor where you can lord over your little realm and customize the crap out of it.
Well... not everybody is managing the Linux kernel. Not everybody is even collaborating. I use fossil[0] because I'd rather enjoy my development process. It _works_ for me. I don't care if Linus uses git, or if some high-profile codebase is managed by git.
> git is a collaboration tool.
And so are fossil and mercurial. And I've run _many_ projects under fossil, including ~20-person distributed (cross-country) projects that include development, configuration, and release management. No git necessary.
I not saying git isn't popular, or can't do its job. I'm saying: Its a bit hard to understand why git (which I suggest is unnecessarily difficult) is so popular -- I listed my two suspicions.
Just to add another anecdotal point on top of your own. I use git because it gets the jobs done. I don't remotely care that Linus uses it. I've honestly never ran into issues even on 20 person+ teams using simple branch & rebase strategies. To each their own.
I am not sure what your point is. Subversion, git, hg, darcs all get the job done. Was your choice of git based on its superiority over the other ones or just a side effect of its popularity? The problem with git is not that you will run into issues, it is that other vcs provide a saner ui and require less of their users without missing on features.
> "I find it's _not_ simple enough to describe and understand"
I mean, you've got tree, commit, and blob objects, and they only compose in very limited ways. trees can have blobs or trees. Commits can have commits or trees. Blobs don't contain other objects. There are also tag objects, but you don't often need to think about those.
That's pretty damn simple. It's really only a single (very simple) concept more complicated than what filesystems expose to end users (trees and blobs, err I mean, directories and files).
The payoff of spending one or two minutes learning these very basics is that you will be able to derive the answer to "Can git do..." formatted questions without little effort. Not having to resort to documentation or google for those kind of questions saves me tons of time and grief.
I would agree with and extend your remarks that stereotypically all git books begin with creating a nice clean repo and all git users begin by being thrown into the deep end with an existing project.
Rather than writing the tutorial starting from nothing and creating a repo and entering its first commit, it might be very interesting to write a tutorial starting from a simple artificial repo with just a couple branches and commits.
I believe this tendency comes from programming where "the book" usually starts with typing in hello world, but the real world usually starts with maint work on existing code.
I still git-flow, I donno if thats cool or not. HN is extremely fad focused so its possible half the readership don't even know what git flow is/was because it was cool waaaaay back when nosql was going to save us all. It would be interesting if the tutorial reflected git flow or possible alternatives.
Oddly enough I think that is one of the reasons Git is popular: you are exposed early to a learnable mental model. (edit: it is a model of Git's storage interface, not a model of version control or a model of storage implementation)
Honestly, since when is that a great feature? I can't think of any other piece of modern software that requires that of its users (other dvcs with similar feature sets included). Noone should care about "internal" interfaces, no matter if they are easy to learn or not.
Programmers are pretty used to building mental models. And my point was that at least you can learn the git internals, but other "everything magic happens but we don't let you even reason how" source control systems are even less learnable than Git.
Here's a very beginner friendly guide on git and Github. It's for people who may have never used version control in the past: http://www.gotealeaf.com/books/git
Maybe I'm still very rudimentary, but as a beginner trying to understand git off and on for the last few months, this is still too advanced to understand up front.
Could you be a little more explicit about what you find too advanced or what specific points would need more explanations?
I intend to use this as a course material for git total beginners so your feedback is very important to me!
This is a really nice, extensive guide. However, I think when introducing Git and its internals for the first time, it is essential to use graphs/diagrams. This tutorial doesn't have any which is its biggest shortcoming. Regardless, I would still recommend this tutorial to friends.
Agree that diagrams would help clarify some points. I was a bit short on time for this so I thought that only using git outputs could be enough; I will try to spend some time to incorporate some illustrations!
If you do, I highly recommend avoiding the types of graphs that git draws for you and that some tools show. (The ones that show the branching history.) As a beginner, I found the graphs way more confusing than what was actually happening, as it didn't communicate anything I could understand. In fact, it made it look like something else was happening than what actually was.
Interesting. Do you think that confusion comes from the fact that commit history (to not say 'time') is represented vertically (and sometime going upward and sometime downward)?
The guide that OP posted is great, but once I see a wall of text in table of contents, I'm instantly turned off. Again, maybe most people will have a better attention span than I do, but some of them will not
agree, it's definitely not enough for anyone who wants to really understand git, but definitely enough to at least get people in the right ballpark of how things work, and maybe draw analogues to whatever system they came from (hg/SVN/whatever)
This is better than I thought it would be (I read the comments here first). I do agree that some of the content can be glossed over (move some of the internals discussion later in the document), and some figures might be useful -- but you must be careful. I've been fooled by figures more often than I'd like.
Overall I feel like this is a good addition to the Git introduction space.
One big piece of feedback is that would be useful to have a section on obtaining and setting Git up the first time. Especially for Windows users, it may not be obvious.
Thanks for the feedback! Regarding the setup, that could be an addition.
It probably need a clearer write up but I added the "Protocols" section to help people understand that SSH is not a must have; from what I've seen the Windows setup difficulties is mostly about SSH -- would you confirm that?
I'm not sure about SSH. You might be correct. I've gotten my setup to work w/o SSH. Although I've mostly just been using the GitHub Windows client lately. :-\",
Finally, a git introduction for real users !
Those that need to understand how it works rather than repeating commands copy/pasted from "command list" have to read it.
Because soon enough, you'll end up in a specific situation needing a specific command...
33 comments
[ 0.23 ms ] story [ 71.6 ms ] threadI will probably start by having Xcode create and manage a local repository, but it is also useful to know what is behind that.
I am not suggesting that all tutorials should jettison an early discussion of the git internals, but merely suggesting that including such a discussion early on, may not be appropriate for some audiences.
As a software developer, I would rather spend my time on the task at hand (my own development) rather than git internals. I don't understand why so many people apologize for the (imo) poor user-experience that git provides...
I find it's _not_ simple enough to describe and understand, and that it almost seems _necessary_ to know it, which takes up cognitive attention/space. I feel like it's a failure of design (poor abstraction, or simply bad engineering) that these sorts of introductions are rehashed over and over and over again. I suspect Git is only popular because
1) Cult of Linus
2) Github
Otherwise, there are other capable more pleasant tools to use...
edit: formatting, s/Linux/Linus/
Yes, it's a good idea to take on git because other people use it. It's not a personal tool like your text editor where you can lord over your little realm and customize the crap out of it. git is a collaboration tool.
I listed what I suspect...
> yet popularity exists for good reason.
Are you talking about cause or effect ? Does it matter ?
> Git may or may not be perfect, depending on your point of view.
It's not, _nearly_ certainly regardless of ones PoV
> However, it's more than sufficient to do the job, and it does the job pretty darn well.
It's used a lot, and mostly works, sure.
> The other factor is that it's popular because.... it's popular.
What "other factor" is this? I was talking about what I consider weak points and poor engineering -- I'm not denying it's popular... it's practically a verb (people say "git" where "source control management", or "distributed source control management" is what they mean...)
> Yes, it's a good idea to take on git because other people use it.
Network effect, I get it...
> It's not a personal tool like your text editor where you can lord over your little realm and customize the crap out of it.
Well... not everybody is managing the Linux kernel. Not everybody is even collaborating. I use fossil[0] because I'd rather enjoy my development process. It _works_ for me. I don't care if Linus uses git, or if some high-profile codebase is managed by git.
> git is a collaboration tool.
And so are fossil and mercurial. And I've run _many_ projects under fossil, including ~20-person distributed (cross-country) projects that include development, configuration, and release management. No git necessary.
I not saying git isn't popular, or can't do its job. I'm saying: Its a bit hard to understand why git (which I suggest is unnecessarily difficult) is so popular -- I listed my two suspicions.
[0] http://fossil-scm.org
I mean, you've got tree, commit, and blob objects, and they only compose in very limited ways. trees can have blobs or trees. Commits can have commits or trees. Blobs don't contain other objects. There are also tag objects, but you don't often need to think about those.
That's pretty damn simple. It's really only a single (very simple) concept more complicated than what filesystems expose to end users (trees and blobs, err I mean, directories and files).
The payoff of spending one or two minutes learning these very basics is that you will be able to derive the answer to "Can git do..." formatted questions without little effort. Not having to resort to documentation or google for those kind of questions saves me tons of time and grief.
Rather than writing the tutorial starting from nothing and creating a repo and entering its first commit, it might be very interesting to write a tutorial starting from a simple artificial repo with just a couple branches and commits.
I believe this tendency comes from programming where "the book" usually starts with typing in hello world, but the real world usually starts with maint work on existing code.
I still git-flow, I donno if thats cool or not. HN is extremely fad focused so its possible half the readership don't even know what git flow is/was because it was cool waaaaay back when nosql was going to save us all. It would be interesting if the tutorial reflected git flow or possible alternatives.
http://rogerdudler.github.io/git-guide/
"no deep shit"
The guide that OP posted is great, but once I see a wall of text in table of contents, I'm instantly turned off. Again, maybe most people will have a better attention span than I do, but some of them will not
Overall I feel like this is a good addition to the Git introduction space.
One big piece of feedback is that would be useful to have a section on obtaining and setting Git up the first time. Especially for Windows users, it may not be obvious.