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

Publication of your repository

Git is distributed versioning system , which means that there can be several repositories of one project at a time (for example from several developers), and individual changes ( commits ) can be sent or received 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 public_html in your home directory - see the document on user WWW pages ). So, for example, if I already have an existing project in the repository /home/ xpepa/nejakyprojekt , I can publish his clone like this:

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 a suffix .git .

Typographic note: in the examples, italics indicate those parts that depend on the specific user and what project names and other properties he chooses to use. When applying them, change these parts in a way that suits your environment.

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

At this point, the public clone of the repository is already available, and its existence can be reported to other users as being available under the URL. https://www.fi.muni.cz/~ xpepa/git/nejakyprojekt.git . For example, another user can download your changes to their repository with the command git fetch , eventual git pull , or even clone your repository with the following command:

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

Restriction of access

Follow the steps above to create a public clone of your repository. There is no link to the repository yet, so only those to whom you explicitly tell will have it available. However, in case of URL guessing (which is not unlikely), it is possible to secure the directory by authentication, for example with a name and password. Because the published repository is actually just a directory inside your web tree, you can use the standard procedure for authenticated access to user web pages .

Such a repository can then be accessed using one of these 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:
...

Update the public repository

If we make further changes (commits) in our working repository, these can be published by forwarding them to the public repository with 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

The repository published by HTTP as described above is readable by various Git clients, but not by humans. For example, you can use Gitweb if you want the contents of a repository to be human-readable, including version information (date of last change, list of changes, list of branches, differences between versions, contents of a particular file in a given or last version, etc.). This tool is installed on the Aisa computer and you only need a directory listing https://www.fi.muni.cz/~ xpepa/git/ and https://www.fi.muni.cz/~ xpepa/git/nejakyprojekt.git/ redirect to Gitweb. Git clients' access is preserved because they never use a directory listing. The repository is then accessible under the same URL to both people and program clients.

To use Gitweb, just go to the directory where you have your public repositories (for example /home/ xpepa/public_html/ git from the above examples) place the file by name .htaccess (attention, dot at the beginning) with the following content:

# 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 to have one central repository into which all developers project their changes. Git supports various approaches (some of which are described in the man page gitworkflows(7) ). One of the common approaches is that a project has one administrator, to whom others offer their changes from their public repositories, he collects them at his discretion in his repository, and then publishes his repository as an "official version" of the project.

However, a centralized approach is also possible in Git. However, to use it, 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 function and setting of access rights will be similar to those at the faculty Subversion server .