Git for Windows is provided as installer package by the msysgit project. Download the latest package starting with "Git-", not a "msysgit-..." package (the latter are supposed to be used to build git yourself). Git for Windows comes with a UNIX environment as far as needed by git and also ships with a Bash shell for using the git command line tools:
The easiest way is to use the dmg packages provided by the Git for OS X project.
More complicated but common is to compile git using the homebrew or MacPorts package manager. Advantage is that you can install all kinds of Unix tools using these, disadvantage is you’ll need to install Xcode for the compiler binaries like gcc.
For homebrew, installation goes like this:
Linux distributions provide packages for git, for example Ubuntu 10.10 comes with git 1.7.1:
git init creates an empty git repository in the current folder:
This might surprise readers who are accustomed to traditional version control systems like CVS or SVN. A git repository can be a completely local undertaking. The whole repository content is stored in a folder named .git in the root of the project folder:
Of course git can also work with remote or central repositories, but it does not require them. We will have a look at working with remote repositories in a forthcoming part of the tutorial. For the moment let us enjoy the freedom of creating a repository locally whenever and for whatever reason we may need one!
Your own files in the repository folder are called working tree:
Git internally holds a thing called the index, which is a snapshot of your project files. After you have just created an empty repository, the index will be empty. You must manually stage the files from your working tree to the index using git add:
git add works recursively, so you can also add whole folders:
The same applies if you change a file in your working tree - you have to add this change to the index with git add:
It’s important to realize that the index is a full snapshot of your project files - it is not just a list of the changed files.
git commit takes the contents of the index and creates a new commit:
Committing is a completely local operation, not related to sending something to a remote server. It just takes the contents of the index and keeps a snapshot of your project files as they were in the index:
Similiar to the index a commit is a full snapshot of your project files. Different from traditional version control systems, commits are not numbered. Instead, a commit gets assigned a SHA-1 hash of the snapshot contents:
This may look awkward the first time you see it. But it brings a huge advantage with it: every commit, which is a full snapshot of your project files, is identified by a cryptographically tamper-proof signature of your file contents. If somehow one byte of the contents or history of your files changes, you would end up with an entirely different hash. So you’re guaranteed to get out what you put into a git repository.
Also, you don’t need to write the full commit hash when you want to refer to some specific commit - you can always abbreviate them by their first characters. The first seven characters are usually enough to identify one commit uniquely.
The workflow for editing files in a git repository looks like this: