translated by Google

Machine-translated page for increased accessibility for English questioners.

This document describes the local resources available on faculty computers to support work with the Git version . The Git system itself can be read, for example, in official tutorial , or in a book For Git , respectively. in her Czech translation . The following document is not a guideline for Git, just to use it in the FI MU environment.

You can also create a repository at the faculty GitLabu , which additionally supports Issues , Milestones, and Wiki . Find more information here .

Publish your repository

Git is distributed version system , which means that there may be multiple repositories of one project at a time (for example, from multiple developers) at one time, and may be sent or accepted between commits by these repositories.

The structure of the Git repository is designed so that no special protocol is needed for reading it - for example, it's enough to publish the repository as a regular directory (on FIs, so to have it under the directory public_html in your home directory - see the user web pages ). For example, if I already have an existing project in the repository /home/xpepa/nejakyprojekt , I can publish his clone 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'...
aisa$ cd nejakyprojekt.git
aisa$ cp hooks/post-update.sample hooks/post-update
aisa$ ./hooks/post-update

Note: The so-called bar repositories are always created in the end directory .git .

Typographical Note: in italics , the parts that are dependent on a particular user and which project naming and other properties they choose to use are in the examples. When you apply them, change them in a way that matches your environment.

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

At this point, the public clone of the repository is already available, and can be reported to other users by being accessible under the URL . For example, another user can download your changes to your repository with a command git fetch , eventually git pull , or even create a repository clone with the following command:

nekde$ git clone
Cloning into 'nejakyprojekt'...

Access restrictions

Using the above procedure, we have created a public clone of your repository. There is no link to the repository yet, so only those who explicitly tell you will have it. In case of a URL (which is not unlikely), it is possible to secure an authentication directory by, for example, a name and a password. Because the published repository is actually just the directory inside your WWW tree, you can use the standard procedure for authenticated access to user web pages .

You can then access this repository using one of these commands.

nekde$ git clone
Cloning into 'nejakyprojekt'...
Username for '':

# 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

Public repository update

If we make other changes in our work repository (commity), they can be published by forwarding them to a public repository 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 by HTTP in the way described above is readable for different Git clients, but not for humans. If you want the contents of the repository to be human readable, including versioning information (last change date, list of changes, list of branches, differences between versions, content of a particular file in the current or latest version, etc.), you can use the Gitweb tool. This tool is installed on the Aisa computer and only directory listing is sufficient and redirect to Gitweb. Client Git access will be retained because they never use the directory listing. The repository is then accessible to the same URL both to people and to program clients.

To use Gitweb you just have to go to the directory where you have your public repositories (for example, /home/xpepa/public_html/git from the examples above) to place a file by name .htaccess (be careful, 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 the Git web interface, for example, at .

One repository for multiple users

In centralized versioning systems (CVS, Subversion), the only possible approach is that there is one central repository in which all developers reflect their changes. Git supports different approaches (some of which are described in the manual page gitworkflows(7) ). One of the frequent approaches is that the project has one manager to whom others are offering their changes from their public repositories, he collects them at their discretion into their repository and then publishes their repository as the "official version" of the project.

A centralized approach is nevertheless possible in Git. However, you need to have a shared directory that can be written by all authorized users. Support for this approach on FI machines is planned for the future. The functions and settings of the access rights will be similar to those of the faculty Subversion server .