> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify-docs-automation-github-pr-review.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Concepts de Git pour la documentation

> Apprenez les bases du contrôle de version Git pour les workflows docs-as-code : dépôts, branches, commits et collaboration via pull requests.

Git est un système de contrôle de version qui suit les modifications apportées à votre documentation et permet la collaboration en équipe. Avec Git, vous pouvez voir ce qui a changé au fil du temps dans les fichiers, qui a effectué les modifications, quand elles ont été faites et pourquoi. Git facilite également le retour à des versions précédentes de fichiers si vous devez annuler des modifications.

L’éditeur web effectue des opérations Git en arrière-plan. En comprenant Git, vous pouvez travailler plus efficacement avec l’éditeur web et collaborer avec des membres de l’équipe qui utilisent un environnement de développement local.

<div id="why-git-for-documentation">
  ## Pourquoi utiliser Git pour la documentation ?
</div>

Git fournit des fonctionnalités essentielles pour gérer la documentation.

* **Historique des versions** : Voir ce qui a changé, quand et pourquoi, pour chaque fichier.
* **Collaboration** : Plusieurs personnes peuvent travailler sur différentes parties en parallèle.
* **Sécurité** : Tester des changements sans risquer d’altérer la documentation en production.
* **Processus de revue** : Les membres de l’équipe peuvent relire les changements avant la publication.
* **Récupération** : Annuler des erreurs ou restaurer des versions précédentes.

<div id="new-to-git">
  ## Nouveau sur Git ?
</div>

Si vous découvrez totalement Git et le contrôle de version, voici un parcours pour vous lancer.

<Steps>
  <Step title="Utilisez d'abord l'éditeur web.">
    L'[éditeur web](/fr/editor/index) gère automatiquement les opérations Git.

    * Visualisez immédiatement toutes les modifications au fur et à mesure.
    * Créez des branches en un clic.
    * Publiez et créez des pull requests (demandes de fusion) sans utiliser de commandes Git.

    Cela vous permet d'apprendre les concepts de Git sans utiliser la ligne de commande.
  </Step>

  <Step title="Apprenez en pratiquant.">
    Lorsque vous utilisez l'éditeur web, vous utilisez Git.

    * **Enregistrer les modifications** crée un commit.
    * **Créer une branche** crée une branche Git.
    * **Publier** ouvre une pull request (demande de fusion) pour relecture.
  </Step>

  <Step title="Explorez le développement local lorsque c'est utile.">
    Vous pouvez gérer votre documentation entièrement avec l'éditeur web et le Dashboard, mais vous pouvez personnaliser votre flux de travail en travaillant dans votre environnement local.

    * Créez et modifiez des fichiers dans votre éditeur préféré.
    * Utilisez Git en ligne de commande, GitHub Desktop ou une extension dans votre éditeur.
    * Prévisualisez les modifications en local avant de les publier.
    * Intégrez d'autres outils comme les tickets de support, le suivi des problèmes et les design systems.
  </Step>
</Steps>

<div id="core-git-concepts">
  ## Concepts fondamentaux de Git
</div>

