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 forks, les commits et les pull requests fonctionnent ensemble pour vous offrir cet espace, afin que vous puissiez expérimenter, enregistrer progressivement votre travail et proposer des modifications finalisées pour revue.
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 un fork si vous n’avez pas d’accès en écriture, ou si vous souhaitez être totalement indépendant 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 un fork, vous pouvez également ouvrir des pull requests pour le dépôt 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 contribuer à des projets open source, lorsque vous ne disposez peut-être pas d’un accès en écriture au dépôt en amont.
Soumettre son travail avec 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é.
Effectuer fréquemment des commits sur votre branche ou votre fork 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 pull requests
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 pull request regroupe vos commits, une description de la modification et les outils dont les réviseurs ont besoin pour en discuter et l’évaluer avant sa fusion.
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é
Tant qu’une pull request est ouverte, la branche de base peut continuer d’évoluer à mesure que d’autres personnes fusionnent leurs modifications. 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.
- Effectuez un rebase pour mettre de l’ordre dans un historique de commits désordonné — en réorganisant, en fusionnant ou en reformulant des commits — avant de demander une relecture.
- Résolvez les conflits de fusion lorsque Git ne peut pas combiner automatiquement les modifications concurrentes.
Travailler avec les commandes du dépôt
Les contributeurs expérimentés travaillent dans les garde-fous qu’un référentiel définit. Ces contrôles définissent où vous pouvez effectuer des pushs, qui doit approuver votre travail et quelles vérifications doivent réussir avant la fusion.
- 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 GitHub Enterprise Server d’imposer des vérifications des règles côté serveur avant que les validations ne soient acceptées.
Chaîne d’outils intégrée
Les pull requests connectent votre code à l’automatisation et aux services qui vous aident à coder rapidement et en toute sécurité.
GitHub Copilot ** peut vous aider à écrire, déboguer et optimiser le code.
- Code scanning ainsi que Dependabot mettent en évidence les problèmes de sécurité et les dépendances vulnérables à mesure que vos modifications progressent dans une pull request, afin que vous puissiez appliquer des pratiques de développement sécurisé dès le début.
- GitHub Actions peut exécuter l’intégration continue à chaque push sur votre pull request, en compilant et en testant automatiquement vos modifications.