Git gestion de versions décentralisé git



Introduction

Les systèmes de gestion de versions (VCS pour Version Control Systems) sont principalement de deux types :
centralisés (comme Subversion) ou décentralisés (comme Git).

Dans le cas centralisé, tous les changements apportés sont soumis (commit) à un serveur central, qui permet
ensuite aux autres développeurs d'accéder à ces changements. L'avantage est la simplicité de configuration et
d'utilisation ; le défaut principal est la centralisation : si le serveur n'est plus accessible, le travail collaboratif
n'est plus possible.

Dans le cas décentralisé, la prise en compte des changements se fait localement. Les autres développeurs
n'auront accès à ces changements que quand les dépôts seront synchronisés. L'avantage est de pouvoir
travailler de manière collaborative localement ; l'inconvénient est la complexité des opérations par la présence
de deux dépôts : le dépôt local (appelé aussi « dépôt privé ») et le dépôt distant, ou « remote » (appelé aussi «
dépôt public »).

Un système décentralisé comme Git a été choisi par l'école, car cela permet :

· aux étudiants, de travailler en mode collaboratif avec leur dépôt local, tout en ayant une « sauvegarde
» de leurs travaux sur le dépôt distant ;
· aux enseignants de gérer les dépôts distant de chacun des projets de leurs élèves ou binômes ; ils
peuvent avoir accès à des statistiques, voire intervenir directement dans les projets, si nécessaire ;
· des restitutions faciles, car elles consistent simplement à placer un tag (voir plus loin) sur le dépôt
distant.

Générer sa clef

SSH keys

An SSH key allows you to establish a secure connection between your computer and GitLab. Before generating an SSH key in your shell, check if your system already has one by running the following command:

Windows Command Line:

type %userprofile%\.ssh\id_rsa.pub

GNU/Linux/Mac/PowerShell:

cat ~/.ssh/id_rsa.pub

If you see a long string starting with ssh-rsa, you can skip the ssh-keygen step.

To generate a new SSH key, use the following command:

ssh-keygen -t rsa -C "admin@example.com"

This command will prompt you for a location and filename to store the key pair and for a password. When prompted for the location and filename, just press enter to use the default. If you use a different name, the key will not be used automatically.

Note: It is a best practice to use a password for an SSH key, but it is not required and you can skip creating a password by pressing enter.

If you want to change the password of your key later, you can use the following command: ssh-keygen -p <keyname>

Use the command below to show your public key:

Windows Command Line:

type %userprofile%\.ssh\id_rsa.pub

GNU/Linux/Mac/PowerShell:

cat ~/.ssh/id_rsa.pub

Copy-paste the key to the 'My SSH Keys' section under the 'SSH' tab in your user profile. Please copy the complete key starting with ssh-rsa and ending with your username and host.

To copy your public key to the clipboard, use the code below. Depending on your OS you'll need to use a different command:

Windows Command Line:

type %userprofile%\.ssh\id_rsa.pub | clip

Windows PowerShell:

cat ~/.ssh/id_rsa.pub | clip

Mac:

pbcopy < ~/.ssh/id_rsa.pub

GNU/Linux (requires xclip):

xclip -sel clip < ~/.ssh/id_rsa.pub




Le Workflow d'un projet


Avant de commencer le développement d'un projet, il est fortement conseillé de définir son workflow (ainsi
que des règles d'utilisation). Les étapes usuelles pour un développeur dans le cadre des projets du cycle
ISMIN sont les suivantes :

1. Avant le démarrage d'un projet :
     1. Installer et initialiser Git, et installer les outils nécessaires au projet
     2. Obtenir de l'enseignant le dépôt distant du compte projet
     3. Récupérer ce dépôt localement (dépôt local)
2. Pendant la réalisation du projet :
     1. Récupérer les changements de l'équipe de manière distante
     2. Modifier le projet et appliquer les changements localement
     3. Vérifier (et tester) les changements locaux
     4. Partager les changements avec l'équipe de manière distante
3. À la fin du projet :
     1. Consolider la restitution du projet par un étiquetage (tag)
     2. À la date fixée, l'enseignant verrouille les dépôts distants de son compte projet


Voici des exemple de règles que vous avez à définir : nature du dépôt distant, périodicité des opérations, etc.
Vous constaterez qu'avec des règles précises, il est possible d'utiliser Git de manière centralisée (cela fait
partie également des avantages des systèmes décentralisés). Dans ce cas, le dépôt commun est appelé « dépôt
partagé ». C'est ce principe de fonctionnement qui est décrit dans ces pages.

1) Avant le démarrage d'un projet

