Tutorial: create a git repository

In this tutorial, you will follow alice through the steps she takes to create (and optionally share) a git repository.

Conventions:

alice: owns the repository, substitute your username;
the-dam.org:: name of git enabled server, subtitute your server's domain name or IP;
users:: name of the group alice wants to share code with, substitute the name of the group you want to share code with;
/home/alice/src/wonderland:: alice's private repository path, substitute your project name and path;
/srv/git/alice/wonderland:: alice's (semi-)public repository path, substitute your project name and path;

1. Public, semi-public, or private ?

alice first needs to decide with whom she wants to share her code:

Write access (push)	Read access (clone, fetch, pull)	Name
alice only	alice only	Private
alice only	some users on the-dam.org	Semi-public, read-only
some users on the-dam.org	some users on the-dam.org	Semi-public, read-write
alice only	the whole world	Public, read-only
some users on the-dam.org	the whole world	Public, read-write
the whole world	the whole world	A BAD IDEA

The sections below describe how to achieve each of those mutually exclusive options.

Note that private repositories are created in alice's home directory (/home/alice/) whereas (semi-)public repositories are created in a shared area (/srv/git/).

While one may share a part of one's home directory by carefully managing permissions, mistakes are likely. Therefore we strongly advise users to do as alice did: keep anything private in their homes, and share stuff in the common areas.

Note also that in the following, alice shares her code with members of group users. users contains all human users on the-dam.org. If she wished to restrict or widen access, she would substitute another group in lieu of users, asking root to create it if it does not already exists.

Finally, note that letting anonymous users write data to the server means trouble, as malware or worse will inevitably get written. As such, root will reconfigure any o+w git repository that exists.

1.1. Creating a private repository

alice navigates to /home/alice/src and runs:

git init --bare wonderland

She then checks that her new repo is indeed private, using the permaudit tool:

permaudit /home/alice/src/wonderland ; echo $?

The command should successfully exit, as shown above.

1.2. Creating a semi-public, read-only repository

Alice navigates to /srv/git/ and runs

git init --bare wonderland

she then chowns and chmods it to allow read access to group users:

chown -R alice:users wonderland
chmod -R u+rwx,g+rx,g-w,o-rwx wonderland

and checks her work with permaudit:

permaudit /srv/git/wonderland

user	nvnsdrdy	r	/srv/git/wonderland/
user	nvnsdrdy	r	/srv/git/wonderland/info
user	nvnsdrdy	r	/srv/git/wonderland/info/exclude
user	nvnsdrdy	r	/srv/git/wonderland/hooks
...

group	users	r	/srv/git/wonderland/description
group	users	r	/srv/git/wonderland/objects
group	users	r	/srv/git/wonderland/objects/info
group	users	r	/srv/git/wonderland/objects/pack

She should see

all human users as well as the users group having read (r) rights to all the files.
Nobody else should have any rights.
In particular, the git group should not be listed in the output (alice can make sure of that by running permaudit /srv/git/wonderland | grep git).
She should see no lines with write (w) rights.

1.3. Creating a semi-public, read-write repository

Alice navigates to /srv/git/ and runs

git init --bare wonderland

she then chowns and chmods it to allow read-write access to group users:

chown -R alice:users wonderland
chmod -R u+rwx,g+rwx,o-rwx wonderland

and checks her work with permaudit:

permaudit /srv/git/wonderland

...
user	nvnsdrdy	r	/srv/git/wonderland/objects/info
user	nvnsdrdy	r	/srv/git/wonderland/objects/pack
user	nvnsdrdy	w	/srv/git/wonderland/
user	nvnsdrdy	w	/srv/git/wonderland/info
user	nvnsdrdy	w	/srv/git/wonderland/info/exclude
...
group	users	r	/srv/git/wonderland/description
group	users	r	/srv/git/wonderland/objects
group	users	r	/srv/git/wonderland/objects/info
group	users	r	/srv/git/wonderland/objects/pack
group	users	w	/srv/git/wonderland/
group	users	w	/srv/git/wonderland/info
group	users	w	/srv/git/wonderland/info/exclude
...

She should see

