Git tutorial

THE ABSOLUTE LEAST YOU NEED TO KNOW TO BE SEMI-FUNCTIONAL WITH GIT

[With this tutorial, I assume you begin the same way I did with git; no knowledge whatsoever concerning version control systems.]

Git is a version control system. What that means to you: it allows you to store your projects, and maintain and keep track of its changes. What's more, it allows you to contribute to other people's projects, in a way that's flexible for both the other person and you.

While there are git clients out there, I'm going to teach you how to do it live, via the command-line. So make sure you have git ready and installed on your computer.

A SNAPSHOT: HOW GIT WORKS

Say you want to make changes to another person's project. Conveniently, the project is hosted publicly via git. A project, in git-speak, is known as a repo, short for repository; the original repo, usually the one that will be ultimately used, is known as the master repo. And what you do as a contributor is fork the master repo- that is, you create a copy of the entire project, that's linked back to the original copy. This new copy is called a fork, or a branch.

You own your branch. It's all yours. You can make whatever changes you'd like to it, and once you're done, you first commit all your changes. This tells git that you're confident in all of your changes and that you are ready to finalize them. This encapsulates all of your changes into one single point. You can then send a request to the owner of the original repository, asking the owner to look at the changes in your commit, and then include, or merge, the changes into the master repo. And if the owner does like them, they'll accept, and pull the changes into the master. You push, and they pull. Get it?

So what if you're the owner of the repo? You can commit to the master directly, but usually you'll actually have your own fork of the master, to which you make changes and push to the master. Of course, you don't have to give permission to accept your own changes, so the master will pull automatically for you.

And this is ultimately all you're really doing with git, or any version control system- just making changes, and pushing them up. Simple, no?

ENTER THE ALMIGHTY GIT COMMAND

Every git operation is done through the command git. The exact operation you'd like to do is then specified as an argument- and then you can have even more arguments on top of that for further specification. Bit confusing? It might be simpler to just think of all the git commands as having two words, rather than one: instead of git, and then, for example, add as an argument, just think of the entire command as git add.

GIT INIT, ADD, STATUS, AND COMMIT

To start up a git repo, it helps to have some files. First, make sure your active directory is the one you'd like to turn into a repo; from now on, this will be the one that git tracks. Then, run git init. This does everything you need to start up a blank git repo.

Notice I said "blank." That's right: you need to manually add your files into the repo. Adding stuff is a two-step process: adding to the staging area (which I'll define in the next sentence), and committing. The staging area is a list of files git keeps. Any other command that acts upon files will act upon only the files listed in the staging area. So by git adding, you're telling git, for the next commands I'm going to run, I want you to care about these files only, and ignore everything else.

You can run git add on each individual file. Or, if you'd like to add every file, run git add *. Want to add only files of a specific type? Using .png as an example, run git add *.png, replacing png with whatever file type you desire.

To check which files you have on the staging area, use git status. It will list all of the files on the staging area, as well as any files git finds that aren't.

Then, commit; this first commit places references to all the new files into your repo. The command to do this is git commit.

Commits can have messages attached to them; it's good practice to detail what went into each commit. Since this is the first, and you're just setting things up, "Initial commit" will suffice. To include a message, begin with -m, then write your message surrounded by quotations:

git commit -m "Initial commit"

And voila! You now have a git repository working on your hard drive! Unfortunately, unless your hard drive is a server, it's stuck there, isolated...

SETTING UP SHOP WITH GITHUB (OR YOUR GIT HOSTING SERVICE OF CHOICE)
IN THIS SECTION: MEET GIT CLONE AND PUSH

What if you want your master repo to be on Github? Unfortunately, it's a bit too late for that, if you've actually been following along (I really hope you haven't.) So here's how to set up your master on Github, instead of your filesystem:

First, log in to Github, and create a new, blank repository. Github is a fairly clear website; you should be able to figure this out.

What you'll be doing is forking this new master repo on Github, adding commits to your fork, then pushing your additions up to the master. We've been over two of the three tasks here; to fork the project via command-line, you'll need git clone.

Git clone is like init, except instead of being blank, it gives you a copy of another repo, and hooks the new repo up to the original, so that you can push. You don't have to fork your master; in this case, you probably should, because you've got nothing else to fork, but it's perfectly valid in larger projects to fork someone who themself has forked the master, or forked someone who forked the master, or forked someone who forked someone who forked someone...

The URL with which to clone is in a little box in the sidebar labeled HTTPS Clone URL. Copy that and paste it after git clone in your terminal.

Of course, your new cloned repo will still be every bit as blank as the one on Github. But it's still a repo- so you can add your files and make an initial commit, just like before. Then, when you're done, push the commit up to the master with git push. Do whatever authentication Github requires (username and password; not rocket science here!) and then look on Github: if you haven't screwed stuff up, your files and folders should show up on the site!

MAKING CHANGES

Making changes to your existing repo is not a difficult task by any means once you understand the commands above. First, edit the files you want on your hard drive, obviously. Then, you're still going to add, commit, and push; this time, however, only the files that have been changed, added, or removed, need to be placed in the staging area with git add. Once you're done, run git commit, preferably with a quick message detailing what's changed in your commit. (Writing good commit messages is both a responsibility and an art. 50 characters is a mostly-accepted length; if you find yourself going over, perhaps you should make multiple, smaller commits.) Then push it real good.

CONTRIBUTING TO THE WORK OF OTHERS

One of the nice thing about hosting on Github is that it opens contribution to your repo to anyone else who so desires. And this includes you! Say you have a project to which you'd like to make changes, but belongs to someone else. It's simple and almost the same; the only difference: you need to request, after you push, that the owner of the repo pull. But no worries; this happens automatically.

It's considered good practice, at least on Github, to create a fork on Github first, that's associated with your Github account, then fork your own Github fork on your hard drive. Make changes to your fork, push up to your repo on Github as detailed previously, then using Github's UI, submit a new pull request. (If you're wondering, pull requests are something you have to do online, not via command-line.) And hope the owner accepts!

COMO TE LLAMAS

And believe it or not, those are the basics to using git. Now, a bit of housekeeping:

When you commit, your name and email are tracked. If you'd like to change what git sends as your name, use these commands:

git config --global user.name
git config --global user.email

Two things of note here: first of all, don't want to provide this information? That's fine, just provide dummy values. For the email, user@email.com is customary. For the name, use Dick Butt because that's hilarious. (Please don't.)

And that's it! Long tutorial, no? Enjoy using git! And once you understand it, I promise you actually will.