Lorsque vous contribuez à un projet, vous avez besoin d’un endroit sûr pour écrire et affiner du code avant qu’il n’affecte votre base de code principale. Les branches, les duplications, les validations et les demandes de tirage fonctionnent ensemble pour vous donner cet espace, afin de pouvoir expérimenter, vérifier le travail de manière incrémentielle et proposer des modifications terminées pour révision.
Isolation de votre travail avec des branches et des fourches
La plupart du travail commence par créer une copie isolée du code que vous pouvez modifier librement.
- Utilisez une branche lorsque vous avez un accès en écriture à un référentiel. Une branche vous permet de développer une fonctionnalité, de corriger un bogue ou d’expérimenter dans une zone autonome du référentiel sans affecter d’autres branches. Vous créez une branche à partir d’une branche existante, généralement la branche par défaut.
- Utilisez une duplication lorsque vous n’avez pas d’accès en écriture, ou lorsque vous souhaitez une indépendance totale du projet d’origine. Un fork est un dépôt distinct qui partage le code et les paramètres de visibilité avec le dépôt « en amont » d’origine. Il a ses propres branches, problèmes et demandes de tirage. Avec une duplication, vous pouvez également ouvrir des demandes de tirage pour le référentiel en amont.
Une branche est généralement le choix le plus simple lorsque vous collaborez déjà dans un référentiel partagé. Un fork est souvent le meilleur choix pour open source contributions, où vous n’avez peut-être pas accès en écriture au référentiel en amont.
Vérification de l’utilisation des validations
Lorsque vous écrivez du code, vous enregistrez de petits groupes significatifs de modifications en tant que validations. Chaque validation enregistre un instantané de votre travail avec un message décrivant ce qui a changé, ce qui facilite le suivi de l’historique, la révision des modifications et la façon dont le code a évolué.
La validation fréquente sur votre branche ou duplication vous permet de :
- Décomposez une modification plus importante en étapes révisables.
- Revenez à un état antérieur si une expérience ne fonctionne pas.
- Donnez aux réviseurs un historique clair de la façon dont vous êtes arrivé au changement final.
Proposer des modifications avec des demandes de tirage
Lorsque votre travail est prêt à être partagé, vous ouvrez une demande de tirage pour proposer la fusion de vos modifications dans la branche de base. Une demande de tirage regroupe vos validations, une description de la modification et les réviseurs d’outils doivent discuter et évaluer ces modifications avant de les fusionner.
Vous pouvez ouvrir une demande de tirage pendant que le travail est toujours en cours en créant un brouillon de demande de tirage, qui partage vos modifications sans demander formellement de révision. Cela est utile lorsque vous souhaitez obtenir des commentaires précoces ou que vous souhaitez exécuter des vérifications automatisées sur votre code.
Maintenir votre code actuel et optimisé
Pendant qu’une demande de tirage est ouverte, la branche de base peut continuer à changer à mesure que d’autres personnes fusionnent leur travail. Pour nettoyer vos modifications et réduire les conflits, vous pouvez :
- Fusionnez ou rebasez la branche de base dans votre branche fréquemment afin que votre différence reste axée sur ce que votre changement introduit. GitHub affiche un écart à trois points par défaut, qui compare votre branche au point où elle diffère de la base.
- Rebasez pour rebasier un historique de validation messy ( réorganiser, combiner ou reformuler des validations) avant de demander une révision.
- Résolvez les conflits de fusion lorsque Git ne peut pas combiner automatiquement les modifications concurrentes.
Utilisation des contrôles de référentiel
Les contributeurs expérimentés travaillent dans les garde-fous qu’un référentiel définit. Ces contrôles permettent d’envoyer (push), qui doit approuver votre travail et ce qui doit passer avant de fusionner.
- Les branches protégées et les ensembles de règles peuvent bloquer les push directs vers des branches importantes, exiger des validations linéaires ou signées, et exiger des vérifications ou des révisions d’état avant la fusion.
- Les propriétaires de code sont automatiquement demandés pour révision lorsque votre modification touche les fichiers qu’ils possèdent, donc planifiez leur approbation sur les zones sensibles.
- Les ensembles de règles Push peuvent s’appliquer sur un réseau de fourche, en limitant les chemins d’accès aux fichiers, les tailles ou les noms dans chaque fourche.
- Les hooks de pré-réception permettent aux administrateurs d’appliquer GitHub Enterprise Server des vérifications de stratégie sur le serveur avant l’acceptation des validations.
Chaîne d’outils intégrée
Les demandes de tirage connectent votre code à l’automatisation et aux services qui vous aident à écrire du code rapidement et en toute sécurité.
- Code scanning ainsi que Dependabot les problèmes de sécurité de surface et les dépendances vulnérables à mesure que vos modifications passent par une demande de tirage( pull request) afin de pouvoir appliquer des pratiques de codage sécurisées au début.
- GitHub Actions peut exécuter l’intégration continue sur chaque envoi (push) à votre demande de tirage (pull request), en créant et en testant automatiquement vos modifications.