My son is creating a software project for a independent study project in high school. I've been nagging him for a while to use version control, and he hasn't done it. I think it's a bit intimidating to be handed a 400-page book on git when he has plenty of other work to do. And also, he doesn't really know, from personal experience, why version control can save him a lot of pain. So he just hasn't taken the time.
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.
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.
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)
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.
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.
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 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@SITE.com', 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.
I'd argue that the one tool you need is something like git to make those small isolated snapshot copies for you. Learn a few commands and you won't have to worry about an ever-growing pile of directores that will just metaphorically topple over eventually.
Then you can make changes ad hoc with confidence that you can quickly and easily revert if something breaks, without having to organize a smattering of cloned directories yourself.
I guess what I'm saying is, the highest ROI for version control is to learn git add, git commit. At least you have the history well-organized for you down the road, with minimal effort on your part. If you need to revert at some point, you can just figure it out when you need it.
To be fair that's a failing of the git user interface. Giving up on the entirety of version control because one of them has a bad UI seems like overkill.
So instead of using a tool that does all this for you, he should do it all manually, himself, in the most tedious way possible? I mean if he was aiming to learn about version control this might be a good approach to teaching the pains that it solves, but git does all this with approximately 4 pretty painless commands: git add, git commit, git log, and git diff.
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.
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.
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".
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.
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.
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).
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.