Git version control system

In those small tables, at the left we always list the Git commands for the task, while at the right the corresponding Subversion commands you would use for the job are listed. If you are in hurry, just skimming over them should give you a good idea about the Git usage basics.

Before running any command the first time, it's recommended that you at least quickly skim through its manual page. Many of the commands have very useful and interesting features (that we won't list here) and sometimes there are some extra notes you might want to know. There's a quick usage help available for the Git commands if you pass them the -h switch.

Things You Should Know

There are couple important concepts it is good to know when starting with Git. If you are in hurry though, you can skip this section and only get back to it when you get seriously confused; it should be possible to pick up with just using your intuition.

• Repositories. With Subversion, for each project there is a single repository at some detached central place where all the history is and which you checkout and commit into. Git works differently, each copy of the project tree (we call that the working copy) carries its own repository around (in the subdirectory in the project tree root). So you can have local and remote branches. You can also have a so-called bare repository which is not attached to a working copy; that is useful especially when you want to publish your repository. We will get to that.
• URL. In Subversion the URL identifies the location of the repository and the path inside the repository, so you organize the layout of the repository and its meaning. Normally you would have trunk/, branches/ and tags/ directories. In Git the URL is just the location of the repository, and it always contains branches and tags. One of the branches is the default (normally named master).
• Revisions. Subversion identifies revisions with ids of decimal numbers growing monotonically which are typically small (although they can get quickly to hundreds of thousands for large projects). That is impractical in distributed systems like Git. Git identifies revisions with SHA1 ids, which are long 160-bit numbers written in hexadecimal. It may look scary at first, but in practice it is not a big hurdle - you can refer to the latest revision by HEAD, its parent as HEAD^ and its parent as HEAD^^ = HEAD~2 (you can go on adding carrets), cut'n'paste helps a lot and you can write only the few leading digits of a revision - as long as it is unique, Git will guess the rest. (You can do even more advanced stuff with revision specifiers, see the git-rev-parse manpage for details.)
• Commits. Each commit has an author and a committer field, which record who and when created the change and who committed it (Git is designed to work well with patches coming by mail - in that case, the author and the committer will be different). Git will try to guess your realname and email, but especially with email it is likely to get it wrong. You can check it using git config -l and set them with:

  git config -global user.name "Your Name Comes Here"

• Commands. The Git commands are in the form git command. You can interchangeably use the git-command form as well.
• Colors. Git can produce colorful output with some commands; since some people hate colors way more than the rest likes them, by default the colors are turned off. If you would like to have colors in your output:

  git config -global color.diff auto git config -global color.status auto git config -global color.branch auto

• Visualize. You may find it convenient to watch your repository using the gitk repository viewer as you go.

Commiting

For the first introduction, let's make your project tracked by Git and see how we get around to do daily development in it. Let's cd to the directory with your project and initialize a brand new Git repository with it:

git init will initialize the repository, git add . will add all the files under the current directory and git commit will create the initial import, given that repositories are coupled with working copies.

Now your tree is officially tracked by Git. You can explore the .git subdirectory a bit if you want, or don't if you don't care. Do some random changes to your tree now - poke into few files or such. Let's check what we've done:

That's it. This is one of the more powerful commands. To get a diff with an specific revision and path do:

Git embeds special information in the diffs about adds, removals and mode changes:

That will apply the patch while telling Git about and performing those "meta-changes".

There is a more concise representation of changes available:

This will show the concise changes summary as well as list any files that you haven't either ignored or told Git about. In addition, it will also show at the top which branch you are in.

While we are at the status command, over time plenty of the "Untracked files" will get in there, denoting files not tracked by Git. Wait a moment if you want to add them, run git clean if you want to get rid of all of them, or add them to the .gitignore file if you want to keep them around untracked (works the same as the svn:ignore property in SVN).

To restore a file from the last revision:

You can restore everything or just specified files.

So, just like in SVN, you need to tell Git when you add, move or remove any files:

You can also recursively add/remove whole directories and so on; Git's cool!

So, it's about time we commit our changes. Big surprise about the command: