GitHub Flow

[Source](https://guides.github.com/introduction/flow/ "Permalien pour Comprendre le GitHub Flow · GitHub Guides")

1. Comprendre le GitHub Flow · Guides GitHub

GitHub Flow est un workflow léger basé sur une branche qui supporte les équipes et projets où les déploiements sont produits régulièrement. Ce guide explique comment et pourquoi GitHub Flow fonctionne.

1. 1. 1. Créer une Branche

Quand vous travaillez sur un projet, vous allez avoir tout un ensemble de fonctionnalités ou idées en progrès à tout moment -- parmi lesquelles certaines seront prêtes à la publication et d'autres qui ne le sont pas. Le branchage existe pour aider à gérer ce workflow.

Quand vous créez une branche dans votre projet, vous créez un environnement où vous pouvez essayer de nouvelles idées. Les modifications que vous faites sur une branche n'affectent pas la branche `master`, aussi vous êtes libre d'expérimenter et de commiter des changements, en restant sûr que votre branche ne sera pas fusionnée jusqu'à ce qu'elle soit prête à être reçue par quelqu'un avec qui vous collaborez.

1. 1. 1. 1. Pro-truc

Le branchage est un concept-clé dans Git, et la totalité du Flow GitHub est basé dessus. Il n'y a qu'une seule règle : tout ce qui est dans la branche `master` est toujours déployable.

Pour cette raison, il est extrêmement important que votre nouvelle branche soit créé en dehors de master quand vous travaillez sur une fonctionnalité ou une réparation. Votre branche devrait être descriptive (par ex., `refactorisation-authentification`, `contenu-utilisateur-cache-key`, `avatars-retina`), afin que les autres puissent voir ce sur quoi vous travaillez.

1. 1. 1. Ajouter des commits

Une fois votre branche créée, il est temps de commencer à produire des modifications. Chaque fois que vous ajoutez, modifiez ou effacez un fichier, vous produisez un commit et l'ajoutez à votre branche. Ce processus d'ajout de commits conserve une trace de votre progression au fur et à mesure que vous travaillez sur une branche fonctionnalité.

Les commits créent également une historique transparente de votre travail que d'autres peuvent suivre pour comprendre ce que vous avez fait et pourquoi. Chaque commit a un message associé de validation, qui est une description expliquant pourquoi un changement particulier a été fait. En outre, chaque commit est considéré comme une unité distincte du changement. Cela vous permet d'annuler les modifications si un bug est trouvé, ou si vous décidez de vous diriger dans une direction différente.

1. 1. 1. 1. ProTruc

Les messages de commit sont importants, d'autant plus que Git suit vos modifications, puis les affiche sous forme de commits une fois qu'ils sont poussés vers le serveur. En écrivant clairement les messages de commit, vous facilitez la tâche de suivi et fournissez un feedback.

1. 1. 1. Ouvrir un Pull Request

Les Pull Requests amorcent la discussion concernant vos commits. Parce qu'ils sont étroitement intégrés avec le dépôt Git sous-jacent, tout le monde peut voir exactement quels changements seraient fusionnés si les personnes acceptent votre demande.

Vous pouvez ouvrir un Pull Request à tout moment pendant le processus de développement : lorsque vous avez peu ou pas de code, mais si vous souhaitez partager quelques captures d'écran ou des idées générales, lorsque vous êtes coincé et avez besoin d'aide ou de conseils, ou lorsque vous êtes prêt à ce que quelqu'un révise votre travail. En utilisant le système @mention de GitHub dans votre Pull Request, vous pouvez demander des commentaires à des personnes ou des équipes spécifiques, qu'eelles sont dans le couloir ou à dix fuseaux horaires de là.

1. 1. 1. 1. ProTruc

Les Pull Requests sont utiles pour contribuer à des projets open source et pour gérer les changements de référentiels partagés. Si vous utilisez un modèle Fork & Pull, les Pull requests fournissent un moyen d'informer les mainteneurs de projets sur les changements que vous souhaitez qu'ils considèrent. Si vous utilisez un Modèle de Référentiel Partagé, les Pull requests aident à démarrer l'examen du code et la conversation sur les changements proposés avant qu'ils ne soient fusionnés dans la branche master.

1. 1. 1. Discuter et réviser votre code

Une fois qu'une Pull Request a été ouverte, la personne ou l'équipe qui révise vos modifications peuvent avoir des questions ou des commentaires. Peut-être le style de codage ne correspond pas aux lignes directrices du projet, la modification manque de tests unitaires, ou peut-être que tout est parfait et les propositions en ordre. Les pull requests sont conçues pour encourager et capturer ce type de conversation.

Vous pouvez également continuer à pousser sur votre branche à la lumière des discussions et des commentaires sur vos commits. Si quelqu'un remarque que vous avez oublié de faire quelque chose ou s'il y a un bug dans le code, vous pouvez le réparer dans votre branche et pousser la modification. GitHub affichera vos nouveaux commits et tous les commentaires supplémentaires que vous pouvez recevoir dans la vue unifiée Pull Request.

1. 1. 1. 1. ProTruc

Les commentaires de Pull Request sont écrits en Markdown, de sorte que vous pouvez intégrer des images et des emoji, utiliser des blocs de texte préformatés, et autres mises en forme légères.

1. 1. 1. Déployer

Une que fois votre Pull Request est examinée et que la branche passe vos tests, vous pouvez déployer vos modifications pour les vérifier en production. Si votre branche provoque des problèmes, vous pouvez revenir en arrière en déployant la branche maître existante en production.

1. 1. 1. Fusionner

Maintenant que vos modifications ont été vérifiées en production, il est temps de fusionner votre code dans la branche master.

Une fois fusionné, les Pull Requests conservent un enregistrement des historiques de modifications à votre code. Parce qu'elles sont consultables, elles permettent à quiconque de comprendre dans le temps pourquoi et comment une décision a été prise.

1. 1. 1. 1. ProTruc

En incorporant certains mots-clés dans le texte de votre Pull Request, vous pouvez associer des problèmes avec le code. Lorsque votre Pull Request est fusionnée, les questions afférentes sont également fermées. Par exemple, saisir l'expression `Closes #32` fermerait la question numéro 32 dans le référentiel. Pour plus d'informations, consultez notre [article d'aide][1].

[1]: https://help.github.com/articles/closing-issues-via-commit-messages