Practical:GIT

De wiki-prog
Révision de 13 septembre 2017 à 13:58 par Slashvar (discuter | contributions) (Cloning a repository)

(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)
Aller à : navigation, rechercher

This page present howto set-up your GIT account at EPITA for S3/S4 practical programming sessions.

GIT set-up

GIT provides mechanism to keep track of versions of files and synchronization between copies of the same source tree. Basic operations you need to know are how to submit (commit) your changes, how to push your changes to a server and how to pull new version from a server.

Setting the environment

There's a file containing global configuration for GIT in your home directory. The file ~/.gitconfig will hold basic settings like your name, email address and global options. Here is an example of this configuration file:

[user]
	name = John Smith
	email = john.smith@epita.fr
[color]
	ui = true
[push]
	default = simple

SSH Key

One way to authenticate on a git server is to use ssh, most of the time using a public/private keys pair. If you haven't generate such a keys pair, here is a simple way to do it:

> ssh-keygen -t rsa -b 4096 -f ~/.ssh/my_git_key_file
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/login/.ssh/my_git_key_file.
Your public key has been saved in /home/login/.ssh/my_git_key_file.pub.
The key fingerprint is:
[ ... snip ... ]

Be sure that the directory ~/.ssh has been created before.

The public key that you will provides for the CRI intranet (providing authentification for git) will be my_git_key_file.pub.

You can add login information for the CRI's GIT services inside the file ~/.ssh/config:

Host git.cri.epita.net
User git
IdentityFile ~/.ssh/my_git_key_file

You can now upload the key to the CRI's intranet [1] ("My SSH Keys".)

Cloning a repository

Now, you can clone praticals' repository to start-up working, go to a working directory of your own, and then use git clone:

> git clone git@git.cri.epita.net:p/2021-s3-tuto/login

You have two repositories:

  • one for all the practical session (git@git.cri.epita.net:p/2021-s3-tuto/login)
  • one for the project (git@git.cri.epita.net:p/2021-s3-project/login) where login is the login of the group leader

Remarque: any members of the group is able to clone and/or update the project repository, you don't need to be the project leader.

Now we can do simple manipulations:

> cd login
> mkdir 20170918_home_work
> cd 20170918_home_work
> echo '* login' > AUTHORS
> git add AUTHORS
> git commit -m "Initial commit"
> git push -u origin master

OK, first lines are obvious. In the fourth line, we add AUTHORS to the list of tracked files, then in the fourth line we commit the change with a simple message and finally we push the change to the server (specifying that we want the distant server called origin to be the default for push/pull.)

Basic Commands

Now you can try to edit in an other place the repository and synchronize your first version.

For example, if you have already cloned the repository and made pushed some modification from another copy, you can update the local version:

> cd login
> git pull --rebase

You can check the status of tracked files and unadded files using git status and then add modified or newly created files:

> git status
status output
> git add my_modified_file.c my_new_file.c
> git commit -m "some message explaining what I've done."
> git push

If you need help on git, you can use inline docs:

> git help
...
> git help add
...
> man 7 giteveryday
...
> man 7 gitcore-tutorial
...

Or dig a little bit in git documentations here:

Ignore binary files

You should avoid pushing binary files in your repository, in particular you must not add .o files.

One of the simplest way to avoid adding files you don't want is to set-up a file called .gitignore. This file can live in the root of your repo or in any sub-directories (in this case, its effect is limited to the corresponding sub-dirs.) The format of the file is pretty simple: each line is a pattern for reject files (using classical regexp), here is a simple example:

*.o
*~
*.tar
*.tar.gz
*.tar.bz2
*.tgz

The first pattern *.o reject all object code produced by the compiler, the second one reject emacs' backup files, and the remaining lines reject several form of tar archives (compressed or not.)

You can set-up an ignore file for all your practical sessions:

> cd login
> cat .gitignore
*.o
*~
*.tar
*.tar.gz
*.tar.bz2
*.tgz
> git add .gitignore
> git commit -m "Adding a gitignore file."
> git push