Git, travailler en projet

table des matières

Travailler seul sur plusieurs copies du projet
Travailler en équipe sur un projet
1. Synchroniser le travail en équipe : gérer les fusions
2. Exemple d’une fusion de deux collaborateurs
  1. Étape 1 - Récupérer l’ensemble du travail à fusionner sur un poste.
  2. Fusion des branches
Gérer les conflits entre fichiers

On vous demandera de continuer les projets initiés dans la section chez vous ou inversement.

Vous allez ensuite travailler à plusieurs sur le même projet.

Pour ces deux situations, il faudra que vous maîtrisiez encore un peu plus l’utilisation de git !

principe Git

Travailler seul sur plusieurs copies du projet

Cas d’utilisation :

Vous travaillez sur un projet pendant les heures de cours et vous désirez continuer à travailler sur ce même projet sur votre ordinateur personnel. Une fois votre travail terminé, vous voulez sauvegarder celui-ci et le retrouver lors du prochain TP en classe.

Principe

Vous allez utiliser la version sur le serveur gitlab comme version de référence. le serveur doit contenir la dernière version de votre travail !

Étape 1 - travail en classe

Vous créez comme d’habitude un dépôt git sur votre PC et sur gitlab et vous synchronisez ces deux dépôts (local et distant)

Pendant la séance

git commit -am "Feature : message de commit"

A la fin de la séance

git push origin master

Étape 2 : travail à la maison

Vous clonez sur votre PC le dépôt sauvegardé sur gitlab

git clone url_de_votre_projet

Vous travaillez

git commit -a -m "message de commit"

A la fin de la séance

git push origin master

A ce moment, gitlab contient donc la version à jour de votre travail

Étape 3 : Nouvelle séance de TP en classe

Vous récupérez la dernière version du serveur

git pull

Info : Si vous n’avez pas initialisé le premier git push avec l’option -u (–set-upstream), vous devez préciser les branches locales et distantes lors du git pull

git pull origin master

Vous travaillez

git commit -a -m "message de commit"

A la fin de la séance

git push origin master

A ce moment, gitlab contient donc la version à jour de votre travail

Étape(s) suivante(s)

Pour continuer le travail chez vous, il suffit de récupérer la dernière version du serveur comme indiqué lors de l’étape 3.

Conclusion

Attention à bien suivre ces étapes dans l’ordre (git pull au début d’une séance, git push à la fin). Sinon, vous allez avoir des conflits de versions à gérer !

Cas particuliers

La commande git clone ne récupère par défaut que la branche master

Si vous voulez récupérer une autre branche, il faut faire un git checkout de la branche distante

Récupérer le nom des branches du serveur
```
git branch -a
```

Récupérer la branche distante en local

git checkout -b nouvelle_branche_locale nom_local_du_dépôt_distant/nouvelle_branche

Travailler en équipe sur un projet

Le travail en équipe suit le même principe de workflow que celui déclaré précédemment.

Attention
La seule spécificité supplémentaire est de travailler chacune des fonctionnalités (feature) sur une branche séparée, comme indiqué sur le diagramme ci-dessous.

Git- Workflow projet

Le premier réflexe à avoir lors du début d’une séance est de récupérer la dernière version sur le serveur via git pull

Seulement, pour ne pas avoir de problèmes, il faut que :

le code poussé par tous les membres de l’équipe soit fonctionnel
Éviter au maximum de travailler sur les mêmes fichiers
Dans la mesure du possible, développer son code dans une branche spécifique et ne fusionner avec master QUE lorsque la fonctionnalité est développée.

Lorsque vous travaillez en équipe, vous devez gérer les fusions.

Synchroniser le travail en équipe : gérer les fusions

Git fusionne automatiquement quand il le peut les différentes versions des fichiers et répertoires du projet.

Nous allons partir du principe que vous voulez synchroniser le travail entre plusieurs personnes sans rien perdre !

Attention : L’utilisation d’un logiciel de versionning pour sauvegarder son travail est essentielle, mais il faut être rigoureux dans la gestion de celui-ci !

DANGER
Pour éviter les problèmes :

Éviter au maximum de travailler sur un même fichier !
Maîtriser les fichiers à commiter (git status)
Ne pas commiter de fichier de configuration propre à votre poste !
Commiter régulièrement
Récupérer régulièrement le travail de votre équipe

Exemple d’une fusion de deux collaborateurs

