Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two-Minute Guide to Git

garyrobinson.net

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Two-Minute Guide to Git

#31

Post by stormbrew »

SeanLuke wrote: post #18
garyrob wrote: post #2

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…

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.

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.

Re: Two-Minute Guide to Git

#32

Post by kasey_junk »

stormbrew wrote: post #31
SeanLuke wrote: post #18

Earlier quoted context omitted.

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.

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 giv…

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.

Re: Two-Minute Guide to Git

#33

Post by thunderbong »

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...

Re: Two-Minute Guide to Git

#34

Post by thebordella »

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.

Re: Two-Minute Guide to Git

#35

Post by andrewstuart2 »

garyrob wrote: post #14
andrewstuart2 wrote: post #10

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 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. :-)
Post reply on HN