GIT basics: installation, local usage

GIT is distributed, which means that it does not need any server to work. So you can always work "locally" if you want, may be to get some experience with GIT, but of course, it's also possible to use a server, and it's actually easiest to collaborate with others.

GIT installation

On ubuntu, you should install both packages "git-core" and "gitk".

On Windows, I suggest that you install the program "MSYS+GIT".

local-only GIT basic usage

Assume that you have a directory MYWORK/ that you would like to version with GIT. The first think to do is to clean up all temporary/binary files (compiled files, ~ files, ...) and move in another directory all data files that you've never and will never edit by hand (corpora, automatically generated files, ...). All these files shouldn't be versioned. If you do nevertheless version them with GIT, GIT won't complain, but it's a waste of disk space, and it may even create many disturbing conflicts (typically, a PDF file generated by latex will differ whenever you recompile the source, even though the sources are 99% similar).

Now that you have a clean directory, you initialize GIT locally with:

git init

This command creates a hidden directory .git that contains a compressed copy of all the history of your versions. Beware that a single .git directory must exist at the root of the repository that you're versionning. A common beginner mistake consists in creating another .git directory (with git init, or git clone) below an existing one (e.g., in /home/xtof/toto/.git and /home/xtof/toto/tutu/.git). This induces many unpredictable errors...

OK. So you now have a local GIT version of your repository, but without any files in it: you indeed have to tell GIT to add all the files you want to version, one by one, or subdirectory by subdirectory.

git add README.txt LIVENSE.txt src/

When you add a subdirectory (like src/ above), then GIT automatically and recursively add all files and directories below src/. This is why it's important in the first place, before adding anything, to clean the initial directory !

So far, GIT has noted that you made some modifications to the repository, by adding some files into it. But your modifications are still not saved in the version history. To actually save them, you shall run:

git commit -am "I just have added some files"

You can of course put anything meaningfull for you in the comment of this command. Now you're done: All your modifications are saved as a new version. GIT will detect whenever you edit one the versioned files, and store your modifications as a new version whenever you do "git commit" again.

You can also remove a file with "git rm", move or rename a file or directory with "git mv", add other files with "git add", and so on. GIT proposes many commands to do many different things, but the most basic and useful to start with are init, add, rm , mv and of course commit. Just like with linux, every GIT command has a builtin help that you can see with the option --help. For instance:

git commit --help

git --help % for a general help and list of commands

To finish this starter guide, a few useful tricks:

  • "git status onefile" will let you know whether "onefile" is versioned or not, modified or not. A faster way to list all unversioned files is to run "git commit" twice: the first time, GIT will record your modifications, the second time, GIT will detect that you have no modification pending and will then list all untracked files.
  • "gitk" is a very useful command that shows graphically all the history
  • When several people are working on the same repository, you'll probably have conflicts. Conflicts are solved the same way as with SVN, except that you have to explicitely "git add" every file for which you have manually solved the conflict, before doing "git commit".
  • Every version in the history might be identified with a unique SHA (or commit) number that is shown on the left of the gitk window, or when you type "git log". If you need to move to a previous version, the easiest way is to use the first 5 or 6 digits of the target SHA number to identify this version, because the first 5 or 6 digits are usually enough for GIT to know which version you want without ambiguity.
  • GIT is very cautious with your data, so don't hesitate to experiment. It's a good habit nevertheless to regularly "git clone --bare" the full repository in another disk for backup. But in fact, often, when you do some git commands that may destroy something, GIT will automatically "put" you in a new (nameless) branch as a safety guard. This can be sometimes confusing, if you don't know anything about branches... So, try to have a look at "git branch --help" sooner or later !
  • If you are lost and you don't know in which state is your repository, I recommend cloning a fresh copy of your repository somewhere else with "git clone", and examining this fresh copy, which exactly represents the last stable state in the history.


Comments powered by Disqus