A simple guide for getting started with git
rogerdudler.github.com
rogerdudler.github.com
"Create a new repository." What is a repository? What do I do with it?
The HEAD is a tree "which points to the last commit you've made". Huh? A tree can point? The one in my garden can't. Also, what's a commit? I thought "commit" was a verb, not a noun.
And so on.
It's nice that people want to make something as complex as git accessible, so I applaud the effort. Nevertheless, this just makes me feel like a moron for not finding it simple. After all, the layout and the pictures make me feel like I should find it simple. But I don't, so it must be me, right? I think it's tutorials like these that keep people on TortoiseSVN.
The meaning of nearly all SCM-related terms in your tutorial are highly git-specific. Making an SCM intro does not really help that. You need to make a git intro.
http://betterexplained.com/articles/a-visual-guide-to-versio...
http://betterexplained.com/articles/intro-to-distributed-ver...
One technique I use is trying to explain the underlying concepts using analogies to what people already know. Most people are familiar with using "Save as..." to create MyResumeOct2010.doc, MyResumeFinal_v1.doc, MyResumeFinal_REALLY.doc, etc. Version control is like a beefed up, automatic "Save as...". You can jump to any version without a mess of different files.
Distributed version control lets you "peel off" individual changes and send them to anyone. If you are making a shopping list with 3 people, you can "peel off" the items that Alice, Bob and Charlie added and put them on your own list.
Once the concepts are clear, you can give them proper names (diffs, revisions, commits, etc.) and things start to click. Anyway, that's what I've found helpful, good luck!
The author takes a top-down approach to teaching, which basically means that he thought about this tutorial from his perspective, someone that was already intimately familiar with the details. This, as you pointed out, is wrong. If this is a tutorial for beginners, you need to have some explanation of what "checking-out" means, what "trees" are, etc. If this tutorial is for advanced users, however, its too sparse to give any new information. So in the end, the tutorial is pretty, but helps neither advanced users nor beginners.
I feel like the examples you give, however, are inefficient for a guide as well -- at what point do we start making assumptions about the reader? For example, you give the example that a beginner might not understand trees, but how do we know they understand anything? Do we believe they don't know trees, but do know how to program, and if so, to what level? Do we assume they are proficient in the terminal, and can even install git if it is not already present? The problem with your approach is that it seems like there's never a point at which we stop.
When I learned a new romantic language (Spanish), we didn't start all the way at the beginning with the alphabet, nor did we try to explain conjugation, past participles. We started with simple phrases -- "Hello", "How are you", "The weather outside is nice", without a real understanding of why we said them. Then, over the years, we peel back the onions of why phrases were the way they were -- Adios (goodbye) was a combined form "A dios"--to the gods. But you shouldn't try to teach that from the onset as you'll overwhelm the learner -- you just continually add on layers until they discover themselves.
Similarly, I feel like for this scenario, a tutorial should set up a scenario that fits the commands perfectly -- don't explain why we use git commit -m, have the first user just go through a few scenarios where they just do it. Then, as they learn, build advanced git tutorials that add on layers, so suddenly they start to uncover all the nuances that git has to offer.
Now, granted, that doesn't extend itself to a "simple guide" if you will, but I feel that these iterative examples that let you think are much better.
The term commit and it's function are made clear in the "add and commit" section. Perhaps the order of "trees" and "add and commit" should be switched, but this hardly makes the guide unusable.
If in doubt, type the commands and see what happens. And, at the very very least, the article is titled "git - the simple guide", not "version control terminology - the simple guide".
Perhaps not everyone is the intended audience, and perhaps some people could supplement this guide with additional reading. I've never used git, and I found this guide clear and useful.
Further, why are we talking in terms of the actual command-line commands? Surely a version control system as popular as this has tools at least as good as TortoiseSVN so that I don't have to actually type commands into a command prompt like some bearded guy from the '70s. I'd much prefer you tell me the name of the popular Windows/Mac client and walk me through the workflow I'll actually use on a day-to-day basis.
Really? I mean, really?
As I say, lots of programmers claim to be more productive from the command line than they are in a visual interface. It doesn't make much sense to try to dispute that, but I still find it quite baffling.
(A goal of Subversion was that its command-line commands produce output which is both easily parsable by humans and machines. But still, I never use it.)
I used to think exactly like this. It takes a while to get used to the CLI workflow, you only start to reap its benefits once you've gained a solid understanding of unix and also developed the autonomy to select the right CLI tools (e.g. tmux, zsh, vim, git) which creates synergy at every tier of your development stack.
I have written software on Windows and Linux, and when it comes to most tasks related to software development, GUIs tend to get in the way. GUIs are useful at first because all your options are laid out before you, but the complexity increases since the functionality of the entire system must be abstracted through a visual interface.
Really? I mean, really?
Kids today!
To be perfectly clear, the command line tools ARE the popular client. The only widely used GUI I'm aware of is the one specific to Github. There are others but they generally expect you to be familiar with the command line workflow. Perhaps this is because Git is easily integrated into IDEs in a way that makes sense for that particular IDE; perhaps it's because the command line interface is actually very good, with features like spelling suggestions (if you've mistyped a command name) and autocompletion scripts (sort of like IntelliSense).
By the way, I can't speak for Windows users but the overwhelming majority of Mac and Linux developers are well aware that their shiny GUIs are thin layers over the gross 70s Unix parts underneath. In this world there's no stigma concerning beards or the 70s, and your dismissal of the command line comes across as backwards and absurd. It's a bit like badmouthing non-Hollywood filmmakers because a lot of them work in foreign languages and you "don't want to read some German thing for four hours" when you go to the movies.
Furthermore, it's possible that the real reason so much of the unofficial Git docs just talk about the command line rather than point you at a GUI client (except for documentation for those clients themselves of course) is that the Git GUI clients are still under so much development and in some cases are really lacking basic features (for instance, last I checked, the TortoiseGit client did not support any way of interacting with the index/staging area, which is a pretty important part of Git).
I think the parting words of the tutorial "Git from the bottom up" described Git as a library for building a version control system, or something like that, and suggested that we have only just begun to see what people can do with it. I kind of like that idea, that maybe it's possible to bury the complexity of Git underneath a really high level interface, although I don't think that I would actually use it. Git's complicated but it's definitely not rocket science. Plus I generally prefer the command line.
I actually have used both tortoiseSVN and git, and I'm actually in love with git!
you should give it a try.
Again, as a beginner, I would tell you that I find git very simple and effective and would strongly encourage you to check it out. Glancing at your profile and comments, I think you'd find it very easy: http://help.github.com/
Here is an image that might clear up some of your questions: http://en.wikipedia.org/wiki/File:Git_data_flow_simplified.s...
I don't use git but I'd like to. I guess I'm the target market in a sense. The key to simplifying a tutorial is removal of jargon. Just tell it like it is.
FYI: This is the line at which I closed the tab: "checkout a repository" - wtf. I don't know what a repository is and now I'm checking it out? is checkout a typo? maybe it should be check-out? either way, I have no way of knowing and confusion has set in. Unfortunately, tab is closed.
I believe that somebody googling git usage is going to be a little bit conversant in the topic of version control.
I also have to say this:
> I believe that somebody googling git usage is going to be a little bit conversant in the topic of version control.
So you seriously believe somebody trying to learn about version control will already know about version control?
For the same reason that I believe someone googling about haskell or erlang probably knows something about programming.
I forget that this site is about startups and not specifically programmers or people with a heavy IT background.
It's my fault and I apologize.
One difference is that you can have multiple of these folders, not only on your local machine but also on remote servers.
A repository is like a slave folder to a master folder, when the master folder is updated (the github folder) the contents are automatically copied to all repositories. In this way, it saves from having to update all folders manually and keeps everything in one place, with only one thing needing changes, which then propogate automatically to where they are needed?
Any idea what version control is?
you can think of a repository as a git-aware folder of code. if you go into your My_Documents folder, type `git init`, it's now a repository. if you click New Repository on github.com, navigate back to your local My_Documents repo, type `git remote add my_github_repo git@github.com:brador/my_documents.git`, you can then push your local repo into that repo with `git push my_github_repo` from your local repo. or if someone else commits to my_github_repo, you can pull changes downstream with `git pull my_github_repo`. git will check repos against eachother for conflicts.
i don't think a "master folder" really makes sense. if you're developing an app, you generally start with that local git init repo, and then you may push it to github. but then you may delete that local repo or go to another computer and type `git clone git@githjub.com:brador/my_documents.git` and it creates a local repo that you can resume working on. i think the point of decentralized version control like git is that there doesn't need to be a master repository. you can always merge repositories into eachother.
I see this pattern all the time where people use the single-word noun form as the verb. It should be "check out" in that instance.
To get people on board with Git, you gotta show that anyone can use it, efficiently. That's how you get the most number of people to adopt - when they can easily see themselves using and trusting Git.
Honestly, I'm not even sure you need to talk about "trees". The first chapter of Pro Git doesn't mention them at all, and this section describes the working dir, the index and HEAD without using the word: http://progit.org/book/ch1-3.html Instead he talks about "snapshots" and "stages".
A repository for what? Is this a folder on my computer somewhere? Should I be moving code into this folder? No idea.
In order to make this tutorial helpful, why not take a simple project and get it working under Git?
For example, let's say right now I have a folder that consists of a single source code file like testapp.php, a README.txt, and then a content folder with some images in it. How can I take this mini project and start using Git to manage my code?
I'm seriously that "beginner" when it comes to Git. I do not understand it at all. Maybe I'm not your audience. This tutorial was FAR from simple IMO.
Some constructive criticism: don't align=center absolutely everything, it makes it difficult to read larger sections of text. If everything is centered, then nothing is centered.
The book is free or can be purchased and explains both git and Mercurial with similar examples. We use it at our office to get novices up to speed on source control.
Joking aside, there is really no need to ruin a great guide by swearing in the subtitle.
I'm not sure I'll ever understand why developers think they need to swear in articles. In this instance, is it because the author is writing in nerd (addressing a seemingly technical concept) and needs to show his article has some universal accessibility by using one of the most understood terms for excrement in the subtitle?
I mean, I'm glad he warned me there is no deep poop in the subtitle because I won't read ANYTHING that has deep doo-doo in it.
Show some maturity: s/shit/stuff (that'd be Sed for replace the word 'shit' with the word 'stuff')
Next time I'll be sure and add in my <sarcasm/> tags for clairty.
How about adding Linux install instructions? Something like,
apt-get install git
Incoming pull request, in case you don't see it.
There exists TortoiseGit:
http://code.google.com/p/tortoisegit/I would recommend http://gitimmersion.com/
I'm not saying git is a totally bad system, but I disagree with people who think git is easy to use.
You don't see thousands of tutorials on the web, and tutorials hitting the HN frontpage on "How to use Subversion", "My personal Subversion workflow", "My .bashrc file containing my aliases for Subversion". I assert the reason is, that they are not necessary (and not, for example, that nobody uses Subversion, or nobody who reads HN uses Subversion.)
See, we also incessantly upvote the latest oneword.js "gimmick", and it'd be inaccurate to assume that these javascript weekend projects fill any sort of demand half the time just because they're so prevalent. I think the community just tends to circulate things that it uses and has an interest in.
The command line is hard to learn, and there is no real way to learn it besides... well, learning it by heart, quirks and all. A bit like learning a foreign language. After a while, you don't notice it any more and you realize how powerful and pleasant git really is.
Here is an article that captures these thoughts fairly well:
http://beust.com/weblog/2010/04/06/git-for-the-nervous-devel...
SVN has had its wave of tutorials and hype (usually comparing it favorably to CVS at the time). Git's wave still seems to be roaring. When the next system comes out, we'll see tutorials for that every couple of weeks too and Git will be where SVN is now.
So for what it's worth, thanks.
Of course you can get started with this guide, but you have no clue what you are doing. It's learning by following the recipe versus learning by understanding.
git checkout tag-name
git reset --hard <commit>This destroys untracked changes and resets your current branch-pointer to <commit>, removing all the commit-history that comes after <commit>. (You can still recover them from the database, e.g. with "git reflog")
But that aside, coming from SVN it makes sense to me, and I've played around with git without really reading into it too much. It's of added interest because deployment and branching seems much less of a hassle with git than with svn.
A good reading is the online book Pro Git which has been mentioned in the comments.
I'm forwarding this my friends who are yet to be using version control. Good stuff.
I know what git is. I know what source control is. To my knowledge toolbox, you just added an explanation of how a git commit->master is different than a push->remote server. Mission accomplished. Win. Author, please continue executing your work and making this world a better place.
http://txlab.wordpress.com/2011/12/02/moving-from-subversion...
It's the best Windows Git client I've found so far.
Is that a "bug"?
Also, brew is a better choice for installing and keeping git up to date.
http://apple.stackexchange.com/questions/18470/why-is-git-no...
If it weren't for git's speed and Linus' name attached to it, I'd be shocked to see any experienced developers using it.
edit: I use git for game development, and we check in some big asset files (uncompressed .wav music tracks etc.). As long as these don't change too often, the repo stays manageable. Up to 10gigs is still a reasonable repository size IMO.