{"meta":{"title":"À propos de Git","intro":"Découvrez le système de contrôle de version Git et son fonctionnement avec GitHub.","product":"Bien démarrer","breadcrumbs":[{"href":"/fr/get-started","title":"Bien démarrer"},{"href":"/fr/get-started/using-git","title":"Utilisation de Git"},{"href":"/fr/get-started/using-git/about-git","title":"À propos de Git"}],"documentType":"article"},"body":"# À propos de Git\n\nDécouvrez le système de contrôle de version Git et son fonctionnement avec GitHub.\n\n## À propos de la gestion de versions et de Git\n\nUn système de gestion de versions, ou VCS, suit l’historique des modifications quand des personnes et équipes collaborent sur des projets. Lorsque les développeurs apportent des modifications au projet, toute version antérieure du projet peut être récupérée à tout moment.\n\nLes développeurs peuvent passer en revue l’historique d’un projet pour savoir :\n\n* Quelles modifications ont été apportées ?\n* Qui a apporté les modifications ?\n* Quand les modifications ont-elles été apportées ?\n* Pourquoi les modifications étaient-elles nécessaires ?\n\nLes systèmes VCS donnent à chaque contributeur une vue unifiée et cohérente d’un projet, en exposant le travail déjà en cours. Voir un historique transparent des modifications, qui les a apportées et leur contribution au développement d’un projet aide les membres de l’équipe à rester en phase tout en travaillant indépendamment.\n\nDans un système de gestion de versions distribué, chaque développeur dispose d’une copie complète du projet et de l’historique du projet. Contrairement aux systèmes de gestion de versions centralisés autrefois populaires, les systèmes VCS distribués n’ont pas besoin d’une connexion constante à un dépôt central. Git est le système de gestion de versions distribué le plus populaire. Git est couramment utilisé pour le développement de logiciels open source et commerciaux, avec des avantages significatifs pour les individus, les équipes et les entreprises.\n\n* Git permet aux développeurs de voir la chronologie entière de leurs modifications, des décisions et de la progression de n’importe quel projet à un seul endroit. À partir du moment où il accède à l’historique d’un projet, le développeur a tout le contexte nécessaire pour le comprendre et commencer à y participer.\n\n* Les développeurs travaillent dans chaque fuseau horaire. Avec un système VCS distribué comme Git, la collaboration peut se produire à tout moment tout en conservant l’intégrité du code source. À l’aide de branches, les développeurs peuvent proposer des modifications en toute sécurité au code de production.\n\n* Les entreprises qui utilisent Git peuvent briser les barrières de communication entre les équipes et les aider à se concentrer sur l’optimisation de leur travail. De plus, Git permet d’aligner des experts dans une entreprise pour collaborer sur des projets majeurs.\n\n## À propos des dépôts\n\nUn dépôt, ou projet Git, englobe la collection entière de fichiers et de dossiers associés à un projet, ainsi que l’historique de révision de chaque fichier. L’historique de fichier apparaît sous forme d’instantanés dans le temps appelés commits. Les commits peuvent être organisés en plusieurs lignes de développement appelées branches. Étant donné que Git est un système VCS distribué, les dépôts sont des unités autonomes et toute personne disposant d’une copie du dépôt peut accéder à l’intégralité du codebase et à son historique. En utilisant la ligne de commande ou d’autres interfaces faciles à utiliser, un dépôt Git permet également d’interagir avec l’historique, de cloner le dépôt, de créer des branches, de commiter, de fusionner, de comparer les modifications entre les versions du code, etc.\n\nGrâce à des plateformes telles que GitHub, Git offre également davantage de possibilités de transparence et de collaboration dans le cadre d'un projet. Les dépôts publics aident les équipes à collaborer pour créer le meilleur produit final possible.\n\n## Comment fonctionne GitHub ?\n\nGitHub héberge des référentiels Git et fournit aux développeurs des outils leur permettant d'améliorer leur code grâce à des fonctions en ligne de commande, des questions (discussions en filigrane), des demandes d'extraction, des révisions de code ou l'utilisation d'une collection d'applications gratuites et payantes dans le GitHub Marketplace. Avec des couches de collaboration comme le flux GitHub, une communauté de 100 millions de développeurs et un écosystème avec des centaines d'intégrations, GitHub change la façon dont les logiciels sont construits.\n\nGitHub intègre la collaboration directement dans le processus de développement. Le travail est organisé en dépôts où les développeurs peuvent décrire les exigences ou la direction et définir les attentes pour les membres de l’équipe. Ensuite, en utilisant le flux GitHub, les développeurs créent simplement une branche pour travailler sur les mises à jour, livrent les changements pour les sauvegarder, ouvrent une demande d'extraction pour proposer et discuter des changements, et fusionnent les demandes d'extraction une fois que tout le monde est sur la même longueur d'onde. Pour plus d’informations, consultez « [flux de GitHub](/fr/get-started/using-github/github-flow) ».\n\nPour les plans et les coûts GitHub, consultez [GitHub Pricing](https://github.com/pricing). Pour plus d’informations sur la façon dont GitHub Enterprise se compare à d’autres options, consultez [Comparing GitHub à d’autres solutions DevOps](https://github.com/resources/articles/devops-tools-comparison).\n\n## GitHub et la ligne de commande\n\n### Commandes Git de base\n\nPour utiliser Git, les développeurs utilisent des commandes spécifiques pour copier, créer, modifier et combiner du code. Ces commandes peuvent être exécutées directement à partir de la ligne de commande ou à l’aide d’une application comme GitHub Desktop. Voici quelques commandes courantes pour l’utilisation de Git :\n\n* `git init` initialise un tout nouveau dépôt Git et commence à suivre un répertoire existant. Elle ajoute un sous-dossier masqué dans le répertoire existant qui héberge la structure de données interne requise pour la gestion de versions.\n\n* `git clone` crée une copie locale d’un projet qui existe déjà à distance. Le clone inclut tous les fichiers, l’historique et les branches du projet.\n\n* `git add` indexe un changement. Git effectue le suivi des modifications apportées au codebase d’un développeur, mais il est nécessaire d’indexer et de prendre un instantané des modifications pour les inclure dans l’historique du projet. Cette commande effectue la préparation, la première partie de ce processus en deux étapes. Toutes les modifications qui sont indexées feront partie de l’instantané suivant et de l’historique du projet. La préparation et le commit effectués séparément donnent aux développeurs un contrôle complet sur l'historique de leur projet sans modifier leur manière de coder et de travailler.\n\n* `git commit` enregistre l’instantané dans l’historique du projet et termine le processus de suivi des modifications. En bref, un commit fonctionne comme la prise d’une photo. Tout ce qui a été mis en scène avec `git add` fera partie de l’instantané avec `git commit`.\n\n* `git status` affiche l’état des modifications comme non suivies, modifiées ou indexées.\n\n* `git branch` affiche les branches traitées localement.\n\n* `git merge` fusionne les lignes de développement. Cette commande est généralement utilisée pour combiner les modifications apportées sur deux branches distinctes. Par exemple, un développeur effectue une fusion quand il souhaite combiner les modifications d’une branche de fonctionnalité dans la branche principale pour le déploiement.\n\n* `git pull` met à jour la ligne de développement locale avec les mises à jour de son équivalent distant. Les développeurs utilisent cette commande si un collègue a effectué des commits sur une branche d’un dépôt distant et qu’ils souhaitent refléter ces modifications dans leur environnement local.\n\n* `git push` met à jour le dépôt distant avec les commits effectués localement sur une branche.\n\nPour plus d’informations, consultez le [guide de référence complet des commandes Git](https://git-scm.com/docs).\n\n### Exemple : Contribuer à un dépôt existant\n\n```bash\n# download a repository on GitHub to our machine\n# Replace `owner/repo` with the owner and name of the repository to clone\ngit clone https://github.com/owner/repo.git\n\n# change into the `repo` directory\ncd repo\n\n# create a new branch to store any new changes\ngit branch my-branch\n\n# switch to that branch (line of development)\ngit checkout my-branch\n\n# make changes, for example, edit `file1.md` and `file2.md` using the text editor\n\n# stage the changed files\ngit add file1.md file2.md\n\n# take a snapshot of the staging area (anything that's been added)\ngit commit -m \"my snapshot\"\n\n# push changes to github\ngit push --set-upstream origin my-branch\n```\n\n### Exemple : Démarrer un nouveau référentiel et le publier sur GitHub\n\nTout d'abord, vous devrez créer un nouveau référentiel sur GitHub. Pour plus d’informations, consultez « [Hello World](/fr/get-started/start-your-journey/hello-world) ».\n**N’initialisez pas** le dépôt avec un fichier README, .gitignore ou un fichier Licence. Ce dépôt vide attend votre code.\n\n```bash\n# create a new directory, and initialize it with git-specific functions\ngit init my-repo\n\n# change into the `my-repo` directory\ncd my-repo\n\n# create the first file in the project\ntouch README.md\n\n# git isn't aware of the file, stage it\ngit add README.md\n\n# take a snapshot of the staging area\ngit commit -m \"add README to initial commit\"\n\n# provide the path for the repository you created on github\ngit remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git\n\n# push changes to github\ngit push --set-upstream origin main\n```\n\n### Exemple : contribuer à une branche existante sur GitHub\n\nCet exemple suppose que vous avez déjà un projet appelé `repo` sur la machine et qu'une nouvelle branche a été poussée sur GitHub depuis la dernière fois que des modifications ont été apportées localement.\n\n```bash\n# change into the `repo` directory\ncd repo\n\n# update all remote tracking branches, and the currently checked out branch\ngit pull\n\n# change into the existing branch called `feature-a`\ngit checkout feature-a\n\n# make changes, for example, edit `file1.md` using the text editor\n\n# stage the changed file\ngit add file1.md\n\n# take a snapshot of the staging area\ngit commit -m \"edit file1\"\n\n# push changes to github\ngit push\n```\n\n## Modèles de développement collaboratif\n\nIl existe deux façons principales de collaborer sur GitHub :\n\n1. Dépôt partagé\n2. Duplication (fork) et tirage (pull)\n\nAvec un dépôt partagé, les individus et les équipes sont explicitement désignés comme contributeurs avec un accès en lecture, en écriture ou administrateur. Cette structure de permission simple, associée à des fonctionnalités telles que les branches protégées, aide les équipes à progresser rapidement lorsqu'elles adoptent GitHub.\n\nPour un projet open source, ou pour des projets auxquels tout le monde peut contribuer, la gestion des autorisations individuelles peut être difficile, mais un modèle de forking et pull request permet à toute personne ayant accès au projet de contribuer. Un fork est une copie d’un projet sous le compte personnel d’un développeur. Chaque développeur dispose d’un contrôle total de sa duplication et est libre d’implémenter un correctif ou une nouvelle fonctionnalité. Le travail effectué dans les duplications est conservé séparément ou exposé dans le projet d’origine par le biais d’une demande de tirage. Là, les chargés de maintenance peuvent examiner les modifications suggérées avant leur fusion. Pour plus d’informations, consultez « [Contribution à un projet](/fr/get-started/exploring-projects-on-github/contributing-to-a-project) »."}