Table of Contents

Introduction à GIT

Cet énoncé a été conçu pour des groupes qui n'ont pas vraiment commencé à utiliser leur dépôt git. Il est donc possible que certaines actions soient inutiles.

Définition de l'environnement

  1. Adresse de gitlab : https://git-iutinfo.unice.fr/
  2. Pour que l'on sache qui commit : 
     git config --global user.name myusername
  3. Pour que l'on ait son adresse : 
     git config --global user.email myemail
  4. Vous désactivez la vérification SSL 
     git config --global http.sslVerify false
  5. Suivez les instructions du dépôt (si vous ne les voyez plus :2018_2019:s2:td:git:depot

Pour les étudiants qui utilisent leur ordi perso, il est possible que vous ayez besoin de, ouvrir un Git CMD en administrateur, puis taper la commande suivante: 

 git config --system --unset credential.helper
TODO GIT INGONE

Gitignore

  1. Un des étudiants du groupe de TD ajoute le fichier .gitignore dans votre répertoire courant, i.e.
    1. Dézipper le fichier.
    2.  git add .gitignore
    3. git commit -a -m "ajout du .gitignore" 
    4. git push
  2. Tous les étudiants du groupe pour partir de la même version
    1. git pull

Git comme un historique des modifications

Chaque étudiant du groupe a une tâche particulière, chacun choisit sa couleur : Blanc, Bleu, Vert, Jaune, Rouge

  1. Créer un fichier contenant une classe vice en fonction de votre couleur (public class X {})
    • Blanc : Game (Partie)
    • Bleu : Player (Joueur)
    • Vert : Move (Coup)
    • Jaune : IA
    • Rouge : GameManager
    • Evidemment dans ce qui suit X est le nom de class créée par chacun.
  2. Comment interprétez-vous le résultat de la commande suivante 
     git status 
  3. Ajoutez votre fichier X.java comme git vous l'a dit : 
     git add X.java
  4. Réinterprétez le résultat de la commande git status.
  5. Le fichier X.txt est maintenant prêt à être versionné. 
     git commit -m "construction de la class X"

    ou 

     git commit

    1) Quel message avez-vous en retour?

  6. Que donne la commande git status ?
  7. Apportez quelques modifications au fichier X.java.
    • Blanc : ajouter l'attribut Date date avec aussi import java.util.Date; (Game)
    • Bleu : ajouter l'attribut String pseudo (Player)
    • Vert : ajouter l'attribut LocalTime time; (Move) 2)
    • Jaune : ajouter l'attribut int level (IA)
    • Rouge : ajouter la methode export (GameManager) 3)
  8. Essayez de commiter ces modifications. Que se passe-t-il ? En vous aidant de la documentation accessible en tapant git help commit, versionnez ces modifications (avec un message décrivant le changement) 4)
  9. Affichez l’historique des modifications du dépôt. 
     git log
  10. Et pour voir les modifications apportées par le dernier commit 
     git log -p  -1

    et savoir qui fait quoi 

     git log --stat

    ou 

     git log --pretty=format:"%h - %an, %ar : %s"

    etc.

  11. En utilisant git diff , visualisez les modifications effectuées entre le premier commit et le second commit. Par exemple 
     git diff 71cfcd6 0c24491

    Attention l'ordre des commits modifie le résultat (un- devient un +).

  12. Modifiez plusieurs fois votre fichier par exemple en ajoutant des commentaires afin d’en avoir plusieurs versions.
  13. Le dernier commentaire ajouté ne vous plait finalement pas. Il existe deux manières de revenir à une version antérieure : de manière temporaire ou définitive.
  14. Exécuter git log et récupérez le hash (HASH) du commit où vous souhaitez revenir en arrière.
    1. Pour revenir en arrière de manière temporaire, exécutez 
       git checkout HASH
      1. Vérifiez que votre fichier est dans son état antérieur.
      2. Revenez au dernier commit (HEAD) en exécutant 
         git checkout master
    2. Pour revenir en arrière de manière définitive, et donc supprimer tout ce que vous avez fait depuis ce moment : 
       git reset --hard HASH
      1. Dans git log, vérifiez que tout ce que vous aviez effectué depuis ce commit a été effacé.