all human users, as well as the users group, having read and write (r, w) rights to all the files.
Nobody else should have any rights.
In particular, the git group should not be listed in the output (alice can make sure of that by running permaudit /srv/git/wonderland | grep git).

1.4. Creating a public read-only repository

Alice navigates to /srv/git/ and runs

git init --bare wonderland

she then chowns and chmods it to allow read access to the whole world:

chown -R alice:users wonderland
chmod -R u+rwx,g+rx,g-w,o+rx,o-w wonderland

and checks her work with permaudit:

permaudit /srv/git/wonderland

user	nvnsdrdy	r	/srv/git/wonderland/
user	nvnsdrdy	r	/srv/git/wonderland/info
user	nvnsdrdy	r	/srv/git/wonderland/info/exclude
user	nvnsdrdy	r	/srv/git/wonderland/hooks
...
user	git	r	/srv/git/wonderland/
user	git	r	/srv/git/wonderland/info
...
group	users	r	/srv/git/wonderland/HEAD
group	users	r	/srv/git/wonderland/description
group	users	r	/srv/git/wonderland/objects
group	users	r	/srv/git/wonderland/objects/info
group	users	r	/srv/git/wonderland/objects/pack

She should see

all human users, the git user, as well as the users group having read (r) rights to all the files.
Nobody else should have any rights.
She should see no lines with write (w) rights.

1.5. Creating a public read-write repository

Alice navigates to /srv/git/ and runs

git init --bare wonderland

she then chowns and chmods it to allow read-write access to group users, and read access to the whole world:

chown -R alice:users wonderland
chmod -R u+rwx,g+rwx,o+rx,o-w wonderland

and checks her work with permaudit:

permaudit /srv/git/wonderland

...
user	nvnsdrdy	r	/srv/git/wonderland/objects/info
user	nvnsdrdy	r	/srv/git/wonderland/objects/pack
user	nvnsdrdy	w	/srv/git/wonderland/
user	nvnsdrdy	w	/srv/git/wonderland/info
user	nvnsdrdy	w	/srv/git/wonderland/info/exclude
...
user	git	r	/srv/git/wonderland/
user	git	r	/srv/git/wonderland/info
...
group	users	r	/srv/git/wonderland/description
group	users	r	/srv/git/wonderland/objects
group	users	r	/srv/git/wonderland/objects/info
group	users	r	/srv/git/wonderland/objects/pack
group	users	w	/srv/git/wonderland/
group	users	w	/srv/git/wonderland/info
group	users	w	/srv/git/wonderland/info/exclude
...

She should see

all human users, as well as the users group, having read and write (r, w) rights to all the files,
the git user having read rights *only*¹1: git being an anonymous ssh user, any git-writable piece of the filesystem will get root's attention, and explanations will have to be given. .
Nobody else should have any rights.

2. Push some code

Time to push some code. Either alice:

has an existing repo: in which case she will add the newly created repo as a remote ;
or she has yet to write any code: in which case she will simply clone the newly created repo.

2.1. Add the new repo as a remote to an existing repo

On her local computer, alice navigates to her existing repo:

cd /home/alice/dev/wonderland

and adds the newly created repo as a remote:

private repo: git remote add thedam alice@the-dam.org:src/wonderland
(semi-)public repo: git remote add thedam alice@the-dam.org:/srv/git/wonderland

She then can push the existing branches to the new repo with

git push thedam '*:*'

2.2. Clone the existing repo

On her local computer, alice navigates to where she wants the repo to be, and run:

private repo: git clone alice@the-dam.org:src/wonderland
(semi-)public repo: git clone alice@the-dam.org:/srv/git/wonderland

3. Publish the code

In the case of a (semi-)public repository, alice should tell her buddies what to run to get a copy of the code.

for bob, another user on the-dam.org: git clone bob@the-dam.org:/srv/wonderland
for anonymous users: git clone git@the-dam.org:wonderland

Congratulations, alice can now share her code with the world, or whoever she sees fit.

4. Advertisement

Did you like what you read ?

You can help me write more by:

renting a guix VPS from me,
hiring me for a consulting gig: software development, cybersecurity audit and training, cryptocurrency forensics, etc. see my personal page,
letting me teach you Python, or spreading the word about this course,
or buying a very, very secure laptop from me.