Normalisation GIT

Normalisation du dépôt GitHub (Work In Progress)

---

Principes de bases

Ce qui se trouve dans les branches principales /master et /devel :

• doit toujours compiler
• doit garder une cohérence fonctionnelle entre les nœuds

Architecture

Le développement utilise des branches dont chacune a un rôle défini :

• /master, branche principale dans laquelle on a une version fonctionnelle et entièrement testée de nos nœuds. Cette branche doit être déployable sur nos robotinos.

• /devel, branche principale dédiée au développement :

  • On y intègre les nouvelles fonctionnalités
  • On utilise cette branche pour les tests (sur simulateur, par exemple)

• /*-devel, branche commune de partage, c'est une branche dédiée au développement nécessitant un travail plus important qu’une simple fonctionnalité :

  • Ce type de branche est mis en place ponctuellement tout le temps de la réalisation de ce travail
  • Le travail impacte plusieurs noeuds, en remettant en cause leur dépendance et leur fonctionnement global
  • Cependant, la branche doit pouvoir être synchronisée régulièrement avec devel

• /work/USER_NAME/... ou /feature/USER_NAME/..., branche de features ou l'on développe de nouvelles focntionnalités

  • Elles doivent avoir une durée de vie courte et être réintégrées le plus tôt possible à la branche de développement dont elles dépendent (devel ou /*-devel)
  • Elles ne doivent être utilisées que pour implémenter une fonctionnalité spécifique (n'impactant que peu de nœuds, par exemple)

Exemple sur une branche

Chaque fois que vous avez une modification à faire sur le code, vous ouvrez une branche spécialement pour la modif, exemple : /feature/USER_NAME/navigation/deplacement/correction_pathfinder à partir de votre branche de référence (ou branche "parente"), ici /devel.
Pendant votre travail, vous restez en synchronisation avec la branche de référence, par exemple ici :

git merge origin/devel

Cette manip' est à faire à chaque fois qu'il y a du nouveau sur la branche parente.

Une fois seulement que vous avez terminé votre feature ou que vous avez une modification (stable) significative à partager, vous merger vos changements dans votre branche "parente".

Le raisonnement s'applique jusqu'à la branche /devel à la différence près qu'on ne push pas dessus, on fait l'intégration des changements via une pull requests.

Idem, le moment venu, les intégration de /devel vers /master se feront par des pull requests.

Pull requests

Il est important que la review des pull request soit fait par quelqu'un ne travaillant pas sur les codes faisant l'objet de la pull request. On s'assure ainsi d'avoir une relecture par un oeil neuf et ça permet aussi de partager les conaissances entre les membres de l'équipe.

https://help.github.com/articles/using-pull-requests/

Aide (WIP)

Si vous avez des questions sur ce qui précède ou ce qui suit, n'hésitez pas à poser les questions (à Valentin par exemple).

Liens utiles

https://training.github.com/kit/downloads/fr/github-git-cheat-sheet.pdf
https://www.atlassian.com/git/

Commandes utiles

Récupérer une branche distance

Pousser une branche locale sur une distante

Merger