Git is a version control system designed for maintaining source code for all kinds of projects. It is distributed, meaning that each checkout (or "clone") of the repository has sufficient metadata to function as "upstream" (e.g. "server"). This should be seen in contrast of SVN or CVS, where a checkout only serves as a workspace and the server remains a single point of synchronization (and possibly, failure).
Note that it may seem like we are using "Git" and "git" interchangeably in this document. However, we use "Git" as the name of the version control system whereas "git" is a command line frontend for "Git". This also applies to "SVN" vs "svn" and so on.
Understanding Git (as a DVCS) compared to Centralized VCSes
As mentioned, Git is a distributed (and not a centralized) version control system. This means that Git has taken some very different design choices than SVN/CVS did.
The following guide may be helpful to understand some of these key differences. While the guide is based on a DVCS called "hg"/"Mercurial", the concepts (but not all of the command examples) apply equally well to Git.
Note that only the "re-education" part is interesting (that is, all the links for how to use hg/Mercurial are not relevant to understanding Git).
For SVN/CVS users, please also keep in mind that cvs/svn commands and git commands are sometimes vastly different. A notorious example is "checkout":
$ svn help checkout | head -n1 checkout (co): Check out a working copy from a repository $ git help | grep checkout checkout Checkout a branch or paths to the working tree
In the given example, the svn command is copying data from a remote server and the git command changes the state of the local copy (possibly discarding local changes depending on usage).
Installing Git
You can download Git frontends from git-scm.com. If you intend to use the repos.gbar.dtu.dk service from G-Bar, we recommend you ensure you have version 1.7.10 or newer.
Using Git
Note: If you have been using SVN or CVS before, it is recommended that you have read Understanding git compared to Centralized VCSes first.
Git is commonly used via the command line, but a myriad of graphical user interfaces exists for Git. Depending on your preferences and skills it may be advisable to use one of these instead of the command line.
Note that the following guides are intended as a quick start and not a substitute for reading the documentation.
Using the command line frontend, git
You can play a bit with Git online via the interactive "try git" tutorial, which briefly guides you through some of the common steps.
Starting from the beginning. The git command line has built-in help via the "help" command. If you are stuck:
$ git help
usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[... list of various options ... ]
The most commonly used git commands are:
add Add file contents to the index
[... list of more commands ... ]
You can also add a command after "git help", in which case you can receive a small manual on the given command.
The first time you use git
The first time you use git on a given machine, you most likely want to run (some of) the following commands:
$ git config --global user.name "<Your full name>" $ git config --global user.email "<your-email@example.com>" $ git config --global color.ui true
The first two commands tells git about your name and email. These will be used as a part of the commit messages you do. The third command requests git to use colours in its output if supported (and where it makes sense).
Note without the "--global", these options are set per repository. This may be useful if you maintain several projects and have to use different emails for some of them.
If these commands have been run correctly, the following commands should print the values:
$ git config user.name <The name you supplied> $ git config user.email <The email you supplied> $ git config color.ui true
Note the "--global" is not needed here if you used it in the first round (and you do not have "per repository" settings for these config options).
The basic commands of git
There are a couple of basic git commands that you will almost certainly need. These are something like:
# One of init or clone $ git init $ git clone https://repos.gbar.dtu.dk/git/<owner>/<repos>.git [<local-name>] # Any number of these interleaved $ git add file/or/dir $ git rm [-r] file/or/dir # commit staged changes locally. $ git commit [-m "commit message"] # Fetch changes from others or push changes done to another repository $ git pull [<name-of-remote> <name-of-branch>] $ git push [<name-of-remote> <name-of-branch>]
The "git init" and "git clone" commands are used to create a completely new repository and clone an existing repository respectively. If you clone an existing repository, git will generally use it by default for some commands (e.g. git pull).
Once you have a repository, you can start adding or modifying its contents. After which you can use "git add" and "git rm" to stage these changes. Once you are satisfied with your changes you can commit them locally via "git commit".
Note for the lazy user, there is also "git add --all" to stage all changes. Though for larger changesets, it may be prudent to split them into smaller pieces (e.g. via "git add -p").
Whenever you want to synchronize with others, you generally use "git pull" or "git push" to receive and send changes (respectively). Though depending on your workflow, you may prefer to replace "git pull" with "git fetch" and manually merging the changes via "git merge".
Keep in mind that you should generally not have any uncommitted changes when you merge or pull. git will refuse to merge if it detects it might conflict with uncommitted changes. git stash may come in handy here:
# First "stash" (hide) your uncommitted changes # (NB: you can use git stash save "<name>" if you want to # name your changes) $ git stash [...] # Now pull the changes from the server - this step may involve # resolving merge conflicts. $ git pull [... receive changes and possibly resolve merge conflicts ...] # With the pull done, you can now bring back your uncommitted # changes. Note that these changes may cause conflicts if they # do not "apply cleanly" anymore. This is basically just a form # of a merge conflict. $ git stash apply [...] # Assuming you are happy with the changes from the stash, you # can now drop them from the stash with: $ git stash drop
Note the last two steps can be reduced to "git stash pop".