Synchronisation de votre répertoire en groupe

Hormis la première étape, vous avez expérimenté Git pour gérer localement vos versions. Nous allons maintenant nous intéresser au développement collaboratif de fichier sources.

  1. Visualisez les références distantes 
     git remote
  2. Visualisez les URL associées aux références distantes 
    git remote -v
  3. BLANC envoie son code vers le dépôt distant : 
     git push origin master
    • Cette commande signifie : git push [nom-distant] [nom-de-branche]. Ici, nous souhaitons pousser votre branche master vers le serveur origin (pour rappel, cloner un dépôt définit automatiquement ces noms pour vous)
  4. TOUS
    1. Visualiser l'état du dépôt distant 
       git remote show origin
  5. TOUS
    1. Synchroniser votre dépôt git avec la commande 
       git pull
  6. TOUS
    1. Chacun pousse son code sur le dépôt distant 
       git push origin master

      et si vous avez un souci… pensez à vous mettre à jour.

  7. Chacun :
    • Bleu ajoute à Game l'attribut “Player black”
    • Vert ajoute à Game l'attribut “Move[] moves”
    • Blanc ajoute à GameManager l'attribut “Game[] games”
    • Jaune ajoute à GameManager l'attribut “IA[] ias”
    • Rouge ajoute à GameManager la méthode Game createGame()
    • Tous commitent en local
  8. Là vous faîtes ensemble et dans l'ordre en vous aidant :
    1. Bleu pousse sur le serveur distant. (Pour lui c'est facile ! )
    2. Vert tente de pousser… Remédiez au conflit.
    3. Blanc pousse sur le serveur distant. Cool !
    4. Jaune pousse sur le serveur distant ….
    5. Rouge pousse sur le serveur distant…

Branches de développement

Cette partie n'est pas insdispensable à la gestion de votre projet tutoré de S2, à moins que votre groupe en ai décidé autrement ;-)

Nous allons travailler avec une branche chacun.

Les caractéristiques n'ayant pas encore été validées par votre client, vous souhaitez travailler sur celles-ci sans casser la version existante. La notion de branche permet de passer instantanément d’une version « stable » (branche « master » créée par défaut) du projet à une « version en cours de développement » (n’importe quelle autre branche que « master »

  1. Jusqu'ici vous avez travaillé sur une seule branche « master » : c’est la branche principale, celle qui en général contient le « vrai » code source de votre projet. Pour voir toutes vos branches 
    git branch
  2. Chacun :
    1. Créez une branche de votre couleur <C> dans votre dépôt Git. 
       git branch C
    2. Vérifiez que vous êtes bien dans la branche Master par la commande 
      git branch
    3. Basculez dans la branche de C
       git checkout C
    4. Vérifiez dans quelle branche vous êtes
    5. Ajoutez à la classe que vous avez créée initialement (Blanc→ Game, ect) ce que vous voulez puis commitez
    6. Fermez votre fichier.
    7. Observez l’historique des modifications du dépôt, que remarquez-vous ?
    8. Revenez à la branche « master » et observez l’historique des modifications, que remarquez-vous ?
    9. Vous souhaitez ajouter vos modifications à la branche master. Fusionnez (« merge ») la branche « C » à la branche « master ». 
      git merge C

      Vérifiez que la fusion s'est bien passée.

    10. Si vous avez un conflit, résolvez le conflit, pour cela dans le fichier en cause, identifiez les codes entre les balises de conflit (««< et »»>).
      1. Commitez le changement (et donc la fusion) en tapant « git commit –a »

Références

http://marklodato.github.io/visual-git-guide/index-en.html

https://rogerdudler.github.io/git-guide/index.fr.html

1)
Un éditeur s'ouvre qui dépend de votre configuration. Si c'est VIM pour sortir “:q”. Si l'éditeur ne vous convient pas, vous pouvez le configurer par exemple 
 git config --global core.editor emacs
2) 
import java.time.LocalTime;
public class Move {
  private LocalTime time;
}
3) 
import java.util.Date;
public class Game {
	private Date date;
}
4)
Au lieu d'un git add suivi d'un git commit vous pouvez préférer 
 git commit -a -m "ajout de l'attribut Y ..."