Étape 1 - Récupérer l’ensemble du travail à fusionner sur un poste.

Nous allons considérer qu’il y a 3 branches sur le projet (master, maBrancheEtudiant1, maBrancheEtudiant2). L’étudiant2 va s’occuper de la fusion des 3 branches sur la branche de référence, master.

Étudiant_1 : Commit du travail

git commit -am "mon super travail fini"

Étudiant_1 :Pousse le travail sur le serveur

git push origin maBrancheEtudiant1

Étudiant_2 : Récupère la dernière version de son binôme
Se déplacer sur la branche master

git checkout master

Cas où la branche n’a jamais été récupérée

  git fetch
  git checkout -b maBrancheEtudiant1 origin/maBrancheEtudiant1

Cas où la branche doit être mise à jour sur le poste de l’étudiant 2
```
  git pull origin maBrancheEtudiant1
```

Si tout c’est bien déroulé, l’étudiant_2 a son travail ainsi que celui de l’étudiant_1.

Fusion des branches

Les branches sont fusionnées une à une. D’abord sa branche (maBrancheEtudiant2), puis la branche de son binôme (maBrancheEtudiant1)

Remarque : Avant la fusion, identifier les éventuels fichiers qui seront en conflit. Ce n’est pas compliqué, il s’agit de ceux que vous avez tous les deux modifiés (CMakelist.txt, main.cpp, …)

Depuis la branche master, fusion du travail de l’étudiant 2

git merge maBrancheEtudiant2

Depuis la branche master, fusion du travail de l’étudiant 1

git merge maBrancheEtudiant1

Remarque : Si il y a un (ou plusieurs) conflit(s), continuez la lecture

Gérer les conflits entre fichiers

Lorsque vous travaillez en équipe sur un même projet et qu’un fichier à été modifié (main.cpp par exemple) par plusieurs personnes, il faut souvent aider Git à déterminer quelle partie du code vous voulez conserver, c’est la gestion des conflits.

Edition manuelle des fichiers en conflits

Si git n’arrive pas résoudre les conflits automatiquement, vous devez éditer les fichiers dans votre IDE et choisissez les versions à conserver (Procédure manuelle)

Votre fichier en conflit contient des lignes étranges comme celles-ci

<<<<<<< HEAD
=======
>>>>>>> new_branch_to_merge_later

Considérez ces lignes comme des « séparateurs de conflit ».
- La ligne ======= est le « centre » du conflit.
- Tout le contenu entre le centre et la ligne <<<<<<< HEAD pointe la réf HEAD.
- Tout le contenu entre le centre et >>>>>>> new_branch_to_merge_later est présent dans notre branche de merge.

Supprimer manuellement les éléments indésirables dans le fichier en conflit.
Ensuite, il faut ajouter le fichier en conflit à git pour indiquer que le conflit est réglé
Ajouter le fichier qui était en conflit
```
git add le_fichier_en_conflit_resolu
```

Pousser votre travail sur le serveur.

git commit -am "fusion des branches ok"
git push origin master

Gestion de conflit et messages d’erreurs

Normalement, vous ne devriez pas avoir à taper les commandes ci-dessous…normalement !

GIT PULL = conflit

GIT PULL = conflit : Veuillez valider ou remiser vos modifications avant la fusion.

Tapez les commandes ci-dessous

git reset --hard HEAD
git reset --hard HEAD && git checkout master && git pull

Valider ou remiser vos modifications avant la fusion

Vous avez fait des modifications sur votre branche, mais finalement, vous ne souhaitez pas les sauvegarder tout de suite, il est possible de les mettre de coté avec git statch.

Mettre de coté les modifications git statch

Soyez-relax-faites-vous-un-petit-git-stash

Modifier des anciens commit

La procédure ci-dessous modifie un ancien commit et propage les modifications dans les commit ultérieurs.

Attention : Cela ne fonctionne QUE sur un dépôt local non publié (c’est à dire avant git push)

Afficher l’historique des commits

git log --oneline --decorate --graph --all

Revenir à un ancien commit (ici le hash b8603aca)

git rebase --interactive b8603aca^

Dans l’éditeur, modifier la ligne pick par edit pour le commit à modifier
Sauvegarder et quitter l’éditeur
Éditer le fichier à modifier et effectuer la/les modification(s)
Modifier le commit

git commit -a --amend --no-edit

Restaurer les commits suivants

git rebase --continue

Pour aller plus loin

merge-conflicts