<AccordionGroup>
  <Accordion title="Branche">
    Une branche pointe vers un commit spécifique dans votre référentiel. Votre documentation en production est générée à partir d'une branche de déploiement. Vous pouvez avoir autant d'autres branches que vous voulez, contenant des modifications qui ne sont pas encore publiées dans votre documentation en production. Si vous voulez intégrer les modifications d'une branche dans votre documentation en production, vous pouvez fusionner la branche dans votre branche de déploiement via une pull request (demande de fusion).

    Utilisez les branches pour travailler sur des modifications sans affecter votre documentation en production, expérimenter en toute sécurité de nouvelles fonctionnalités et obtenir des revues avant la publication.
  </Accordion>

  <Accordion title="Clone">
    Téléchargez une copie complète d'un référentiel sur votre ordinateur, incluant tous les fichiers et l'historique complet. Lorsque vous clonez, vous obtenez tout ce dont vous avez besoin pour travailler en local.

    ```bash theme={null}
    git clone https://github.com/your-org/your-repo
    ```
  </Accordion>

  <Accordion title="Commit">
    Un instantané enregistré de vos modifications à un moment donné. Chaque commit inclut un message décrivant ce qui a changé et crée une trace permanente dans l'historique de votre projet.
  </Accordion>

  <Accordion title="Conflit">
    Se produit lorsque deux personnes modifient différemment la même partie d'un fichier. Git vous demande de choisir manuellement quelle modification conserver ou de combiner les deux.
  </Accordion>

  <Accordion title="Branche de déploiement">
    La branche principale de votre projet. Les modifications apportées à cette branche sont automatiquement publiées sur votre site de documentation. Souvent appelée `main`, mais vous pouvez définir n'importe quelle branche comme votre branche de déploiement.
  </Accordion>

  <Accordion title="Diff">
    Un diff (ou différence) montre les modifications entre deux versions d'un fichier. Lors de l'examen de pull requests (demandes de fusion), les diffs mettent en évidence ce qui est différent par rapport à la version d'origine du fichier.
  </Accordion>

  <Accordion title="Fusion">
    Combinez les modifications d'une branche dans une autre. Généralement effectué via une pull request (demande de fusion) après revue pour intégrer un travail sur des fonctionnalités dans votre branche de déploiement.
  </Accordion>

  <Accordion title="Pull">
    Récupérez les dernières modifications depuis le référentiel distant vers votre copie locale. Vous permet de rester à jour avec le travail des autres.

    ```bash theme={null}
    git pull
    ```
  </Accordion>

  <Accordion title="Pull request">
    Un moyen de proposer la fusion des modifications d'une branche dans votre documentation en production. Permet la revue et la discussion avant que les modifications ne soient mises en ligne. Couramment appelée PR, et aussi appelée merge request dans GitLab.
  </Accordion>

  <Accordion title="Push">
    Envoyez vos commits locaux vers le référentiel distant. Cela rend vos modifications disponibles pour les autres et peut déclencher des déploiements automatiques.

    ```bash theme={null}
    git push
    ```
  </Accordion>

  <Accordion title="Remote">
    Une version de votre référentiel hébergée sur un serveur. Votre référentiel local se connecte à un référentiel distant pour pousser et récupérer des modifications.
  </Accordion>

  <Accordion title="Référentiel">
    Le code source de votre documentation, avec tous les fichiers et leur historique, qui composent les pages de votre site de documentation. L'éditeur en ligne se connecte à votre référentiel de documentation pour accéder au contenu et le modifier.
  </Accordion>

  <Accordion title="Stage">
    Préparez des modifications spécifiques à inclure dans votre prochain commit. Le staging vous permet d'organiser les modifications en commits logiques.

    ```bash theme={null}
    git add filename.mdx
    ```
  </Accordion>
</AccordionGroup>

<div id="how-the-web-editor-uses-git">
  ## Comment l’éditeur web utilise Git
</div>

L’éditeur web se connecte à votre référentiel Git via la [GitHub App](/fr/deploy/github) ou l’[intégration GitLab](/fr/deploy/gitlab) et automatise les opérations Git courantes.

Lorsque vous :

* **Ouvrez un fichier** : l’éditeur récupère la dernière version depuis votre référentiel, pour que vous travailliez toujours avec un contenu à jour.
* **Apportez des modifications** : l’éditeur suit vos modifications comme un brouillon, qui pourra devenir un commit lorsque vous serez prêt à enregistrer votre travail.
* **Enregistrez les modifications** : l’éditeur crée un commit avec vos modifications, conservant votre travail dans l’historique du projet.
* **Créez une branche** : l’éditeur crée une nouvelle branche dans votre référentiel, utilisable par toute personne ayant accès au référentiel afin de collaborer et de passer les changements en revue.
* **Publiez sur votre branche de déploiement** : l’éditeur crée un commit et pousse directement vers votre branche de déploiement, ce qui publie immédiatement vos modifications.
* **Publiez sur d’autres branches** : l’éditeur crée une pull request (demande de fusion), vous permettant d’obtenir des retours avant de fusionner vos modifications dans votre branche de déploiement.

<div id="common-workflows">
  ## Flux de travail courants
</div>

<div id="publish-directly-to-your-deployment-branch">
  ### Publier directement dans votre branche de déploiement
</div>

