I don't get this. Sure, the tutorial looks very pretty, but it does not explain any concepts.
"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.
I agree with you in general, but I feel like you take a wrong perspective of it.
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.
Coming from my perspective (I'm familiar with the concepts of version control, and and a good enough high level understanding of it, but I don't know how to use git and it's commands), I found this very useful and informative. I suppose you could break down knowledge of git into 2 types, WHAT it does, and HOW to use it. I think this tutorial fails at the first part (or doesn't care about it) but is tremendously useful for the second part. It's just a good starting point for someone like me, who knows what it is, but doesn't know how to use it yet.
Indeed. I've been using source control of various flavors for 15 years now, and that "Trees" section is completely unparseable by me. Why are there 3 of them? Why do I care that there are 3 of them? What do I use them for? If I don't use them all directly, why are we talking about them?
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.
> Further, why are we talking in terms of the actual command-line commands? (...) 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.
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.
To be honest, if you're going to use Git you probably need to at least become familiar with the vocabulary of the command line interface, even if you never use it. This is because so much of the documentation (including unofficial tutorials) and even interfaces of most of the GUI clients are set up to use the same words. This is actually basically a good thing, I think, because it means that switching from one GUI client to another isn't a big deal.
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.
Absolutely. I am aware that lots of developers seem to like the command line, but I can't for the life of me understand why. I think visually, so looking at a visual interface such as Windows Explorer is several orders of magnitude more productive than fiddling around with cd/ls to give me a picture of what's going on. Once I find what I'm looking for, I'd much prefer to right click on it and get on with my day than open up a terminal, type out a path, then try to remember some archaic command syntax.
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.
>am aware that lots of developers seem to like the command line, but I can't for the life of me understand why.
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.
I don't think it's a matter of programmers being productive per se. The greatest benefits of command line are the ability to easily store, share and reproduce actions. It's just text. You don't need screenshots to explain something, and everything is scriptable.
Note that source control in particular is particularly amenable to the command line, since the output of source control commands is blobs of text that refers to text files on disk; grepping around in it and wanting to access, process, or modify those files by name is a common operation.
I'm not sure I agree with that; I mean I use TortoiseSVN and before that TortoiseCVS as my main interface to version control, and have done for the last 10 years. It works perfectly and I don't feel I'm missing the command-line at all.
(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.)
As someone who is used to SVN and Mercurial, I found this pretty useful. The author's going to have to decide what the intended audience is - people who have never used SCM, or people who are considering switching from another SCM (probably SVN).
Presumably I know why I want to use git before I look at this guide. Also, I know what a repository is (in the English sense), but just in case, I typed define repository into google: "A place, building, or receptacle where things are or may be stored." Now "Create a new repository" really is dead simple.
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.
Thanks for your feedback! I completely understand your point. Maybe it would make sense to make another guide with an intro on Source Control Management systems and link it in the git guide. Currently, you need to have a little bit of knowledge on an SCM. But I will think about it.
Hmm, I'm not sure "having a little knowledge on an SCM" does the trick. Let's assume that I've used subversion for years (which surely is SCM). Therefore, for instance, I know that a repository is something on a server that can hold all relevant for my current team (we'll checkout a subdir for each of subproject). Also, I know that committing means sending a change to the server. I also know that I can lock a file and then nobody else can commit it, handy!
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.
I don't know if they are necessarily Git specific, but probably are distributed version control system specific. For example the concept that committing would record your changes to the local repository wouldn't make any sense to a Subversion user, but would make a lot of sense to say a user of Mercurial.
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!
I found this guide very useful, so thanks for making it. :) I've used SVN, Mercurial, and git before, so knowing those made this easy to digest. Plus it covers stuff about git I never knew existed, like gitk. So cool!
Your feedback is probably exactly what the project needs in order to become a better introductory guide. As such, I'm surprised the site doesn't include an obvious link to the GitHub repo/issues [1] so that people who have not been enlightened, or want to contribute better explanations, can share what needs to be clarified.
If you want an easier/more clear guide that the one linked, follow their first-time use tutorial. Learning how it works is as simple as installing it and running their tutorial; it wouldn't take you more than 15 minutes.
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/
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.
Really. For me a repository is somewhere I might leave something...storage...like dropbox maybe? I don't know what it means in the github jargon sense. I have no idea what version control is specifically, but again, I guess it is v1.0 v2.0 etc.
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?
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.
Make a tutorial that follows the workflow of a bad developer, and you can get a lot of people on board. Show us how to undo terrible mistakes. Show us how to work with other bad developers and working with their terrible mistakes.
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.
The giant font doesn't make it any easier to understand. Stuff like 'your local repository consists of three "trees" maintained by git' only makes sense to people who already know how git works.
Exactly. You can use a big happy font, but when step 2 tells me to create a "repository" and I'm already stuck.... well, that's a problem.
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.
I think the problem is that the guide doesn't explain the vocabulary it uses at all. There are programmers (and definitely non-programmers) who might not have heard the word "tree" used to describe a directory filled with files and other directories. It's immediately clear once it's explained, and the guide even has little drawings that look like a directory tree, but for people new to version control and people who have used CVS or SVN this use of the word might be foreign. The same with "commit" since someone coming from another system has a different idea of what that means and someone new to version control has no idea.
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".
I found it pretty helpful with the use of the word "tree" (got it from http://progit.org/). But I definitely need to add some kind of glossary to the page.
Hey pixeldude, there's a lot of negative feedback on here that seems pretty hostile in tone. Don't let it get you down. It's not perfect yet, but you're writing something that I specifically wanted to give others at multiple points in the past.
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.
It was available in paperback for free a few months ago too (may still be, not sure). I got it, for free, in Europe. From the states. I have no idea how that works financially, but it's a great book on a number of levels and Eric has my utmost respect because of it.
This is such a great book. No fluff, just straightforward examples of how to do basic version control. Plus, Eric is a good writer. (Actually, anyone who can take a dull topic like version control and make it entertaining probably qualifies as a great writer.)
"There's just one thing, Dude. Do you have to use so many cuss words?" -- Big Lebowski
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')
Hehe, sorry. The "doo-doo" was used sarcastically - meant to show exactly how out-of-place it is to talk about excrement (using any synonym) in the context of a git tutorial.
Next time I'll be sure and add in my <sarcasm/> tags for clairty.
You should mention the "git gui" command alongside gitk. It's a really great way to see the changes in your working tree, stage files into the index, and finally commit. You can even right click on hunks in the diff and select "Stage Hunk for Commit" to stage just parts of a file. Generally I'm a command-line person but git gui is a lot easier to use than "git add -i" Also, git novices whom I know have generally reacted well to git gui.
It is neither helpful to an expert, nor to a beginner. A beginner will have no clue what the article is talking, like tree etc. An expert cannot really use this as a quick reference or something. Looks flashy, but is it anything more?
I have been using Git for a couple of weeks for my personal projects and got frustrated with it. I literally just finished moving all of my stuff back from Git to SVN before checking HN and reading this. The link you posted is making me have second thoughts and now I want to give it another go. Thanks... I guess.
I think git is not easy to use, and the proof of that is that at least once a month there is a "how to use git" tutorial on the front-page of HN.
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.)
I think tutorials just follow what's hot and what people are using, not necessarily what people have trouble understanding. Git is central to HN as a community, so we upvote things like git articles, and other HNers are more likely to try to learn git because of exposure. Coding projects on HN generally link to a github repository. Someone might create a new git cheatsheet tomorrow, but it doesn't indicate that nobody can understand any of the other git cheatsheets you can find in a google query.
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.
> I think git is not easy to use, and the proof of that is that at least once a month there is a "how to use git" tutorial on the front-page of HN.
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:
There were a lot of articles of that sort around back when SVN was interesting and people were bothering to learn it in large numbers. HN wasn't around then, of course, but I remember it sweeping through the Ruby community at the time.
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.
I am a designer first and fiddle with programming second. Although I use GIT I am no expertert in it and actually this tutorial made a few things fall in place for me.
It looks like a lot of people have a case of the Mondays today. Seriously, these are about the number of commands I had sketched out when first starting on GIT, which I assume is your audience. I do have to say that I get a little tripped up between trying to use page-down and having to position the page. A full page side-swipe presentation format would work well here.
I think this guide needs some general explanation of what git is, and what the thinking behind it is (like here: http://progit.org/book/ch1-3.html).
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.
Please note that this does more then what the parent suggests doing by "git checkout".
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")
Thanks for putting this together, it looks great. I should mention that the word "shit" in the title of this will make it challenging for me to share this with many professional colleagues.
I love this, and I've bookmarked it to email it around when I need to, but I'd love to read something that simplifies setting up git on the server side as a central location for repositories.
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.
This community gets to me on occasion, parallel to that meme with the asian father saying 'Why you no get A+'?
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.
It so happens that I started using git just 2 days ago. Reading the git help was pretty useful, but I didn't want to spend a week reading pro git(the ebook). This tutorial is pretty useful to get someone quickly up and running, and certainly a better alternative than spending my time learning git (not that I won't study the details as I go along) rather than the actual project.
Here I summarized major differences between Subversion and Git -- I wrote this just to avoid explaining the same things to my customers. I hope someone finds it useful:
Although I already learned how to get started in git "the hard way", I think this guide is really helpful for beginners. I know I would have appreciated it. As a matter of fact, the first repo I pushed to github was a guide on how to do do stuff in github =D
In the example where you `git checkout -b feature_x`, I believe you also want to `git merge feature_x` after you `git checkout master`, as the `-d` flag on `git branch -d feature_x` will only delete the branch if it's been merged.
That one has been mostly abandoned by the author, for one that is regularly updated take a look at https://github.com/laullon/gitx which is a fork of the original GitX.
Quite possibly; all of the Macs I have on hand already have Xcode installed so I can't check. But I don't think that's a big issue; if you're developing software you're almost certainly going to want to install Xcode and all the accompanying dev tools anyway.
Pull is the same as doing fetch and merge individually. It's only "bad" in the sense that it might do something you're not ready to do yet. If you fetch first, you can inspect the changes before you merge them.
The biggest problem with Git is the insistence of using command line. Just so you know, when you install the software it provides a simple GUI where you can, you know, click on buttons instead of memorizing commands.
I don't understand; you want page down to go to the next "block"? That would be neat. I'm asking because pagedown seems to "work" as expected on my browser (scrolls down one viewport-height).
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.
"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.