Un pull request flow est un flux de travail léger en 6 étapes basé sur une branche. Remarque: ce guide utilise des citations de GitHub Guides (Open Source).

Voici un aperçu de ce workflow:
0. "Pull" prendre les dernieres modifications (obtenir la base de code la plus récente en locale)
1. Créer une "branche" (version)
2. Commit les changements
3. Ouvrir une "pull request" (proposer les changements)
4. Discussions et révisions du code
5. Rebaser et tester
6. Merge (Fusion) dans la branche master

Remarque: Git est livré avec des outils GUI intégrés pour explorer les branches - gitk . Nous recommandons de l'utiliser afin d'avoir un bon aperçu de l'organisation. Il suffit de le lancer dans le terminal:
gitk

Tip : Il n'y a qu'une seule règle: tout ce qui se trouve dans la branche master est toujours déployable (valide).

Pour cette raison, il est extrêmement important de travailler sur une branche différente de 'master' pour mettre au point une fonctionnalité ou un correctif. Le nom de la branch doit être descriptif (e.g., refactor-authentication, build-maze-visualizer, use-embedded-format).

Les commits permettent de suivre les modifications pendant que nous travaillons. Les commits créent également un historique transparent de notre travail que les autres peuvent aussi suivre afin comprendre ce qui a été fait et pourquoi. Chaque commit a un message associé, c'est une description expliquant pourquoi une modification particulière a été effectuée.

En outre, chaque validation est considérée comme une unité accessible. Cela nous permet d'annuler les modifications si un bogue est détecté ou de créer de nouvelles versions à partir d'un point particulier.

Nous recommandons d'utiliser une interface graphique pour gérer les commit, cela nous donne un meilleur aperçu de ce que nous voulons enregistrer.

  $ git gui // (git-gui)

Tip : Les messages de validation sont importants, ils décrivent l'historique des changements. Ecrire des messages de validation clairs facilite le suivi du code.

La Pull Request initie une discussion autours des commits réalisés. Tout le monde peut voir exactement quelles modifications seraient fusionnées en acceptant cette demande.

Nous pouvons ouvrir une demande à tout moment:
lorsque que nous souhaitons partager des captures d'écran ou des idées générales,
lorsque nous sommes bloqué et/ou avons besoin d'aide ou de conseils,
ou lorsque nous sommes prêt pour une révision du travail.

Tip : Les Pull Requests sont utiles pour contribuer à des projets open source et pour gérer les modifications apportées aux projets partagés.

Une fois qu'une pull request a été ouverte, la personne ou l'équipe qui examine les modifications peut avoir des questions ou des commentaires (le plus souvent via une plateforme hôte). Peut-être que le style de codage ne correspond pas aux directives du projet, que les changements manquent de tests unitaires, ou encore que tout est en ordre. Les pull request sont conçues pour encourager et sauvegarder ces conversations.

Nous pouvons toujours continuer à faire des commits et engager des discussions. Si quelqu'un commente qu'il y a un bogue dans le code, nous pouvons le corriger dans notre branche et pousser la modification dans la revue.

Une fois que la pull request et les tests ont été validés, nous pouvons rebaser notre branche sur master (elle utilisera la version la plus récente du code) afin de tester toutes les modifications ensemble (production).

Si notre branche cause des problèmes ou que les tests ne passent pas, nous devons la corriger avant de fusionner avec master.

--no-ff | No Fast Forward

L'option --no-ff est utile lorsque nous souhaitons avoir une idée claire des commits de notre branche une fois la fusion effectuée. Cela traite une branche de fonctionnalité avec des commits comme une seule unité, et les fusionner en une seule unité. La branche ressort ainsi clairement de notre historique avec l'option --no-ff.

Tag & Version