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 Git versioning system . You can read more about the Git system itself in official tutorial , or in a book Pro Git , respectively. in her Czech translation . The following document is not a guide to Git, only for its use in the FI MU network environment.

GitLab FI

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

Publish your repository

Git is distributed versioning system , which means that there can be multiple repositories of one project (such as multiple developers) at the same time, and you can send or receive individual changes ( commits ) between those 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 sufficient to publish the repository as a common directory by means of the HTTP protocol (on FI computers, therefore, have it under the directory public_html in your home directory - see document about 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'...
done.
aisa$ 
cd 
nejakyprojekt.git
aisa$ 
cp hooks/post-update.sample hooks/post-update
aisa$ 
./hooks/post-update

Note: so-called repository bare files are always created in the ending directory .git .

Typographic Note: In the examples, italics indicate those parts that are user-dependent and which project name and other properties it chooses to use. When applying them, change these parts according to your environment.

Keep in mind that these files must be readable by apachefi users or others for proper operation, see user HTML pages .

At this point, a public repository clone is already available, and it can be reported to other users that it is available under URL https://www.fi.muni.cz/~ xpepa/git/nejakyprojekt.git . For example, another user can download your changes to their repository by command git fetch , eventually 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.

Access Restrictions

We've created a public clone of your repository as described above. There is no link to the repository at this time, so only those you explicitly share will have access to it. However, in case of a guessing URL (which is not unlikely), it is possible to secure the directory by authentication, for example with a username and password. Since the published repository is actually just a directory inside your WWW tree, the standard procedure for authenticated access to user WWW 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://
jmeno@www.fi.muni.cz/~
xpepa/nejakyprojekt.git
Password:
...

Updating the public repository

If we make other changes (commits) in our working repository, they can be published by forwarding them to the 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: a web interface to the Git repository

The HTTP repository described above is readable by various Git clients, but not by humans. If you want the repository content to be human readable, including version information (last modified date, list of changes, branch list, version differences, content of a particular file in the current or last version, etc.), you can use the Gitweb tool. This tool is installed on the Aisa computer and you only need to list directories https://www.fi.muni.cz/~ xpepa/git/ and https://www.fi.muni.cz/~ xpepa/git/nejakyprojekt.git/ redirect to Gitweb. Git client access will be retained because they never use 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 the Git web interface 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 in which all developers project their changes. Git supports different approaches (some of which are described in the manual page) gitworkflows(7) ). One of the common approaches is that a project has one manager, to whom others offer their changes from their public repositories; he collects them at his own discretion 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, it is necessary 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 that of the faculty Subversion server .