Terminal, Git, and GitHub for the Rest of Us: Screencast
So you’ve read the tutorials, and still can’t manage to figure out this stuff? What is Git – and why do we even need it? If you fall into this category, much like I did at one point, I’ve recorded a video tutorial that hopes to teach you exactly how to get started. Rather than feeling your eyes blur over as you attempt to comprehend code snippets like “git push origin master,” relax, and let me explain it to you as best as I possibly can!
Other Viewing Options
Further Reading
Write a Plus Tutorial
Did you know that you can earn up to $600 for writing a PLUS tutorial and/or screencast for us? We’re looking for in depth and well-written tutorials on HTML, CSS, PHP, and JavaScript. If you’re of the ability, please contact Jeffrey at nettuts@tutsplus.com.
Please note that actual compensation will be dependent upon the quality of the final tutorial and screencast.

- Follow us on Twitter, or subscribe to the Nettuts+ RSS Feed for the best web development tutorials on the web.






Thanks been waiting for this
Thanks!
Rik de Vos
Is the video out of sync?
Really useful video!
a) I and the majority don’t have a mac
b) Can someone do a screen cast of a GUI version control system.
I would love to learn a version control system, but im one windows and I HATE HATE command line… please can you teach us another vcs , but in GUI…
thanks jeffrey
Now what’s the point of a VCS without the CLI? o.O
http://code.google.com/p/tortoisegit/
You should really take time to learn to use the command line, once you get the hang of it you’ll see the advantages.
i don’t mean this as flame-bait but a majority of serious web developers do seem to have switched to macs. also – the CLI is much more powerful tool than any GUI client could ever be.
Is this a joke? 75% of the world programs in a microsoft language and uses windows and these are VERY serious developers
Gotta agree with Rich — learning to use command line is an invaluable investment as a developer, period.
Hey Jeff, what’s the software u use to search for Terminal? Is it a spotlight replacement/enhancer?
Thanks
It’s free, and is called QuickSilver. http://www.macupdate.com/info.php/id/14831
@Enatom – There are GUI interfaces to Git.
Take a look at http://git-scm.com/tools for a listing.
After a long I love Jeffrey’s Screencasts
Git for the rest of us? The content wasn’t nearly as friendly as the title. This is the first tutorial that angered me. Not that the tutorial is bad, but Git…really…? It’s amazing how they’ve made a concept that seems so basic and simple, so complex in practice (enter Linux joke here). I got lost and almost had a refusal to learn mentality while watching. Maybe it was just info overload or something.
OK, that vent helped. Sorry for the slight Linux bash. Jeffrey, I appreciate all of the tutorials you do on this site.
@CodeJoust – I’ll take a look at those GUI interfaces.
Which part confused you?
It wasn’t confusion as much as the complexity, and it seemed like a lot for such a simple task. Kindof like having a “there has gotta be an easier way” feeling throughout. After reading the title, I just figured…”great, I’ll watch this video, and BAM know how this whole Git thing works.” My heart was slightly broken as I watched the video. Obviously rewatching over and over and nailing this stuff down is what I need to do, I just wasn’t expecting to put that much effort into it
Heck, you introduced me to RegEx and CodeIgniter with such ease, I thought this seemingly simpler topic would be cake. I am downloading an rewatching now. Out of curiosity, if there are GUI’s out there, and this particular tutorial is for “the rest of us,” why did you decide not to use them?
Because there’s a reason why the pros will just use the Terminal. It’s quicker. Once you learn the syntax…it’s simple as can be. It just takes some to time to wrap your head around it.
After rewatching the vid, and reading the 2 previous Git tuts, I’m feeling like I’m starting to get it (corniness and pun intended). Admittedly, I didn’t read the Git tuts prior to watching this video (hey, I like screencasts). It seemed very complex to me the first go-round, but after managing my expectations of how Git works, it was much easier to consume the next viewing. After reading the tuts, I can see why you describe this video as a companion to those written tuts. It makes much more sense when you put all of them together. Thanks.
This was a great tutorial and recap on the other two tuts for Git.
Thanks…
How about something similar for Subversion?
Wow !
That’s good !
Thanks !
Just running “cd” actually takes you back to your home directory.
If you want to go up to your parent you have to type “cd ..”
Hmmm, i can see why it is useful but isn’t there a way to make an automatic “backup” or commitment as it is called in the terminal? Because, now i have to do it manually, knowing myself i will be forgetting it sooner or later, so cant you script it that it will save everything to the remote server every 30min or so ?
I don’t think you’ll find any way to make an automatic commit; this is because Git isn’t a code backup system. Commits should be important points in your projects history. Think of a history book: it won’t tell you everything that happened every month or year, it only highlights the big events that you care about. Your Git commits should mark milestones like new features, bug fixes, etc. You don’t want auto-commits happening half-way through a function
.
Hope that helps!
oh BTW I’ve been meaning to ask, does net-tuts has an IRC channel?
For those of you new to the terminal, one little hint for navigating around… If you start typing the name of a directory (let’s say we have a directory named testProject), after typing tes, you can hit Tab, and the terminal will fill in the rest (assuming you have no other files/directories that start with tes). It helps me quite a bit… especially if you have directories that have really long names, directories with spaces in them, etc.
I feel like this would slow down development if you did it too often, but for large milestones like v0.9, v1.0, v1.1, etc. it would be a great to use
But if something really went wrong, it be faster to go back to a recent commit than to fix a problem manually. And you don’t want to role back to the previous version of the project!
Why do you have to be old to have experience of the command line? Admittedly I did start using computers before GUIs were established but I have also used linux with no GUI installed daily for most of my adult life!
Whoever it was that reckons the “majority” are not on a mac I would love to see Envato’s stats, I’ll be willing to bet otherwise – I love it when someone actualy puts out a screencast/tutorial from a mac point of view. I get sick of people assuming everyone uses windows!
Web developers & coders should be happy and very familier with the command line, it is not old tech, just more direct!
This is great. I have been wanted to start an open source project and this will help me to get started on github.
This is actually very helpful, I still do not know the basics of what a git or what git is… I will spare some time today to try to grasp it.
Its a good video tutorial, i learn a lot and i will start sign up and try it
.
i wuld ask if you Jeffrey and Andrew Burgess have a user in github i can see and follow
Thanks
very nice tutorial
Sweet! Thanks so much!
For those who haven’t seen it:
very interesting talk by Linus Torvalds about #git at Google: http://www.youtube.com/watch?v=4XpnKHJAok8
Git does it’s job really well, but I do think Mercurial is way better to start using and to learn comparing to Git. It has a nice windows gui (tortoisehg), commands are much shorter and easier to get and memorize, it runs equally well on Windows (no need for cygwin or msys), everything can be configured via gui, etc. Also, free plan at bitbucket.org (the equivalent of github for Mercurial hosting) allows hosting one commercial project, whereas on github all your projects must be open source (for the free plan that is). That way, you can just host your commercial project for free there and practice using Mercurial on a real project. Highly reccomended.
To summarise, git is MacGyver and mercurial is James Bond (http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/) but both are marginally better than non DVCS.
What’s the best practice for files containing usernames/passwords?
The best practice is to make sure that usernames and passwords are not hardcoded.
In the case of, say, database config files (for a web framework, for example), you can make an unfilled “example” config file: copy database.yml to database.example.yml or whatever, and leave all parameters blank.
After this, you can add the path to the real configuration file to your .gitignore file – this will instruct git to ignore this file so that it won’t be added to the repository.
More about .gitignore.
Great, thanks. I like the idea of having an example of my config file and then telling git to ignore the real file. That works for me. Thanks.
More git tutorials!
I couldn’t agree more that this is just sooooo freaking complicated for a such simple concept!
Jeffrey Way wrote:
«Because there’s a reason why the pros will just use the Terminal. It’s quicker. Once you learn the syntax…it’s simple as can be. It just takes some to time to wrap your head around it.»
We’re looking at the quicker way to learn how to use it, not which method is quicker (by 5ms…) and require 5 years of learning how to use it!
Saying “how are you” in Hebrew is quicker than saying it in English, but I’m not gonna learn to speak Hebrew, I’ll just learn to say “how are you” in my native language: that will take me 2 minutes to remember it forever, while learning Hebrew would take me 5 years+ to speak it fluently…
Stupid old age, we’re in 2010 for god sake, command line doesn’t exist anymore for 99.9% of computer users! I’ve never used command line and will never use, this is so different from a GUI which is intuitive! With a GUI you don’t need to remember some strange accumulation of letters, you just have to select, drag, drop, or make a simple click to open a menu for more actions, etc. This is so much more natural to click a button “Create a new folder” than remember specific command like “mkdir blablabla…” WTF dude??
Why am I writing all that? This is because of the title of your video, “for the rest of us”, are you serious? This is the most complicated, the most complex, the most incomprehensible, the most cumbersome tutorial I’ve ever watched! While watching I’ve had this feeling over and over that it’s just unconceivable and unbelievable, it MUST be a simpler way to.. create folders and files (and so the rest of the required actions)!!!!!!!!
Change the title of this video and don’t wast people’s precious time. Please.
Thank you.
By the way I’m very surprised by the author, because I learned regex from you and it was just so simple and so intuitive… Did someone force you to put this title or did you choose it by yourself?
Sorry for the hard time, but this is the reality and I’m not the only one to tell that.
Thank you for your time and for your work.
@Patam – I’m sorry you had trouble understanding it. It’s the best I could explain it – and it seems to have helped others.
You’re a developer. Nothing prevents you from installing a GUI-based client for git, but complaining about CLI is completely ridiculous. Depending on the language/frameworks you’re working with, it’s possible that you’ll be using the command line anyway.
Using git from the command line for everyday commands is so ridiculously simple I seriously can’t see what your problem is.
For example, let’s assume you change something in your project:
git add .
git commit
This will first add all changed files to the staging area, which holds changes you’ve made since the last commit and that will be commited next.
Then it will commit the changes, and ask you for a message. That’s all.
Numerous IDE’s have built-in or plugin support for version control systems like Git. Nothing prevents you from using these either.
Yes, this was immensely helpful!
For me personally the first time someone explained the concept in an accessible manner.
(And it worked:
http://github.com/cfleschhut/firstProject)
Thank you Jeffrey for this screencast!
Really, really appreciated!
Hey Jeffrey, I was wondering what type of microphone you used?
Snowball condenser mic.
I’ve already got a git hub account, i’ve generated the id_rsa.pub file with my public key. I logged into my git-hub account, now in the tab to access your ssh public keys, there is a field for titles. What to i insert there?
Great screencast, made me register to the plus account.
Is there a way to make it automatically commit?
No – only because you wouldn’t want to auto commit.
Nice screencast, it was very helpful
Wow…the advertisement is stalling and has taken over 1 minute to fully play…thanks guys. Not even a “No Ad’s” version for the fact that I’m paying for this site.
Awesome.
Hi Seth – If you’ll scroll down an inch or so, there’s a no ads version.
…so
I’m scared to scroll.
Crappy ads on the crappy, slow loading video now!
Double awesome!
You should also check out gitosis – i run this on my development server for all my git repositories – http://bit.ly/8JcIFl
Not that git isn’t complicated, but this screencast makes git seem even more complex due to its attempt to cover many different topics without laying down a firm foundation in any single topic.
Off the top of my head:
1. Terminal
2. vim
3. Secure Shell (SSH)
4. public-key cryptography
5. git
6. GitHub
Each of these are topics unto themselves, and deserve quite a bit of attention on their own. I would not attempt to use git without first understanding basic usage of Terminal, SSH, and public-key cryptography. Those three items are important in very many aspects of computing, and IMO any programmer should make it their business to become familiar with each.
The learning curve of git is fairly steep, I’ll admit, but I don’t think the quick overview of the other items in this list gave the tutorial-watchers a fighting chance. Perhaps the author should consider creating separate screencasts for each of these topics. I think many who’ve posted in this thread would find them useful.
I don’t agree with the decision to use vim here. Someone not familiar with Terminal should not go anywhere near vim, as it’s a modal text editor with immense power and a learning curve to match it. Don’t get me wrong; I love vim, and I’m actually using it to type out this comment, but it takes a commitment from the user and should not necessarily be used casually with beginners. It can be too frustrating. nano, a simpler, non-modal text editor included with OS X by default, would have been a better choice.
git’s basic design is actually fairly simple. In fact, if you view git’s man page (its manual, essentially. type `man git` (w/o backticks) in Terminal to view it), it actually says: “git – the stupid content tracker”. But it is because it is simple that it can be manipulated and used in powerful ways.
It’s not just about save points. It’s about you can manipulate those “save points”. You can create many different branches, each with a different feature, whether experimental or not. You can them selectively merge those branches together, and you can even split up branches into much smaller pieces and organize them however you would like. If you’ve ever wanted to maintain 2+ versions of a project at once, you will love git. There areso many other things I could go into regarding the greatness of git, but it’s something you have to learn about and see for yourself. And it takes some time. Nothing worth doing is ever easy.
However, git isn’t known for being user-friendly. If you’re not interested in GitHub or the distributed nature of git, I would suggest checking out (no pun intended) Subversion (SVN). It’s older and has a fair amount of GUI tools built for it, and is somewhat less confusing due to its non-distributed nature and its lack of staging area. I’m not too educated on SVN so I’ll leave it at that.
If you are interested in git, however, I can recommend a few resources go jumpstart your learning process:
1. Pro Git, the free online version – http://progit.org/book/
2. git ready, a great resource with specific examples – http://gitready.com/
3. Git Community Book – http://book.git-scm.com
4. GitHub Guides – http://github.com/guides/home
5. If you’re into IRC (Internet Relay Chat), check out #git and #github on freenode
So, if you’ve to the free time, I’d absolutely recommend learning git (or SVN, or Mercurial). It will change the way you approach programming. It certainly has for me.
If you have any questions, find on me on Twitter (jaymendoza).
Oh, and no disrespect intended toward Jeffrey Way. I’m glad he’s evangelizing, but I can easily see how a newcomer could feel overwhelmed by the content of this screencast, and I just wanted to do what I could to clarify some things.
Hey Jay – You definitely make valid points. Granted a specific screencast for each would of course be better. But the point of this screencast was to provide almost a fly-by of how you would use it. Obviously a 20 minute tutorial can’t teach everything – and it doesn’t intend to. That’s why I encouraged the viewers to read Andrew’s great articles.
But definitely, Jay – valid points.
You raise a good point. With that said, I believe this screencast serves its purpose.
For those who find themselves frustrated, I’d say to look at this as just that, a fly-by and an introduction, and not a comprehensive overview.
How can I go back to older verion of my file?
Well I’m new to this as well but, i just click on the file and than on the history button, there you’ll find all the previous versions of your file. Have not found a way to download the file but copy/paste will work i guess
If you want to check out an older version of a specific file:
git log
This will give you a list of your commits. Find the commit that contains the version of the file you want, and copy the commit id (something like “commit 4c76a99…”, but you want just the part after “commit”.) You can actually just copy the first 5 or 6 characters of the commit id, as long as it is unique within your repository.
git checkout 4c76a99 path/to/file
where path/to/file is, well, the path to the file you want to check out.
Note that this doesn’t commit the older version of the file to your current branch, it just replaces the file in your working directory and adds the changes (that transform the current file into the older revision) to the staging area. To view the differences between the old and the new revisions of the file, use:
git diff –cached (or –staged, which is a synonym of –cached)
If you want to check out an entire revision, don’t include ‘path/to/file’:
git checkout 4c76a99
Note that those en dashes in –cached and –staged are actually two hyphens. The code on this site appears to convert two hyphens into an en dash.
Please, everybody. Show some respect, the tutorial is awesome, git are awesome AND powerful. If this is too advanced for you then you may have to considerate about you and your development. Sorry for my poor english, my main language is not english..
Hello Jeff, this is a GREAT resource for everybody, I myself would like to learn how to use SVN as I hear it is better for a personal project. Also my IDE PHPDesigner has support for TortoiseSVN but it is still hard to use if you don’t know how. I am thinking that this might help me some in figuring out how to use SVN though. WOuld love to see some tutorials on SVN though in the future thanks
I just downloaded it and its out of sync… is it just me or everyone having the same problem?
Are you sure – I just checked, and it seems to be working correctly for me…