Séance 7 (nouvelle version) — TP : Continuation du développement
(Re-)Positionnement dans le dépôt Git de GitLab
Voici la procédure que nous proposons (dans tous les cas « par défaut »). « En cas de panique », veuillez vous reporter à celle qui suit celle-ci.
-
Procédure
« repositionnement »
-
on repart d'un dépôt mis à jour et on continue dans la
branche develop
-
cd ~/CSC4102
cd csc4102-projet
git fetch # prendre connaissance des nouveautés
git branch # quelle est la branche courante ?
si pas déjà dans la branche develop alors « git checkout develop » # se positionner dans la branche
git pull origin develop # accepter les modifications de la branche
si conflit et besoin d'une fusion, « git mergetool --tool=meld » puis « git commit »
-
cd ~/CSC4102
-
on repart d'un dépôt mis à jour et on continue dans la
branche develop
« En cas de panique », veuillez suivre la procédure qui suit :
-
Procédure « nouveau
clonage »
-
on clone à nouveau le dépôt et on continue dans la
branche develop :
-
cd ~/CSC4102
mv csc4102-projet csc4102-projet_old # garder une copie au cas où du contenu n'ait pas été poussé
git clone URL_DE_VOTRE_PROJET
cd csc4102-projet
git checkout develop # positionnement dans la branche develop
-
cd ~/CSC4102
-
on clone à nouveau le dépôt et on continue dans la
branche develop :
Continuation du développement de l'application
Vous devez compléter votre logiciel pour qu'il possède toutes les fonctionnalités présentées dans le cahier des charges (cf. la section « Complétude du logiciel » du cahier des charges). Hormis la notification avec le patron de conception Publier/Souscrire, tout le logiciel peut être développé : pour la partie notification, si vous n'avez pas inséré le patron de conception Publier/Souscrire, utilisez un affichage à la console pour indiquer qu'un acteur est notifié.
Nous conseillons de commencer l'étude de ces éléments une fois les
cas d'utilisation
|
Comme vous avez gagné en autonomie, nous vous laissons organiser votre travail en présentiel et en hors présentiel tout au long des dernières séances. Bien sûr, n'hésitez pas à discuter de vos tâches et de votre solution avec vos responsables de groupe. Lors des travaux à venir, des modifications peuvent impacter la modélisation existante : diagramme de cas d'utilisation, pré-/post-conditions, tables de décision des tests de validation, diagramme de classes, diagrammes de séquence, etc. Pour les nouveaux cas d'utilisation, nous vous laissons décider ce que vous modélisez, la seule obligation étant de fournir les nouveaux élements suivants :
|
Mise à disposition du travail effectué dans le dépôt Git de GitLab
Systématiquement, avant de terminer une séance de travail, que ce soit en salle TP ou chez vous, mettez à jour votre dépôt local (au cas où vous ayez travaillé en parallèle), validez et poussez votre travail :
-
git fetch # charger les modifications non
encore connues localement
git pull origin develop # mettre à jour votre branche develop
et si conflit et besoin d'une fusion, git mergetool --tool=meld -
git status # connaître l'état de votre
arborescence
selon les besoins, pour préparer la zone de transit pour la validation du prochain instantané, git add, git mv, git checkout --, etc.
git commit -m "je dis ce que contient le nouvel instantané" # valider les modifications de la zone de transit
git push origin develop# pousser pour mettre à disposition - connectez-vous à GitLab et vérifiez que votre travail a été poussé.
À LA FIN DU TP DE LA SÉANCE
Avant de quitter le TP, veuillez s'il vous plaît remplir dans la page Partage de votre groupe le tableau d'avancement de votre binôme-projet :
- page Partage du groupe de TP 1 pour l'avancement ;
- page Partage du groupe de TP 2 pour l'avancement ;
- page Partage du groupe de TP 3 pour l'avancement ;
- page Partage du groupe de TP 4 pour l'avancement ;
- page Partage du groupe de TP 5 pour l'avancement ;
- page Partage du groupe de TP 6 pour l'avancement.
C'est aussi le moment de parcourir la grille d'auto-évaluation de la séance.
