Github Workflow
En interne
Le projet utilise ce workflow :
- Une branche
masterlié aux releases - Une branche
developpour le développement - Des branches
features/featureou autres
Chaque push à la branche master publiera une release sur le Play Store.
Une pipeline CI/CD est mise en place pour compiler et tester automatiquement.
En Open Source
Avant enchainer sur le Github Flow, il est recommandé d'ouvrir un Issue afin de voir si les développeurs n'ont pas déjà réfléchies sur le problème.
Nous utilisons principalement le Github Flow. Voici toutes les étapes en détails :
-
Le dépôt est fork par le contributeur sur Github.
-
Une fois fork, le contributeur clone ce dépôt sur son ordinateur.
1 | |
- Après le clone, le dépôt
originestgit@github.com:[contributeur]/minitel-app.git. Afin que le dépôt soit toujours à jour par rapport au projet à contribuer, le contributeur doit ajouter le dépôt distant ditupstream:
1 | |
- A partir de ce moment, le contributeur peut travailler sur son dépôt en local. Exemple de commandes :
1 2 3 | |
-
Les push sont envoyés dans le dépôt du contributeur.
-
Une fois le travail terminé, le contributeur voudra merge son dépôt distant
git@github.com:[contributeur]/minitel-app.gitversgit@github.com:Darkness4/minitel-app.git. Cependant, le dépôt distant du contributeur doit être mis à jour. Si la branche du contributeur s'appelaitfix-stuffet la branche cible du dépôt original s'appelaitdevelop, alors il faudra mettre à jourfix-stuffen faisant :
1 2 3 4 5 6 7 | |
-
Le contributeur peut alors ouvrir un Pull Request et request un Code Review.
-
Les développeurs du projets pourra alors Code Review et merge.