Two-Minute Guide to Git(garyrobinson.net)
garyrobinson.net
Two-Minute Guide to Git
http://www.garyrobinson.net/2014/10/git-in-two-minutes-for-a-solo-developer.html
10 comments
Your useful guide aside: why not have him use mercurial?
git has a very steep learning curve and an interface only a mother could love. Mercurial on the other hand has a clean interface very similar to svn, and has all the advantages of git that you list above. And can be straightforwardly run over apache to boot. Also the command is one letter shorter than git.
git has a very steep learning curve and an interface only a mother could love. Mercurial on the other hand has a clean interface very similar to svn, and has all the advantages of git that you list above. And can be straightforwardly run over apache to boot. Also the command is one letter shorter than git.
First, I know git, and not mercurial.
Second, I don't think there is a steep learning curve for the subset included in my post.
Third, I think git has enough momentum that it makes sense for beginning programmers to focus on it. I suspect Mercurial will get a lower and lower percentage of the market place over time, because programmers will generally need to learn git at some point, and once they've done so, there is less reason for them to go against the tide on their next project by learning Mercurial. (An "increasing returns" situation.) Maybe I'm wrong about this -- it's just the sense I have. But, see this chart, which I think tends to validate it: http://www.google.com/trends/explore#q=git%2C%20svn%2C%20hg&...
Second, I don't think there is a steep learning curve for the subset included in my post.
Third, I think git has enough momentum that it makes sense for beginning programmers to focus on it. I suspect Mercurial will get a lower and lower percentage of the market place over time, because programmers will generally need to learn git at some point, and once they've done so, there is less reason for them to go against the tide on their next project by learning Mercurial. (An "increasing returns" situation.) Maybe I'm wrong about this -- it's just the sense I have. But, see this chart, which I think tends to validate it: http://www.google.com/trends/explore#q=git%2C%20svn%2C%20hg&...
Both are great, but for a beginner, I too feel that Mercurial is much easier to get started. You don't have to spend any time 'understanding' how it works, just 3-4 commands is all that it takes to use it.
> Mercurial will get a lower and lower percentage of the market place over time
Lots of big projects continue to use Hg, some even switching to it from Git (e.g. FB)
https://hg.python.org/
https://hg.mozilla.org/
https://code.facebook.com/posts/218678814984400/scaling-merc...
> Mercurial will get a lower and lower percentage of the market place over time
Lots of big projects continue to use Hg, some even switching to it from Git (e.g. FB)
https://hg.python.org/
https://hg.mozilla.org/
https://code.facebook.com/posts/218678814984400/scaling-merc...
For purely local use I really don't think there's actually a substantial difference between mercurial and git in terms of interface, mother's love or not. When you start talking about running it over apache you've gone into a whole other use case (and suddenly you have apache as well...).
I also think this is a relatively old complaint. Git's interface has improved a lot in the 1.8-2.1 window of versions, and now gives pretty decent guidance on some of the hairier parts of itself even.
I also think this is a relatively old complaint. Git's interface has improved a lot in the 1.8-2.1 window of versions, and now gives pretty decent guidance on some of the hairier parts of itself even.
For the most part you are right. But the mercurial command line interface is phenomenally better and the basics of vcs work with much less cognitive overhead than git.
You can use subversion without a server; it's especially easy on Windows with TortoiseSVN. TortoiseSVN is one of the easiest tools to use for version control for single-person projects.
http://tortoisesvn.tigris.org/faq.html#noserver
http://stackoverflow.com/questions/2940276/how-to-use-svn-wi...
http://tortoisesvn.tigris.org/faq.html#noserver
http://stackoverflow.com/questions/2940276/how-to-use-svn-wi...
Git was a little abstract for me to comprehend easily using command line so I just didn't use version control. The concepts made sense in theory, and I knew there would be benefits, but it was difficult to really wrap my mind fully.
I recently began using Tower which gave me some visual cues to the concepts others seem to more easily be able to visualize in their head. Once I get more confident in my workflow I may go back and try using Git from the command line again to see how I like it.
I recently began using Tower which gave me some visual cues to the concepts others seem to more easily be able to visualize in their head. Once I get more confident in my workflow I may go back and try using Git from the command line again to see how I like it.
i made a similar list when teaching others programming as well as for a friend so we could do some collaborative literary writing,
i think offsite storage, or publishing, is also of tier one importance and can be distilled to simple instructions:
(0) create an account with bitbucket for free private, or github for free public .. of course you will have to show 'git config --global user.name NAME' and 'git config --global user.email [email protected]', but this step is a one off and can easily be ignored after initial setup which you can be present for
(i) 'git remote add origin LOCATION', and 'git remote -v' if you forget where the repo is being sent
(ii) 'git push origin master', after ever session
(iii) 'git pull origin master', before ever session
i think offsite storage, or publishing, is also of tier one importance and can be distilled to simple instructions:
(0) create an account with bitbucket for free private, or github for free public .. of course you will have to show 'git config --global user.name NAME' and 'git config --global user.email [email protected]', but this step is a one off and can easily be ignored after initial setup which you can be present for
(i) 'git remote add origin LOCATION', and 'git remote -v' if you forget where the repo is being sent
(ii) 'git push origin master', after ever session
(iii) 'git pull origin master', before ever session
I would add "you don't have to list any filenames on the commit line - use -a for all of them, or add them again one by one (or in groups) before calling git commit.
My younger brother is doing his project and he uses TortoiseSVN on windows all by himself. I think that would be a better start.
well, all these points valid for all DVCS, not just Git.
[deleted](3)
This is a great little guide. Nicely done!
But my suggestion would be to use a nice Git GUI instead of the command line. SmartGit is free for non-commercial use and is quite wonderful. It's both easier to use than the command line (by a long shot) and it's actually more powerful too. Many operations that take multiple command line steps are a single command in SmartGit.
There is also SourceTree or the more limited Git GUIs for Mac and Windows from GitHub, but SmartGit is my favorite.
Maybe I'll take your writeup and convert it to a similar guide for SmartGit! :-)
But my suggestion would be to use a nice Git GUI instead of the command line. SmartGit is free for non-commercial use and is quite wonderful. It's both easier to use than the command line (by a long shot) and it's actually more powerful too. Many operations that take multiple command line steps are a single command in SmartGit.
There is also SourceTree or the more limited Git GUIs for Mac and Windows from GitHub, but SmartGit is my favorite.
Maybe I'll take your writeup and convert it to a similar guide for SmartGit! :-)
My philosophy is that when you use the command line, a) You learn the tool better, and b) wherever you are where there's git, you can use it. No need to install anything else.
I had that philosophy back when I used Subversion, and I think it served me well. It really isn't that hard to use the command line. Especially if you use the subset in my post. I also suspect that GUI tools will generally have the power to deal with staging, branching, etc, and may thus be harder for a total newbie to understand, and more intimidating, than the few commands I outlined in the post.
That's my take on it anyway. YMMV, of course!
I had that philosophy back when I used Subversion, and I think it served me well. It really isn't that hard to use the command line. Especially if you use the subset in my post. I also suspect that GUI tools will generally have the power to deal with staging, branching, etc, and may thus be harder for a total newbie to understand, and more intimidating, than the few commands I outlined in the post.
That's my take on it anyway. YMMV, of course!
GUI tools are nice in some situations, but I find they mostly slow me down. When I'm using Git I want to be fast and a hot-key command window plus the command line is about as fast as you can get.
definitely this. TortoiseGit, for instance, makes everything laughably easy for 95% of most workflows. For the other 5%, you can always drop down to commandline/terminal and then you really need to know what's going on.
I find Fossil[1] to be best DVCS for individuals and small teams. It's like a complete github on your computer. Some salient features -
a. It has a Wiki
b. It has bug tracking
c. It has it's own server
d. It's got a nice and simple web interface. Especially when it visualizes the different branches[2]
e. It's a single file executable across all different operating systems.
f. The Autosync feature[3], which is on by default is, in my opinion, makes version management dead simple. (no pushing and pulling!). This feature by itself makes starting with DVCS really easy.
[1]http://fossil-scm.org/index.html/doc/tip/www/index.wiki
[2]http://fossil-scm.org/index.html/timeline?y=ci
[3]http://fossil-scm.org/index.html/doc/tip/www/concepts.wiki#w...
a. It has a Wiki
b. It has bug tracking
c. It has it's own server
d. It's got a nice and simple web interface. Especially when it visualizes the different branches[2]
e. It's a single file executable across all different operating systems.
f. The Autosync feature[3], which is on by default is, in my opinion, makes version management dead simple. (no pushing and pulling!). This feature by itself makes starting with DVCS really easy.
[1]http://fossil-scm.org/index.html/doc/tip/www/index.wiki
[2]http://fossil-scm.org/index.html/timeline?y=ci
[3]http://fossil-scm.org/index.html/doc/tip/www/concepts.wiki#w...
I had to learn git not too long ago, and found "Git from the bottom up" [1] to be immensely helpful. Until about halfway through reading it I was totally lost, but then everything started to click into place. I had a lot of trouble using git without that decent understanding of the whole system.
This seems like a great guide for people who only need a quick crash course in the specifics of actually using git, but for anyone who still feels lost without that deeper grasp, I definitely recommend "Git from the bottom up".
[1] http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
This seems like a great guide for people who only need a quick crash course in the specifics of actually using git, but for anyone who still feels lost without that deeper grasp, I definitely recommend "Git from the bottom up".
[1] http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
I like the idea but the title's a bit misleading. For comparison, this article is over twice as long as the Git in 5 Minutes guide that you reference. I'm not trying to be snarky, I was just very surprised when I saw the article's length.
People searching for Git in X minutes might prefer a shorter preamble and a more expository form, like this: http://rogerdudler.github.io/git-guide/
/2¢
People searching for Git in X minutes might prefer a shorter preamble and a more expository form, like this: http://rogerdudler.github.io/git-guide/
/2¢
I appreciate this guide, so thank you, Gary.
My own special snowflake story: I am an experienced solo developer interested in getting up to speed with modern version control. I like that Git is popular and I prefer to learn well-supported tools. But every time I approach learning Git for my own needs, I get stymied and confused.
- I don't work in teams with other developers. I have no need to share code with anybody.
- I am not concerned about data loss, per se, because the systems I build include their own custom automated backup solutions.
- I don't develop in a VM on my local machine; I develop on a remote dev machine which is an exact system replica of the remote live machine (minus the software under development).
So what do I want from Git -- or something like it?
I want a good way to manage pushing features from dev to live with granular control. I may be working on 3 features plus a batch of bugfixes on the dev machine. When 1 feature and some of the bugfixes are ready to go I want to be able to push them live without pushing incomplete features live; and of course, I want this all to be as frictionless as possible because I don't want to waste time monkeying around with my dev tools when I should be working on dev itself.
Gary's guide doesn't completely get me here, but it is a nice, accessible start. So many Git resources I have read immediately launch into how Git works under the hood. Guess what? I don't care! Would you teach someone how to drive a car by first explaining how combustion engines work?
Maybe Git isn't the best tool for me after all, but with Gary's guide at least I know what commands to run without filling my head with an engineer's treatise of its internal engineering.
My own special snowflake story: I am an experienced solo developer interested in getting up to speed with modern version control. I like that Git is popular and I prefer to learn well-supported tools. But every time I approach learning Git for my own needs, I get stymied and confused.
- I don't work in teams with other developers. I have no need to share code with anybody.
- I am not concerned about data loss, per se, because the systems I build include their own custom automated backup solutions.
- I don't develop in a VM on my local machine; I develop on a remote dev machine which is an exact system replica of the remote live machine (minus the software under development).
So what do I want from Git -- or something like it?
I want a good way to manage pushing features from dev to live with granular control. I may be working on 3 features plus a batch of bugfixes on the dev machine. When 1 feature and some of the bugfixes are ready to go I want to be able to push them live without pushing incomplete features live; and of course, I want this all to be as frictionless as possible because I don't want to waste time monkeying around with my dev tools when I should be working on dev itself.
Gary's guide doesn't completely get me here, but it is a nice, accessible start. So many Git resources I have read immediately launch into how Git works under the hood. Guess what? I don't care! Would you teach someone how to drive a car by first explaining how combustion engines work?
Maybe Git isn't the best tool for me after all, but with Gary's guide at least I know what commands to run without filling my head with an engineer's treatise of its internal engineering.
I'd add the .gitignore file to the guide, with a link to a site like http://gitignore.io.
I think it's both easy and important to learn early that you don't want to commit binaries and push them around with git.
I think it's both easy and important to learn early that you don't want to commit binaries and push them around with git.
I agree with you -- and it's actually already mentioned, in the little section at the end, "One more thing – optional – may add another minute"
Well shoot, I could have at least done a search of the page before commenting. Serves me right for skipping the optional section. :-)
I really like the Hacker's Guide to Git:
https://wildlyinaccurate.com/a-hackers-guide-to-git
https://wildlyinaccurate.com/a-hackers-guide-to-git
Nice summary. My only observation is that, in practice gitk --all and gitk -- <filename> have completely replaced their git log equivalents for me (and are more universally available than $RANDOM_GIT_GUI).
Two seconds guide from Git: https://subversion.apache.org/
One problem is that even if he googles "git" to find a simple guide, it talks about the server interactions which, frankly, aren't necessary for him for a project like this, and make things a lot more complicated. He's not sharing code with anyone. And he backs up his hard drive regularly, so he's not worried about losing all his code due to a hardware failure.
As opposed to Subversion, git can be used usefully without a server (including the possibility of a local server process), which actually makes git easier to get started with than Subversion.
So I wrote him a very brief guide for that kind of very simple, one-person use. Another benefit: when he needs to share code, and starts to feel the need to do things like branching, he'll already know some basics of git and so it won't be a big jump to start harnessing more of git's power.
I thought I'd post my guide it to HN in case anyone else finds it useful for that type of situation.