Vous savez déjà créer des branches, les fusionner, résoudre un conflit, pousser sur GitHub et ouvrir une Pull Request. Ce dernier guide complète le tableau avec deux notions que vous croiserez tôt ou tard : les issues et les forks. Elles répondent chacune à un besoin précis, différent des branches et des Pull Requests.

Les issues : suivre un sujet, pas encore le résoudre

Une issue est un ticket GitHub qui décrit un problème, une idée ou une question, sans forcément contenir de code. Lucas remarque par exemple que la section de contact ajoutée par Emma manque d'un lien vers les réseaux sociaux du projet : plutôt que de le corriger immédiatement, il ouvre une issue pour décrire précisément ce qui manque, afin qu'Emma ou quelqu'un d'autre puisse la traiter plus tard, en toute connaissance de cause.

Une issue vit indépendamment des branches et des commits. Elle peut rester ouverte des semaines, recevoir des commentaires de plusieurs personnes, être liée à une Pull Request qui la résout, puis se fermer automatiquement quand cette PR est fusionnée, si le message de la Pull Request contient une mention comme Closes #12, où 12 est le numéro de l'issue.

Branche ou fork : la vraie question à se poser

Une branche appartient toujours au même dépôt. Emma et Lucas, qui ont tous deux un accès en écriture au dépôt mon-premier-site, peuvent créer autant de branches qu'ils veulent directement dedans, comme vous l'avez fait tout au long de ce parcours.

Un fork est différent : c'est une copie complète et indépendante d'un dépôt, créée sous votre propre compte GitHub. Vous l'utilisez typiquement quand vous n'avez pas les droits d'écriture sur le dépôt d'origine, par exemple pour proposer une correction à un projet open source que vous ne possédez pas. Vous forkez le projet, vous travaillez sur votre copie, avec vos propres branches et vos propres commits, puis vous ouvrez une Pull Request depuis votre fork vers le dépôt d'origine. Les mainteneurs du projet original peuvent alors relire et fusionner votre proposition, sans jamais vous avoir donné d'accès direct à leur dépôt.

La règle simple à retenir : si vous avez un accès en écriture, une branche suffit. Si vous n'en avez pas, un fork est la porte d'entrée.

Bonnes pratiques pour rester maître de l'historique

Avant toute action qui pourrait modifier ou perdre du travail, comme une fusion ou une réécriture d'historique, relisez git status et vérifiez sur quelle branche vous vous trouvez. C'est un réflexe que vous avez pratiqué guide après guide dans ce parcours, et qui reste valable quelle que soit la taille du projet.

Préférez une Pull Request petite, centrée sur un seul sujet clair, plutôt qu'une modification large et difficile à relire sérieusement : vous l'avez vu au guide précédent avec la section de contact d'Emma. Sur un dépôt partagé, synchronisez-vous régulièrement avec git pull plutôt que d'accumuler des semaines de divergence sur votre branche locale, ce qui rend les éventuels conflits bien plus difficiles à démêler.

N'utilisez jamais git push --force comme réflexe

La commande git push --force réécrit l'historique distant pour le faire correspondre exactement à votre historique local, y compris si cela supprime des commits que d'autres personnes ont déjà poussés. Sur une branche partagée, comme main sur un projet collaboratif, c'est une commande potentiellement destructive pour le travail des autres. Si vous pensez en avoir réellement besoin, un instant d'hésitation est légitime : demandez de l'aide à quelqu'un de plus expérimenté avant de l'exécuter sur une branche que d'autres personnes utilisent aussi.

Questions fréquentes

Pas exactement : une issue reste un ticket de discussion. Ce qui les relie, c'est une Pull Request qui mentionne l'issue dans son message, par exemple avec « Closes #12 ». La fusion de cette PR ferme alors automatiquement l'issue correspondante.
Non, jamais automatiquement. Il faut explicitement synchroniser votre fork avec le dépôt d'origine, une opération que GitHub facilite avec un bouton dédié, mais qui reste une action volontaire de votre part.
Non, ce n'est pas obligatoire. Sur votre propre projet personnel, comme mon-premier-site tout au long de ce parcours, committer directement sur main est parfaitement raisonnable. Les Pull Requests deviennent surtout utiles dès qu'une autre personne doit relire ou discuter d'un changement avant qu'il ne soit intégré.
En résumé de ce parcours

Git suit l'historique de votre projet en local, avec des fichiers de travail, une staging area et des commits. GitHub héberge une copie de cet historique et ajoute des outils de collaboration comme les Pull Requests, les issues et les forks. Une branche isole un travail dans le même dépôt ; un fork isole un travail dans un dépôt entièrement séparé. Dans les deux cas, git status reste votre meilleur réflexe avant d'agir.

Vérifiez que vous avez compris

Vous découvrez un petit projet open source qui vous intéresse sur GitHub, mais vous n'avez aucun accès en écriture dessus. Vous voulez corriger une faute dans son README. Quelle est la première étape correcte : créer une branche directement sur ce dépôt, ou le forker ?

Le forker. Sans accès en écriture, vous ne pouvez pas créer de branche directement sur le dépôt d'origine. Le fork crée une copie sous votre propre compte, sur laquelle vous avez tous les droits, et depuis laquelle vous pourrez ensuite proposer votre correction via une Pull Request vers le projet d'origine.

Chapitre terminé