Avant le démarrage de tout projet de développement informatique, votre espace de travail doit être
correctement initialisé. Comme la plupart de ces projets sont proposés sous Linux (programmation C, C++,
système d'exploitation, etc.), les informations pour configurer l'espace de travail sont données dans un
environnement « ligne de commandes » (shell de type bash) sous Linux. Il est cependant possible d'utiliser
d'autres environnements ; cela sera éventuellement traité dans une prochaine version de ce document.

Initialisation de Git

Après l'installation de Git sur votre système (non traité dans ces pages), vous avez quelques commandes de
configuration à effectuer.

Le fichier principal de configuration de Git se trouve dans le répertoire de connexion : ~/.gitconfig. Il est
possible de modifier le fichier de configuration spécifique à un dépôt, .git/config, en omettant l'option
--global dans les commandes ci-dessous, et en étant positionné dans le répertoire du projet. Ces fichiers de
configuration sont des fichiers texte qu'il est possible de modifier directement ; il est cependant conseillé
d'utiliser la commande git config pour les configurer.

git config --global user.name "Votre nom"
git config --global user.email "prenom.nom@emse.fr"







Initialisation de ssh

La connexion aux dépôts Git nécessitent l'installation d'un client ssh sur votre machine et sa configuration.
Pour vous authentifier sur le serveur, votre enseignant a besoin de votre clef publique ssh.

Il se peut que cette clef ait déjà été générée sur votre compte. Pour le vérifier, tapez la commande :

ls $HOME/.ssh/*.pub


Si le fichier id_rsa.pub n'existe pas, alors vous devez créer un couple de clés privée et publique avec l'outil
ssh-keygen :

ssh_keygen -t rsa


Création du dépôt partagé sur le serveur Git de l'école

Ce n'est pas vous, mais la DSI qui va créer le dépôt partagé.

[Note] Les dépôts partagés du serveur Git de l'école sont des dépôts bruts (bare repositories), c'est à dire des
dépôts qui ne contiennent pas les fichiers de travail mais uniquement les données de gestion de Git (ces
dépôts ne pourront donc pas être utilisés directement, comme dépôt local). Par convention, le nom des dépôts
bruts se termine par .git. Les sites comme GITHUB ne proposent que des dépôts de type bare.

Pour créer le dépôt et vous en donner l'accès, l'enseignant a besoin de la clef publique SSH du compte que
vous allez utiliser pour accéder au dépôt (point précédent). Pour cela, copiez le fichier id_rsa.pub sur votre
bureau (NE COMMUNIQUEZ JAMAIS VOTRE CLÉ PRIVÉE) et renommez-le avec votre nom :

cp $HOME/.ssh/id_rsa.pub $HOME/votre_nom.pub


Envoyez ce fichier votre_nom.pub par mail à la DSI pour creer le dépôt partagé,
en lui donnant son nom (celui du projet par exemple).




2) Pendant la réalisation du projet

Réaliser le projet localement

Ce qui a changé

Il est fortement conseillé de consulter le statut de votre projet avec git status avant d'exécuter des actions.
Cette commande a aussi l'intérêt d'afficher les commandes Git à exécuter pour placer le dépôt dans un état
« rien à faire (Nothing to commit (working directory clean) ».

Pour annuler les modifications de votre espace de travail, c'est à dire retrouver les éléments dans l'état
synchronisé avec le dépôt, il faut utiliser la commande git checkout -- . (cette commande se termine par '.'
indiquant le répertoire courant ; vous pouvez préciser l'(es) élément(s) spécifiquement).

La zone de transit (staging area)

Git utilise un processus à deux étapes pour placer les changements dans le dépôt local. La première étape
consiste à placer les changements de l'espace de travail vers la zone de transit (staging area), avec la
commande git add. Les changements incluent tout ce qui a été ajouté, modifié ou supprimé.

Vous pouvez spécifier un fichier, un répertoire ou tout simplement l'option -A pour ajouter tout ce qui a été
ajouté ou changé, ou l'option -u pour ajouter uniquement ce qui a été changé dans les éléments déjà présents
dans le dépôt.

Cette étape ne modifie pas le dépôt local. Pour en annuler les effets, il faut taper la commande
git reset HEAD . (cette commande se termine par '.' indiquant le répertoire courant ; vous pouvez préciser
l'(es) élément(s) spécifiquement). Le nom HEAD désigne la dernière mise à jour du dépôt (commit).

Mise à jour du dépôt local

La seconde étape consiste à appliquer les changements dans le dépôt local, à partir de la zone de transit, avec
la commande git commit. Chaque commit est repéré par un identifiant interne, qui sera associé à un message
indiqué avec l'option -m ; si cette option est omise, un éditeur de texte est lancé pour y saisir le message. Pour
appliquer tous les changements en une seule commande, il faut utiliser l'option -a.

Partager les changements avec l'équipe

Savoir quel est le dépôt partagé

Lors de votre premier accès, votre dépôt local a mémorisé où se trouve votre dépôt partagé. Pour le vérifier,
utilisez la commande suivante qui devrait afficher le nom origin par défaut :

git remote show


Pour avoir plus d'information sur ce dépôt, faites :

git remote show origin





Récupérer les changements

Pour récupérer les changements placés par d'autres développeurs sur le dépôt partagé (par défaut, c'est le
dépôt origin qui est interrogé), faites :

git pull


Déposer ses changements

Pour déposer ses changements (présents dans le dépôt local, donc après un ou plusieurs git commit) dans le
dépôt partagé, faites :

git push origin master


En plus du nom de dépôt {origin}, il faut indiquer la branche que l'on souhaite synchroniser, ici, c'est la
branche par défaut dont le nom est master.

3) À la fin du projet


Étiquetage du projet

Vous devez étiqueter (tag) votre projet pour la distribution, avant la date prévue de la restitution. Pour cela,
dans votre répertoire racine de votre projet, faites :

git tag -a xxxversionxxx -m "Restitution xxx"


La mention -a demande d'annoter l'étiquette (meilleure garantie, en particulier inscription de la date).
xxxversionxxx est le nom de l'étiquette et un message peut être associé à cette étiquette.

Ensuite, vous devez déposer l'étiquette sur le serveur distant :

git push origin master xxxversionxxx


Vérification de l'étiquetage

Pour vérifier l'étiquetage, faites :

git tag
git show xxxversionxxx | head -10


Un grand merci à Philippe Lalevée pour la doc et son aide .


Zircon - This is a contributing Drupal Theme
Design by WeebPal.