<Tabs>
  <Tab title="Avec l’éditeur web">
    1. Ouvrez le fichier dans l’[éditeur web](https://dashboard.mintlify.com/editor).
    2. Apportez vos modifications.
    3. Cliquez sur **Publish**.
    4. Les modifications apparaissent dans le référentiel et sont déployées automatiquement.
  </Tab>

  <Tab title="Avec le développement local">
    1. Récupérez les dernières modifications : `git pull`
    2. Modifiez le fichier dans votre éditeur.
    3. Préparez les modifications : `git add filename.mdx`
    4. Créez un commit : `git commit -m "Update documentation"`
    5. Poussez les modifications : `git push`
    6. Les modifications sont déployées automatiquement.
  </Tab>
</Tabs>

<div id="work-on-a-feature-branch">
  ### Travailler sur une branche de fonctionnalité
</div>

<Tabs>
  <Tab title="Utiliser l’éditeur web">
    <Note>
      Pour créer des pull requests (demandes de fusion) depuis l’éditeur web, vous devez avoir activé une règle de protection de branche qui impose des pull requests avant que les modifications puissent être fusionnées dans votre branche de déploiement. Sans règles de protection de branche, les modifications apportées sur les branches sont fusionnées dans votre branche de déploiement lors de la publication.
    </Note>

    1. Créez une branche à partir du menu déroulant des branches dans la barre d’outils de l’éditeur.
    2. Apportez et enregistrez des modifications sur la branche.
    3. Cliquez sur **Publish** pour créer une pull request.
    4. Fusionnez la pull request lorsque vous êtes prêt.
  </Tab>

  <Tab title="Utiliser un environnement local">
    1. Créez une branche : `git checkout -b feature-name`
    2. Effectuez un commit de vos modifications.
    3. Poussez la branche : `git push -u origin feature-name`
    4. Créez une pull request.
    5. Fusionnez la pull request lorsque vous êtes prêt.
  </Tab>
</Tabs>

<div id="review-changes-before-publishing">
  ### Passer en revue les changements avant la publication
</div>

<Steps>
  <Step title="Créer une branche de fonctionnalité.">
    Travaillez sur vos modifications dans une branche distincte de votre branche de déploiement afin de pouvoir les partager et les passer en revue avant la publication.
  </Step>

  <Step title="Apporter vos modifications.">
    Modifiez les fichiers et créez des commits sur la branche de fonctionnalité.
  </Step>

  <Step title="Créer une pull request.">
    Créez une pull request (demande de fusion) pour proposer la fusion des changements de votre branche de fonctionnalité dans la branche de déploiement.
  </Step>

  <Step title="Passer en revue le diff.">
    Vérifiez vos changements. La pull request affiche, ligne par ligne, les différences par rapport à la version d’origine du fichier.
  </Step>

  <Step title="Recueillir les retours de l’équipe.">
    Les membres de l’équipe peuvent commenter des lignes spécifiques ou l’ensemble des changements. Apportez les modifications nécessaires et créez des commits sur la branche de fonctionnalité.
  </Step>

  <Step title="Fusionner après approbation.">
    Fusionnez la pull request pour publier les changements sur votre documentation en production.
  </Step>
</Steps>

<div id="git-best-practices">
  ## Bonnes pratiques Git
</div>

Chaque équipe développe ses propres flux de travail et préférences, mais voici quelques bonnes pratiques générales pour commencer.

* **Rédigez des messages de commit descriptifs** : Soyez précis sur ce qui a changé en utilisant un langage actif. `Fix broken link in API docs` est plus informatif que `update page`.
* **Utilisez des noms de branches explicites** : Les noms de branches doivent expliquer l’objectif de la branche. Utilisez des noms parlants comme `update-api-reference` plutôt que des noms génériques comme `temp` ou `my-branch`.
* **Gardez les branches ciblées** : Limitez les changements sur une branche à une tâche ou un projet spécifique. Cela facilite les revues de code et réduit les conflits.
* **Supprimez les branches après fusion** : Supprimez les branches dont vous n’avez plus besoin pour garder votre référentiel bien organisé.
* **Pull avant de push** : Faites toujours un pull des dernières modifications avant de pousser pour éviter les conflits. L’éditeur web le fait automatiquement.
* **Relisez d’abord vos propres changements** : Vérifiez le diff avant de créer une pull request (demande de fusion).