This document describes the local resources available on faculty computers to support work with the Git versioning system. You can read more about Git itself, for example in the official tutorial, or in the book Pro Git, or its English translation. The following document is not a guide to Git, only to its use in the FI MU network environment.

Publishing your repository

Git is a distributed versioning system, which means that there can be multiple repositories of a single project (for example, from multiple developers) at any one time, and you can distribute or receive changes (commits) between these repositories.

The structure of the Git repository is designed in such a way that no special protocol is needed to read it - for example, it is enough to publish the repository as a regular directory using the HTTP protocol (on FI computers, this means having it under the public_html directory in your home directory - see the document on user WWW pages). So, for example, if I have an existing project in the /home/xpepa/nejakyprojekt repository, I can publish a clone of it as follows:

aisa$ mkdir -p /home/xpepa/public_html/git
aisa$ cd /home/xpepa/public_html/git
aisa$ git clone --bare /home/xpepa/nejakyprojekt nejakyprojekt.git
Cloning into bare repository 'nejakyprojekt.git'...
done.
aisa$ cd nejakyprojekt.git
aisa$ cp hooks/post-update.sample hooks/post-update
aisa$ ./hooks/post-update

Note: so-called bare repositories are always created in a directory with the extension .git.

Typographical note: The italicized parts in the examples are the parts that depend on the user and what naming convention and other features they decide to use. When applying them, change these parts in a way that is appropriate for your environment.

Remember that these files need to be readable by apachefi users or others for proper functioning, see the user HTML pages.

At this point, the public clone of the repository is already available, and you can notify other users of its existence by telling them that it is available under the URL https://www.fi.muni.cz/~xpepa/git/nejakyprojekt.git. So another user can, for example, download your changes to their repository with the command git fetch, or git pull, or even create a clone of your repository with the following command:

nekde$ git clone https://www.fi.muni.cz/~xpepa/nejakyprojekt.git
Cloning into 'nejakyprojekt'...
done.

Restrict access

Using the above procedure, we have created a public clone of your repository. There is no link to the repository yet, so only those you explicitly tell will have access to it. However, in case the URL is guessed (which is not unlikely), there is an option to secure the repository by authenticating it with, for example, a name and password. Since the published repository is really just a directory inside your WWW tree, you can use the standard procedure for authenticated access to user WWW pages.

Such a repository can then be accessed using any of the following commands.

nekde$ git clone https://www.fi.muni.cz/~xpepa/nejakyprojekt.git
Cloning into 'nejakyprojekt'...
Username for 'https://www.fi.muni.cz':
...

# u některých starších verzí gitu (1.7.x) je nutné použít způsob
# s uvedeným přihlašovacím jménem:
nekde$ git clone https://xlogin@www.fi.muni.cz/~xpepa/nejakyprojekt.git
Password:
...

Updating a public repository

If you make additional changes (commits) to your working repository, you can publish them by forwarding them to the public repository using the command git push:

aisa$ cd /home/xpepa/nejakyprojekt
aisa$ vi nejakysoubor.txt # provedeme změnu 
aisa$ git commit -m 'Uprava nejakeho souboru' nejakysoubor.txt
aisa$ git push /home/xpepa/public_html/git/nejakyprojekt.git # zveřejníme
...
To .../nejakyprojekt.git/
   e413f46..b652329 master -> master

Gitweb: web interface to the Git repository

A repository published over HTTP in the way described above is readable by various Git clients, but not by humans. If you want the repository content to be human-readable as well, including versioning information (last modified date, list of changes, list of branches, differences between versions, contents of a particular file in a given or latest version, etc.), you can use a tool like Gitweb. This tool is installed on Aisa's machine, and all you have to do is redirect the directory listings https://www.fi.muni.cz/~xpepa/git/ and https://www.fi.muni.cz/~xpepa/git/nejakyprojekt.git/ to Gitweb. Git client access is preserved, since they never use the directory listing. The repository is then accessible under the same URL by both humans and software clients.

To use Gitweb, simply place a file named .htaccess (note the period at the beginning) with the following content in the directory where you have your public repositories (for example, /home/xpepa/public_html/git from the examples above):

# obsah souboru /home/xpepa/public_html/git/.htaccess:
Options -Indexes
RewriteEngine On
RewriteRule ^$ /git/gitweb.cgi/%{REQUEST_FILENAME} [L,PT]
RedirectMatch permanent ^(/~xpepa/git/)([a-z0-9_/-]*[a-z0-9_-])\.git/$ $1?p=$2.git

You can try out the web interface to Git, for example, at https://www.fi.muni.cz/~kas/git/.

One repository for multiple users

In centralized versioning systems (CVS, Subversion), the only possible approach is that there is one central repository into which all developers project their changes. Git supports different approaches (some of them are described in the man page gitworkflows(7)). One common approach is that a project has one maintainer to whom others offer their changes from their public repositories, he collects them into his repository as he sees fit, and then publishes his repository as the "official version" of the project.

However, centralized access is also possible in Git. To use it, however, you need to have a shared directory, writable by all authorized users. Support for this approach on FI machines is planned for the future. The functionality and setting of access rights will be similar to the faculty Subversion server.