NOTE: This is not a rant, I'm just trying to give you a peek into my mind as I tried out this tutorial. I'm doing my best to describe my confusion.
I have no clue how to use Git, and I've been trying to wrap my head around it for a while. Unfortunately, this is yet another tutorial that is very frustrating even though it's designed to target noobs like myself.
So, I added octocat.txt to my staging area. Success! ... Wait. Why do I care? What did I do? Staging what, for what? Huh?
I committed some random text. Or something. And I typed "-m". So does "git commit -m 'something random'" actually do something? What did I commit to? Arrrggg. Why did I -m !?
Then there's this one: git commit -m 'Add all the octocat txt files'
So it understands plain English? Was that the random text? Is that just some sample text as part of the Tutorial or does that actually work on Git? Oh man, I'm now more confused than when I started.
...
Anyway, for some reason, everyone who tries to describe Git already has such a strong understanding of it and it's oddities, that they are, for some reason, unable to lay it out properly for a noob IMO. I cannot figure out how anyone figures out Git, I assume there was some serious hand holding, because I'm just not grasping it and I usually "get" this stuff rather quickly. Maybe that's the problem, Git isn't something you can just pick up quickly, maybe I need to buy a huge Git how-to book like the old days.
In a nutshell... a project can be described in terms of the changes a user makes over time.
In Git, these changes are called "commits".
Commits contain a change a user has made to the code and some additional useful metadata. This metadata includes the time the change was made, the user's name, a message to describe in general terms what the change was (that -m thing), and so on.
Git itself is a database that stores these commits. Each commit links back to the change before it, forming a chain.
If a single person is working on a project, this may be a linear chain of commits, but if multiple people are working on the same project, two people might make a change to the same text at the same time.
So maybe one person writes "The Nexus 7 costs £159", and another person writes "The Nexus 7 costs $199". If this happened, the chain would split; you'd have two valid changes made to the same text. The act of reconciling these chains is called a "merge". We might choose to use one version or the other, or to combine the two, such as "The Nexus 7 costs $199 (£159)".
That's basically it. The only other thing Git does is to allow you to give commits a human-readable name so you can refer back to them later.
Anyway, for some reason, everyone who tries to describe Git already has such a strong understanding of it and it's oddities, that they are, for some reason, unable to lay it out properly for a noob IMO.
This is a common problem in teaching, technical writing, and other forms of technical instruction.
Even when a good teacher or writer sets out to deliver material to total beginners, it's very tricky to truly enter the beginner's mindset and cast away a lot of the mental abstractions built up over the years.
I think one way to improve this situation is to focus on results and casually use features and techniques along the way rather than focus on features and techniques and have contrived examples to show off them off. The fewer technical terms or domain specific language you can use up front, the better. (I should note I've been very guilty of the contrived example approach, but this is what it's all about.. experimenting and learning what really works for learners :-))
I sympathize. What is really necessary are not tutorials on how to use Git--it isn't that hard, after all, for most of us--but more of a description of actual workflow. Not HOW you issue Git commands; but how to use Git.
It would be interesting to read articles about how a single programmer uses Git, how a small programming team, how a distributed team uses Git. Similar articles about how a team producing art, or text (not programmers) use Git.
There's plenty of Git command tutorials already; let's hear about how you actually use Git.
I figured out Git, and I'm not that clever, so don't worry!
The staging area (aka the index) is where you put things before they become a commit. You don't always want to commit all of your changes at once. The index is there so you can commit the changes you want instead of just committing all the changes every time.
`git commit` means "turn the contents of the index into a commit". A commit is a set of changes that logically go together denoting a version of the repository. A commit needs to have a message describing what the commit does. If you just type "git commit", it opens up an editor for you to type in your commit message. If you want to skip the editor, you can just pass in the -m flag, followed by your commit message in quotes.
Are you familiar with the shell? Are you comfortable with the concept of a linked list? If not, work on those--even if you don't use Git, it's part of being a better programmer. But if you do understand these things, you can fairly easily get a very deep understanding of Git.
Git is a simple, but extremely powerful system. Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying. Until you understand the concepts upon which Git is built, you’ll feel like a stranger in a foreign land.
The following parable will take you on a journey through the creation of a Git-like system from the ground up. Understanding the concepts presented here will be the most valuable thing you can do to prepare yourself to harness the full power of Git. The concepts themselves are quite simple, but allow for an amazing wealth of functionality to spring into existence. Read this parable all the way through and you should have very little trouble mastering the various Git commands and wielding the awesome power that Git makes available to you.
I'm about half way through the Git Immersion tutorials [1], and so far it's been pretty good - clear explanations of what you're doing and why you should care.
Of all the basic version control intros/books, for me nothing beats Version Control by Example[1] book. It first explains the core concepts/commands behind version control such as create, commit, etc and them it goes on to illustrate how these commands actually implemented and used in practice using different version control systems.
The explanation is given for both centralized version control systems, using SVN, as well as for distributed version control systems, using Mercurial and Git (and Veracity).
Give it a try. The digital editions (PDF/EPUB/MOBI) are free for download I think.
Off-topic from the theme of your post, if you really want to learn about git, you could take the path that I did, which was to go by way of Mercurial (otherwise known as hg).
Hg is simpler than git in many ways. There's no "staging" for changes, so "commit" is just taking a snapshot of your files as they are right now. Simple.
And, since it's so simple, that means that you can write a really good tutorial for it, which Joel Spolsky did: http://hginit.com/01.html
Hg is plenty useful in its own right, and it doesn't really deserve to be training wheels for git as I've presented it here. But moving from hg to git is really easy; it makes git just seem like hg with a bunch more features.
Coming from a Subversion & Perforce background, I was initially very confused by Git. There were two things that finally switched-on the old lightbulb for me:
a) Scott's book
b) Actively using Git for all of my personal projects (e.g. small school assignments and code experiments), without using a remote repository. If you defer learning about remote repositories for now, I'm sure the light will switch-on for you as well :)
> Maybe that's the problem, Git isn't something you can just pick up quickly
It is the problem, I think. Git isn't easy to use. It's a powerful tool designed by a very smart person (Linus) to manage a very complex project (the kernel). It's not a toy, and it's not designed for beginners. On top of that, the interface actually isn't that well designed, and is a pretty leaky abstraction layer that in many cases requires you to have some understanding of its internals [1]. But we're programmers, our work isn't always easy and the benefits of using Git or using any distributed version control system outweigh the alternatives (note that I'm not talking about Git vs Mercurial vs Darcs but rather about the previous generation of supposedly easier tools like SVN and CVS). So I really think it's worth struggling to master it and treat it like a first-class tool, that you're going to invest in because it's important, rather than try to find an easy way out.
I'm projecting on to you a little bit, and I apologize for that, but every time a Git tutorial hits the front page of HN, there are people expressing frustration or complaining that Git is too hard or too complex. Yeah, it's not perfect, but honestly, it's a damned good tool, and I think it's absolutely worth investing in. Most things worth learning are hard, and while that's not an excuse for poor tutorials (no comment on this one as I haven't tried it), I don't think programmers who take their profession seriously have much to excuse what seems like our almost constant desire for things to be easy.
Maybe the next generation of version control will be easier to use and have a more beautiful user interface, but Git is here now and there's an ecosystem around it supported by the network effects of its popularity, and I think that does end up outweighing the difficulty.
[1] That said, I think the inner core of its internals, ie representing revision history as a DAG of commits, is actually relatively simple, despite the poor interface. See this for what I think is one of the best intros to Git: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
the best way to learn Git is simply to be forced to use it. and even then you only learn subset you actually need to get the job done but at least it's something to get you started.
I'm not going to post link to yet another git tutorial. I would rather recommend to start with something like Heroku, Appharbor or similar.
I find by far the best way to learn git is actually walking through it with someone who knows, and asking absolutely every question that comes to your mind--force them to break it down. Email me at [email protected] if you want to set up a Skype chat/screenshare sometime, I'd love to teach you. It wasn't that much long ago I was in your shoes!
P.S. And the only way to get better with it after you learn is to use it everywhere. Which is a good idea anyway, because version control is incredibly useful.
I know how you feel. I was working on a very basic project and since i had some hand-holding i used git to publish the code to github, but now the hand-holding has stopped (my mentor doesnt have time to help me) and i'm no longer pushing to Github (dont want to make all my code open source).
It was too much of a learning curve to figure out how to deal with this change where Git was concerned, so i went back to mercurial which has a windows client and is easy enough to get my head round.
I do think that Git is probably more powerful as i see it in much more use in production out there, and at a guess i imagine that for version control it's probably more dependable and reliable than Mercurial - im not really qualified to say - but right now, i'm sticking to mercurial because at least i can wrap my head around it, and that's what matters, for now.
You're right. I'm halfway from git noob to power user. My problem with git is that everything is named badly. index, staging, head, ref, reset, rebase, pull, fetch, merge, all of it could have been named better. The commands could have better arguments. And you're right about most tutorials. They only make sense if you already know git.
These are pretty good. It's when I saw these that I realized everything in git is named poorly:
> Anyway, for some reason, everyone who tries to describe Git already has such a strong understanding of it and it's oddities, that they are, for some reason, unable to lay it out properly for a noob IMO
I for one had a really hard time grasping Git, until I wiped my VC-mindset slate clean, it was primarily my upbringing in a development environment where Centralized Version Control was the king. I read up on Eric Sink's Version Control By Example. It's a great book to lay-out the fundamentals of Git. If you wrap yourself around the concept and not the tool, the use of tools (Git commandlines, Git GUI's) will come naturally.
I can empathize, been in a similar situation myself. Most of the git tutorials out there have a problem that they don't explain much of the 'why' and just tell about the 'how'. They are telling mostly about commands and not about the concepts behind it.
Some guy at Harvard wrote a great tutorial[1] on understanding git conceptually. It has been on of the best git tutorials I have read myself.
I liked http://gitref.org when I started with git. I find it's a good quick reference to common git commands so you can quickly get up and running with git. The rest of learning git is really just practice and searching for how to do stuff when you need to.
It's pretty clear that this tutorial expects you to already have some experience with concepts in revision control. However, the problem is that if you're already experienced in revision control, you would probably find this tutorial a little simplistic and condescending.
Basically, git has a steep learning curve and people haven't found a good way to flatten it out a bit.
The svn book, (and I believe the hg) spends a number of chapters explaining how version control works. It will also give you some background on how things were, and where they're going.
If the git docs don't do a good enough job, I suggest you read/skim the introductory chapters of these two free books.
This is the best intro I've read to get the concepts of distributed version control: http://hginit.com/
It's specific to Mercurial, but git is very similar. If it's the overall concepts that are giving you trouble, that should be effective in removing those blocks.
It sounds like the problem isn't git itself, but the concept of source control in general, which is pretty abstract until you actually dig into a source-controlled project that has other people committing - after that, the understanding comes pretty naturally.
Can we please stop pretending that Git is simple and easy to learn? If that were true then there wouldn't be "Learn how to use Git in <X> minutes!" posts every other day.
The fact of the matter is that Git is incredibly powerful but also complex and hard to learn. This isn't a bash on Git at all. It's ok! Sometimes complicated things are just that, complicated.
I believe we'll have better guides and tutorials if people stop treating Git like it's easier or more simple than it actually is.
It would be nice to get everything on one page. As it is, in my laptop I am scrolling up and down a lot to see the instructions, the terminal, and the local filesystem, which are laid out as three rows in one long column.
I did the tutorial mostly without looking at the filesystem so I could stop scrolling. But I know I missed a few helpful "extra" hints because they were below the fold next to the filesystem.
On the plus side, it piqued my interest. I've been meaning to get around to this.
As someone new to git, I was dissapointed to see that:
git add "*.txt"
added all of the .txt files from the current directory AND all of the .txt files contained within a subdirectory. I would have expected the same files to get added as those that would have shown up using:
ls *.txt
For other new users: I've been told that this is an error in the tutorial. The tutorial forced the use of quotes but apparently they are not required and git would have added only the files that show up with the ls command as indicated above.
EDIT: I'm wrong. Using quotation marks DOES make git fetch .txt files within subdirectories. As pointed out by cellularmitosis, git seems to do it's own "interesting" glob expansion.
What you are looking at is actually part-git, part unix-shell-y.
You did
ls * .txt
Let's try something way crazy, type
echo * .txt
What do you see? All of your txt files right? But that's just echo, not ls.
Ahh. Here's the clinch. When you do " * ", that's called either shell "expansion" or "globbing" depending on your shell. Basically, the shell says "ok, before I run your command, I'm going to look at it and see if I need to do anything on my end"
This is why you can do
$ n=0
$ echo $n
The shell hijacks your input, replacing "$n" with "0", then feeds it into echo
In your example, the shell has hijacked the star in "ls * .txt", replaced it with all of your txt files, say (a.txt, b.txt) and then ran ls.
That means that ls ACTUALLY got
ls a.txt b.txt
And THAT's why it works with echo.
---------
So git add "* .txt" works differently, what gives?
Well, when you put things in double or single quotes you are telling the shell "hey, don't do your usual stuff here". The single quotes are more extreme. If we go back to our n=0 example we can try two more things:
$ n=0
$ echo $n
$ echo "$n"
$ echo '$n'
As you can see, the ' says "relax shell, I have this".
So when you do
git add "* .txt"
you are actually passing the "* .txt" to git.
In most reasonable, sensible programs, the program will look for a file named "asterisk dot t x t" in this case.
It had you use `git add '* .txt'` because there were untracked txt files in the octofamily directory. `git add * .txt` would have just added the txt files in the root of the directory and ignored the octofamily directory.
I wouldn't think this is so much an error as they _want_ you to use '*.txt' to add the files in the subdirectory along with the files in the root. They could have touched better on the difference between quotes and no quotes though.
for those who aren't familiar with the nitty gritty, what's happening here is that bash (your shell) expands the "glob" (* .txt) before it ever runs ls, so what actually gets run isn't 'ls * .txt', it's 'ls foo.txt bar.txt dog.txt' etc.
but when you put quotes around "* .txt", that tells bash not to expand the glob.
so in the above case, '* .txt' is actually getting passed into git, rather than 'foo.txt bar.txt dog.txt' etc. I'm not a git user, but it sounds like git has special handling for "* .txt" which causes it to perform its own glob expansion, which happens to also include descending into directories. hilarity ensues.
EDIT: I can't seem to figure out how to type * .txt without triggering the italicized formatter, so I had to put a space after the asterisk. urgh.
This tutorial is very pretty and does a great job of emulating the local Git experience using just a single interactive webpage. However, Github seems to be trying to introduce Git to a wider audience - namely non-developers.
From the blog post[1]:
"If you know of a developer, designer, or other knowledge worker that would benefit from using Git but that hasn't made the leap just yet, send them over to try.github.com when they have a spare 15 minutes."
As a developer, it would be nice to know how well this tutorial really works for non-developers. To me, it seems that the tutorial introduces way too many concepts and details in a very short time for a non-developer to understand.
For example, there are a lot of people that work daily with a computer but freeze completely when faced with the task of using a command-line interface. Yes, clicking on the command does write it in the console but you still have to know to press the return key to actually execute the command.
I'm not saying people shouldn't learn Git, I'm just wondering what the target audience and purpose of this tutorial is.
I really appreciate the new learning tools to become more adept at programming and the command line. However, I often find myself mindlessly re-typing the commands being thrown at me without really understanding what's going on, or why I'm being asked to do it.
I liked the approach of Ruby Monks where they give you a task and let you guess the syntax. If you got stuck you then look at the solution.
I don't mean to make less of try git, or any other interactive tutorial. We live in a wonderful time where we are able to learn powerful tools without even installing them, so I almost feel bad about making this criticism. But I think current tools could be improved by removing some of the wizardy feeling and allowing users to play around and trying to figure out stuff on their own.
Something that often gets glossed over in explaining version control to a non-developer is, "WTF is happening with my files?"
The concept of a single folder containing multiple versions of your stuff is a big deal; the fact that you can't simply navigate to a branch as if it's a different folder--that you can't "see" all your files at once--is a non-trivial thing to punch through.
This doesn't help you learn Git. It helps you learn the commands for Git if you're already familiar with version control.
I can kind of sort of use Git already but frankly I don't understand what half of the commands do nor do I understand the point of them.
Technically the only commands I would assume you need are:
- Get repository
- Merge repository (with comment)
- Get history/comments
But Git has dozens of different things it can do that expand on the above and learning it all is time consuming and there is no one single place to do so (and no the documentation isn't a good place because it isn't a intuitive way to learn).
The biggest hurdle of using Git is that Git has its own vocabulary for things; and there is nothing "common sense" about that vocabulary. Even people who attempt to explain it assume you know another version control so use vocabulary from that.
Runs a bit slow, but impressive nonetheless. I appreciate the simple but effective interface.
I love when sites do something like this in order to give potential users a quick taste of a language or technology. I already learned Git using the Pro Git book, but this would have come in handy as an introductory lesson.
This also reminds me the of the awesome tryruby.org
As someone without a trained programming background and never once used any version control (last time I programmed was for the ti-83 in middle school), Git at first was tough to pick up.
It wasn't until I went through Michael Hartl's Rails tutorial that I actually learned Github, master/branches, etc., and understood what are commits and pushes.
A lot of these Git tutorials seem to walk you through a series of commands as if knowing the commands is knowing Git.
I think they should focus on scenarios instead. Short stories like: "Bob's code is working well but he wants to try something that might be completely misguided. He knows better than to mess with his working code....." Then at the end of the story a command is introduced. Also, some kind of indication of what Git is actually doing when you issue that command. When you tell Git to branch, what actually happens to the file system? When you say git status, what is it actually looking at?
And please, don't start a tutorial on Git without introducing the three area paradigm (working, staging/index, commit)
Git _isn't_ easy to learn. Not at all. You can't spend 15 minutes looking at a Git tutorial or playing a game which teaches you Git, close the page and exclaim "Excellent! I know Git now!" - you can however put it on your CV, and blag it in that new job you're applying for where you need to understand git.
Like most things in software development, learning by doing is the best option because most people don't have photographic memories, and having a reference is usually essential.
Luckily, we all have one huge reference available to us, for free (more or less), with a thriving community who are more than happy to help: The Internet.
Very slick, but also very slow. Occasionally I have to run a command twice for it to register. Also, it's strange that git's output isn't colorized, considering the "Success!" messages are.
My use of Git is basically to have a dev branch where I commit randomly, like some sort of ftp/backup, and a master branch that I merge from dev if I have a release ready.
The other day I tried to merge only some files from a new "experimental" branch and failed hard. I then realized I had it all wrong about how to successfully commit and manage branches.
And felt so lame :) The sad part is that I am the only one trying to use a CVS at work.
TL;DR : I still need to learn Git, so thank you everyone trying to "teach" it.
This is basically a glorified animation. On the commit stages, try adding a different message than theirs. When you get to the log stage, it shows their messages. :-(
I really love the idea of sponsored courses/tutorials. This type of thing makes me more likely to use Git and GitHub more, and evangelize more.
I have a tough time wanting to pay for a course at a place like code school when I know if I go through the docs/tutorials I'll get it. It's not that I don't think the experience is better, or even (for a certain definition) worth the money. I feel like it is an unnecessary indulgence.
[+] [-] dpcan|13 years ago|reply
I have no clue how to use Git, and I've been trying to wrap my head around it for a while. Unfortunately, this is yet another tutorial that is very frustrating even though it's designed to target noobs like myself.
So, I added octocat.txt to my staging area. Success! ... Wait. Why do I care? What did I do? Staging what, for what? Huh?
I committed some random text. Or something. And I typed "-m". So does "git commit -m 'something random'" actually do something? What did I commit to? Arrrggg. Why did I -m !?
Then there's this one: git commit -m 'Add all the octocat txt files'
So it understands plain English? Was that the random text? Is that just some sample text as part of the Tutorial or does that actually work on Git? Oh man, I'm now more confused than when I started.
...
Anyway, for some reason, everyone who tries to describe Git already has such a strong understanding of it and it's oddities, that they are, for some reason, unable to lay it out properly for a noob IMO. I cannot figure out how anyone figures out Git, I assume there was some serious hand holding, because I'm just not grasping it and I usually "get" this stuff rather quickly. Maybe that's the problem, Git isn't something you can just pick up quickly, maybe I need to buy a huge Git how-to book like the old days.
Sincerely, Frustrated in Programming Land.
[+] [-] weavejester|13 years ago|reply
In Git, these changes are called "commits".
Commits contain a change a user has made to the code and some additional useful metadata. This metadata includes the time the change was made, the user's name, a message to describe in general terms what the change was (that -m thing), and so on.
Git itself is a database that stores these commits. Each commit links back to the change before it, forming a chain.
If a single person is working on a project, this may be a linear chain of commits, but if multiple people are working on the same project, two people might make a change to the same text at the same time.
So maybe one person writes "The Nexus 7 costs £159", and another person writes "The Nexus 7 costs $199". If this happened, the chain would split; you'd have two valid changes made to the same text. The act of reconciling these chains is called a "merge". We might choose to use one version or the other, or to combine the two, such as "The Nexus 7 costs $199 (£159)".
That's basically it. The only other thing Git does is to allow you to give commits a human-readable name so you can refer back to them later.
[+] [-] petercooper|13 years ago|reply
This is a common problem in teaching, technical writing, and other forms of technical instruction.
Even when a good teacher or writer sets out to deliver material to total beginners, it's very tricky to truly enter the beginner's mindset and cast away a lot of the mental abstractions built up over the years.
I think one way to improve this situation is to focus on results and casually use features and techniques along the way rather than focus on features and techniques and have contrived examples to show off them off. The fewer technical terms or domain specific language you can use up front, the better. (I should note I've been very guilty of the contrived example approach, but this is what it's all about.. experimenting and learning what really works for learners :-))
[+] [-] rajat|13 years ago|reply
It would be interesting to read articles about how a single programmer uses Git, how a small programming team, how a distributed team uses Git. Similar articles about how a team producing art, or text (not programmers) use Git.
There's plenty of Git command tutorials already; let's hear about how you actually use Git.
[+] [-] philwelch|13 years ago|reply
The staging area (aka the index) is where you put things before they become a commit. You don't always want to commit all of your changes at once. The index is there so you can commit the changes you want instead of just committing all the changes every time.
`git commit` means "turn the contents of the index into a commit". A commit is a set of changes that logically go together denoting a version of the repository. A commit needs to have a message describing what the commit does. If you just type "git commit", it opens up an editor for you to type in your commit message. If you want to skip the editor, you can just pass in the -m flag, followed by your commit message in quotes.
Are you familiar with the shell? Are you comfortable with the concept of a linked list? If not, work on those--even if you don't use Git, it's part of being a better programmer. But if you do understand these things, you can fairly easily get a very deep understanding of Git.
[+] [-] js2|13 years ago|reply
Git is a simple, but extremely powerful system. Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying. Until you understand the concepts upon which Git is built, you’ll feel like a stranger in a foreign land.
The following parable will take you on a journey through the creation of a Git-like system from the ground up. Understanding the concepts presented here will be the most valuable thing you can do to prepare yourself to harness the full power of Git. The concepts themselves are quite simple, but allow for an amazing wealth of functionality to spring into existence. Read this parable all the way through and you should have very little trouble mastering the various Git commands and wielding the awesome power that Git makes available to you.
http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
[+] [-] nhebb|13 years ago|reply
[1] http://gitimmersion.com
[+] [-] to3m|13 years ago|reply
http://git-scm.com/book/en/Git-Basics
[+] [-] kilemensi|13 years ago|reply
The explanation is given for both centralized version control systems, using SVN, as well as for distributed version control systems, using Mercurial and Git (and Veracity).
Give it a try. The digital editions (PDF/EPUB/MOBI) are free for download I think.
[1] http://www.ericsink.com/vcbe/
[+] [-] adambard|13 years ago|reply
Hg is simpler than git in many ways. There's no "staging" for changes, so "commit" is just taking a snapshot of your files as they are right now. Simple.
And, since it's so simple, that means that you can write a really good tutorial for it, which Joel Spolsky did: http://hginit.com/01.html
Hg is plenty useful in its own right, and it doesn't really deserve to be training wheels for git as I've presented it here. But moving from hg to git is really easy; it makes git just seem like hg with a bunch more features.
[+] [-] splicer|13 years ago|reply
If you prefer a video, try "Getting Git" by Scott Chacon: http://vimeo.com/14629850
Coming from a Subversion & Perforce background, I was initially very confused by Git. There were two things that finally switched-on the old lightbulb for me:
a) Scott's book
b) Actively using Git for all of my personal projects (e.g. small school assignments and code experiments), without using a remote repository. If you defer learning about remote repositories for now, I'm sure the light will switch-on for you as well :)
[+] [-] spacemanaki|13 years ago|reply
It is the problem, I think. Git isn't easy to use. It's a powerful tool designed by a very smart person (Linus) to manage a very complex project (the kernel). It's not a toy, and it's not designed for beginners. On top of that, the interface actually isn't that well designed, and is a pretty leaky abstraction layer that in many cases requires you to have some understanding of its internals [1]. But we're programmers, our work isn't always easy and the benefits of using Git or using any distributed version control system outweigh the alternatives (note that I'm not talking about Git vs Mercurial vs Darcs but rather about the previous generation of supposedly easier tools like SVN and CVS). So I really think it's worth struggling to master it and treat it like a first-class tool, that you're going to invest in because it's important, rather than try to find an easy way out.
I'm projecting on to you a little bit, and I apologize for that, but every time a Git tutorial hits the front page of HN, there are people expressing frustration or complaining that Git is too hard or too complex. Yeah, it's not perfect, but honestly, it's a damned good tool, and I think it's absolutely worth investing in. Most things worth learning are hard, and while that's not an excuse for poor tutorials (no comment on this one as I haven't tried it), I don't think programmers who take their profession seriously have much to excuse what seems like our almost constant desire for things to be easy.
Maybe the next generation of version control will be easier to use and have a more beautiful user interface, but Git is here now and there's an ecosystem around it supported by the network effects of its popularity, and I think that does end up outweighing the difficulty.
[1] That said, I think the inner core of its internals, ie representing revision history as a DAG of commits, is actually relatively simple, despite the poor interface. See this for what I think is one of the best intros to Git: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
[+] [-] lubos|13 years ago|reply
I'm not going to post link to yet another git tutorial. I would rather recommend to start with something like Heroku, Appharbor or similar.
[+] [-] thetabyte|13 years ago|reply
P.S. And the only way to get better with it after you learn is to use it everywhere. Which is a good idea anyway, because version control is incredibly useful.
[+] [-] krmmalik|13 years ago|reply
It was too much of a learning curve to figure out how to deal with this change where Git was concerned, so i went back to mercurial which has a windows client and is easy enough to get my head round.
I do think that Git is probably more powerful as i see it in much more use in production out there, and at a guess i imagine that for version control it's probably more dependable and reliable than Mercurial - im not really qualified to say - but right now, i'm sticking to mercurial because at least i can wrap my head around it, and that's what matters, for now.
[+] [-] chrismealy|13 years ago|reply
These are pretty good. It's when I saw these that I realized everything in git is named poorly:
http://marklodato.github.com/visual-git-guide/index-en.html http://ndpsoftware.com/git-cheatsheet.html
[+] [-] acesubido|13 years ago|reply
I for one had a really hard time grasping Git, until I wiped my VC-mindset slate clean, it was primarily my upbringing in a development environment where Centralized Version Control was the king. I read up on Eric Sink's Version Control By Example. It's a great book to lay-out the fundamentals of Git. If you wrap yourself around the concept and not the tool, the use of tools (Git commandlines, Git GUI's) will come naturally.
[+] [-] vrishabh|13 years ago|reply
Some guy at Harvard wrote a great tutorial[1] on understanding git conceptually. It has been on of the best git tutorials I have read myself.
[1] Understand Git Conceptually - http://www.eecs.harvard.edu/~cduan/technical/git/
[+] [-] motowilliams|13 years ago|reply
[+] [-] zxtang|13 years ago|reply
The section on commit explains what the '-m' option is:http://gitref.org/basic/#commit
[+] [-] raygunomical|13 years ago|reply
Basically, git has a steep learning curve and people haven't found a good way to flatten it out a bit.
[+] [-] mixmastamyk|13 years ago|reply
[+] [-] nollidge|13 years ago|reply
It's specific to Mercurial, but git is very similar. If it's the overall concepts that are giving you trouble, that should be effective in removing those blocks.
[+] [-] kevinqi|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] arms|13 years ago|reply
For a more in-depth guide, check out the Pro Git book @ http://git-scm.com/book. You can read it online for free.
[+] [-] mbq|13 years ago|reply
[+] [-] opminion|13 years ago|reply
[+] [-] forrestthewoods|13 years ago|reply
The fact of the matter is that Git is incredibly powerful but also complex and hard to learn. This isn't a bash on Git at all. It's ok! Sometimes complicated things are just that, complicated.
I believe we'll have better guides and tutorials if people stop treating Git like it's easier or more simple than it actually is.
[+] [-] msg|13 years ago|reply
I did the tutorial mostly without looking at the filesystem so I could stop scrolling. But I know I missed a few helpful "extra" hints because they were below the fold next to the filesystem.
On the plus side, it piqued my interest. I've been meaning to get around to this.
[+] [-] p2e|13 years ago|reply
EDIT: I'm wrong. Using quotation marks DOES make git fetch .txt files within subdirectories. As pointed out by cellularmitosis, git seems to do it's own "interesting" glob expansion.
[+] [-] kristopolous|13 years ago|reply
Let me explain what's happening.
What you are looking at is actually part-git, part unix-shell-y.
You did ls * .txt
Let's try something way crazy, type echo * .txt
What do you see? All of your txt files right? But that's just echo, not ls.
Ahh. Here's the clinch. When you do " * ", that's called either shell "expansion" or "globbing" depending on your shell. Basically, the shell says "ok, before I run your command, I'm going to look at it and see if I need to do anything on my end"
This is why you can do
The shell hijacks your input, replacing "$n" with "0", then feeds it into echoIn your example, the shell has hijacked the star in "ls * .txt", replaced it with all of your txt files, say (a.txt, b.txt) and then ran ls.
That means that ls ACTUALLY got
And THAT's why it works with echo.---------
So git add "* .txt" works differently, what gives?
Well, when you put things in double or single quotes you are telling the shell "hey, don't do your usual stuff here". The single quotes are more extreme. If we go back to our n=0 example we can try two more things:
As you can see, the ' says "relax shell, I have this".So when you do
you are actually passing the "* .txt" to git.In most reasonable, sensible programs, the program will look for a file named "asterisk dot t x t" in this case.
But alas, our friends at git have decided to be tricky. The ' * ' syntax for git is similar to gitignore-like syntax (http://www.kernel.org/pub/software/scm/git/docs/v1.7.10/giti...)
"Awesome", you exclaim! Not so fast. It's not the same.
So git add '!1' doesn't work. git add 'one/ * * ' doesn't work, only git add ' * ' seems to work.
Why is it so hard? Good question! I haven't any idea. But we can commiserate together ... you know, over twitter.
Have a good one!
[+] [-] Sindacious|13 years ago|reply
I wouldn't think this is so much an error as they _want_ you to use '*.txt' to add the files in the subdirectory along with the files in the root. They could have touched better on the difference between quotes and no quotes though.
[+] [-] cellularmitosis|13 years ago|reply
but when you put quotes around "* .txt", that tells bash not to expand the glob.
so in the above case, '* .txt' is actually getting passed into git, rather than 'foo.txt bar.txt dog.txt' etc. I'm not a git user, but it sounds like git has special handling for "* .txt" which causes it to perform its own glob expansion, which happens to also include descending into directories. hilarity ensues.
EDIT: I can't seem to figure out how to type * .txt without triggering the italicized formatter, so I had to put a space after the asterisk. urgh.
[+] [-] juriga|13 years ago|reply
From the blog post[1]:
"If you know of a developer, designer, or other knowledge worker that would benefit from using Git but that hasn't made the leap just yet, send them over to try.github.com when they have a spare 15 minutes."
As a developer, it would be nice to know how well this tutorial really works for non-developers. To me, it seems that the tutorial introduces way too many concepts and details in a very short time for a non-developer to understand.
For example, there are a lot of people that work daily with a computer but freeze completely when faced with the task of using a command-line interface. Yes, clicking on the command does write it in the console but you still have to know to press the return key to actually execute the command.
I'm not saying people shouldn't learn Git, I'm just wondering what the target audience and purpose of this tutorial is.
[1] https://github.com/blog/1183-try-git-in-your-browser
[+] [-] duopixel|13 years ago|reply
I liked the approach of Ruby Monks where they give you a task and let you guess the syntax. If you got stuck you then look at the solution.
I don't mean to make less of try git, or any other interactive tutorial. We live in a wonderful time where we are able to learn powerful tools without even installing them, so I almost feel bad about making this criticism. But I think current tools could be improved by removing some of the wizardy feeling and allowing users to play around and trying to figure out stuff on their own.
[+] [-] robbiemitchell|13 years ago|reply
The concept of a single folder containing multiple versions of your stuff is a big deal; the fact that you can't simply navigate to a branch as if it's a different folder--that you can't "see" all your files at once--is a non-trivial thing to punch through.
[+] [-] UnoriginalGuy|13 years ago|reply
I can kind of sort of use Git already but frankly I don't understand what half of the commands do nor do I understand the point of them.
Technically the only commands I would assume you need are:
- Get repository - Merge repository (with comment) - Get history/comments
But Git has dozens of different things it can do that expand on the above and learning it all is time consuming and there is no one single place to do so (and no the documentation isn't a good place because it isn't a intuitive way to learn).
The biggest hurdle of using Git is that Git has its own vocabulary for things; and there is nothing "common sense" about that vocabulary. Even people who attempt to explain it assume you know another version control so use vocabulary from that.
[+] [-] tsurantino|13 years ago|reply
[+] [-] arms|13 years ago|reply
I love when sites do something like this in order to give potential users a quick taste of a language or technology. I already learned Git using the Pro Git book, but this would have come in handy as an introductory lesson.
This also reminds me the of the awesome tryruby.org
[+] [-] EricDeb|13 years ago|reply
[+] [-] lambtron|13 years ago|reply
It wasn't until I went through Michael Hartl's Rails tutorial that I actually learned Github, master/branches, etc., and understood what are commits and pushes.
[+] [-] grannyg00se|13 years ago|reply
I think they should focus on scenarios instead. Short stories like: "Bob's code is working well but he wants to try something that might be completely misguided. He knows better than to mess with his working code....." Then at the end of the story a command is introduced. Also, some kind of indication of what Git is actually doing when you issue that command. When you tell Git to branch, what actually happens to the file system? When you say git status, what is it actually looking at?
And please, don't start a tutorial on Git without introducing the three area paradigm (working, staging/index, commit)
Here's a talk by Scott Chacon of GitHub. http://www.youtube.com/watch?v=ZDR433b0HJY
It's over an hour long and very detailed.
[+] [-] basicallydan|13 years ago|reply
Like most things in software development, learning by doing is the best option because most people don't have photographic memories, and having a reference is usually essential.
Luckily, we all have one huge reference available to us, for free (more or less), with a thriving community who are more than happy to help: The Internet.
This tool is, nonetheless, a good starting point.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] taylorfausak|13 years ago|reply
[+] [-] conradfr|13 years ago|reply
The other day I tried to merge only some files from a new "experimental" branch and failed hard. I then realized I had it all wrong about how to successfully commit and manage branches.
And felt so lame :) The sad part is that I am the only one trying to use a CVS at work.
TL;DR : I still need to learn Git, so thank you everyone trying to "teach" it.
[+] [-] gburt|13 years ago|reply
[+] [-] Beltiras|13 years ago|reply
[+] [-] tissarah|13 years ago|reply
I have a tough time wanting to pay for a course at a place like code school when I know if I go through the docs/tutorials I'll get it. It's not that I don't think the experience is better, or even (for a certain definition) worth the money. I feel like it is an unnecessary indulgence.