![\"xkcd](\"https://imgs.xkcd.com/comics/git.png\")
Les systèmes de contrôle de version (VCS) sont des outils utilisés pour suivre les modifications apportées au code source (ou à d'autres collections de fichiers et dossiers). Comme leur nom l'indique, ces outils aident à maintenir un historique des modifications ; de plus, ils facilitent la collaboration. Les VCS suivent les modifications apportées à un dossier et à son contenu dans une série d'instantanés, où chaque instantané encapsule l'état complet des fichiers/dossiers dans un répertoire de niveau supérieur. Les VCS maintiennent également des métadonnées comme qui a créé chaque instantané, les messages associés à chaque instantané, etc.
\n\nPourquoi le contrôle de version est-il utile ? Même lorsque vous travaillez seul, il peut vous permettre de consulter d'anciens instantanés d'un projet, de conserver un journal des raisons pour lesquelles certaines modifications ont été apportées, de travailler sur des branches de développement parallèles, et bien plus encore. Lorsque vous travaillez avec d'autres, c'est un outil inestimable pour voir ce que d'autres personnes ont modifié, ainsi que pour résoudre les conflits dans le développement concurrent.
\n\nLes VCS modernes vous permettent également de répondre facilement (et souvent automatiquement) à des questions telles que :
\n\nBien que d'autres VCS existent, Git est la norme de facto pour le contrôle de version. Cette bande dessinée XKCD capture la réputation de Git :
\n\n
Parce que l'interface de Git est une abstraction qui fuit, apprendre Git de haut en bas (en commençant par son interface / interface en ligne de commande) peut conduire à beaucoup de confusion. Il est possible de mémoriser une poignée de commandes et de les considérer comme des incantations magiques, et de suivre l'approche de la bande dessinée ci-dessus chaque fois que quelque chose ne va pas.
\n\nBien que Git ait certes une interface laide, sa conception et ses idées sous-jacentes sont belles. Alors qu'une interface laide doit être mémorisée, une belle conception peut être comprise. Pour cette raison, nous donnons une explication ascendante de Git, en commençant par son modèle de données et en couvrant ensuite l'interface en ligne de commande. Une fois le modèle de données compris, les commandes peuvent être mieux comprises en termes de la façon dont elles manipulent le modèle de données sous-jacent.
\n\nIl existe de nombreuses approches ad hoc que vous pourriez adopter pour le contrôle de version. Git a un modèle bien pensé qui permet toutes les belles fonctionnalités du contrôle de version, comme le maintien de l'historique, le support des branches et la collaboration.
\n\nGit modélise l'historique d'une collection de fichiers et de dossiers dans un répertoire de niveau supérieur comme une série d'instantanés. Dans la terminologie Git, un fichier est appelé un \"blob\", et c'est juste un tas d'octets. Un répertoire est appelé un \"tree\" (arbre), et il mappe des noms à des blobs ou des arbres (donc les répertoires peuvent contenir d'autres répertoires). Un instantané est l'arbre de niveau supérieur qui est suivi. Par exemple, nous pourrions avoir un arbre comme suit :
\n\n<root> (tree)\n|\n+- foo (tree)\n| |\n| + bar.txt (blob, contents = \"hello world\")\n|\n+- baz.txt (blob, contents = \"git is wonderful\")\nL'arbre de niveau supérieur contient deux éléments, un arbre \"foo\" (qui contient lui-même un élément, un blob \"bar.txt\"), et un blob \"baz.txt\".
\n\nComment un système de contrôle de version devrait-il relier les instantanés ? Un modèle simple serait d'avoir un historique linéaire. Un historique serait une liste d'instantanés dans l'ordre chronologique. Pour de nombreuses raisons, Git n'utilise pas un modèle simple comme celui-ci.
\n\nDans Git, un historique est un graphe acyclique orienté (DAG) d'instantanés. Cela peut sembler être un mot mathématique sophistiqué, mais ne soyez pas intimidé. Tout cela signifie que chaque instantané dans Git fait référence à un ensemble de \"parents\", les instantanés qui l'ont précédé. C'est un ensemble de parents plutôt qu'un seul parent (comme ce serait le cas dans un historique linéaire) car un instantané peut descendre de plusieurs parents, par exemple, en raison de la combinaison (fusion) de deux branches parallèles de développement.
\n\nGit appelle ces instantanés des \"commit\"s. La visualisation d'un historique de commits pourrait ressembler à ceci :
\n\no <-- o <-- o <-- o\n ^\n \\\n --- o <-- o\nDans l'art ASCII ci-dessus, les os correspondent à des commits individuels (instantanés). Les flèches pointent vers le parent de chaque commit (c'est une relation \"vient avant\", pas \"vient après\"). Après le troisième commit, l'historique se divise en deux branches distinctes. Cela pourrait correspondre, par exemple, à deux fonctionnalités distinctes développées en parallèle, indépendamment l'une de l'autre. À l'avenir, ces branches peuvent être fusionnées pour créer un nouvel instantané qui incorpore les deux fonctionnalités, produisant un nouvel historique qui ressemble à ceci, avec le commit de fusion nouvellement créé affiché en gras :
\n\no <-- o <-- o <-- o <---- o\n ^ /\n \\ v\n --- o <-- o\n\n\n\nLes commits dans Git sont immuables. Cela ne signifie pas que les erreurs ne peuvent pas être corrigées, cependant ; c'est juste que les \"modifications\" de l'historique des commits créent en fait des commits entièrement nouveaux, et les références (voir ci-dessous) sont mises à jour pour pointer vers les nouveaux.
\n\nIl peut être instructif de voir le modèle de données de Git écrit en pseudocode :
\n\n// un fichier est un tas d'octets\ntype blob = array<byte>\n\n// un répertoire contient des fichiers et des répertoires nommés\ntype tree = map<string, tree | blob>\n\n// un commit a des parents, des métadonnées et l'arbre de niveau supérieur\ntype commit = struct {\n parents: array<commit>\n author: string\n message: string\n snapshot: tree\n}\nC'est un modèle d'historique propre et simple.
\n\nUn \"objet\" est un blob, un arbre ou un commit :
\n\ntype object = blob | tree | commit\nDans le magasin de données Git, tous les objets sont adressés par contenu par leur hachage SHA-1.
\n\nobjects = map<string, object>\n\ndef store(object):\n id = sha1(object)\n objects[id] = object\n\ndef load(id):\n return objects[id]\nLes blobs, les arbres et les commits sont unifiés de cette manière : ce sont tous des objets. Lorsqu'ils font référence à d'autres objets, ils ne les contiennent pas réellement dans leur représentation sur disque, mais ont une référence à eux par leur hachage.
\n\nPar exemple, l'arbre pour la structure de répertoire d'exemple ci-dessus (visualisé en utilisant git cat-file -p 698281bc680d1995c5f4caaf3359721a5a58d48d), ressemble à ceci :
100644 blob 4448adbf7ecd394f42ae135bbeed9676e894af85 baz.txt\n040000 tree c68d233a33c5c06e0340e4c224f0afca87c8ce87 foo\nL'arbre lui-même contient des pointeurs vers son contenu, baz.txt (un blob) et foo (un arbre). Si nous regardons le contenu adressé par le hachage correspondant à baz.txt avec git cat-file -p 4448adbf7ecd394f42ae135bbeed9676e894af85, nous obtenons ce qui suit :
git is wonderful\nMaintenant, tous les instantanés peuvent être identifiés par leurs hachages SHA-1. C'est peu pratique, car les humains ne sont pas doués pour se souvenir de chaînes de 40 caractères hexadécimaux.
\n\nLa solution de Git à ce problème est des noms lisibles par l'homme pour les hachages SHA-1, appelés \"références\". Les références sont des pointeurs vers des commits. Contrairement aux objets, qui sont immuables, les références sont mutables (peuvent être mises à jour pour pointer vers un nouveau commit). Par exemple, la référence master pointe généralement vers le dernier commit dans la branche principale de développement.
references = map<string, string>\n\ndef update_reference(name, id):\n references[name] = id\n\ndef read_reference(name):\n return references[name]\n\ndef load_reference(name_or_id):\n if name_or_id in references:\n return load(references[name_or_id])\n else:\n return load(name_or_id)\nAvec cela, Git peut utiliser des noms lisibles par l'homme comme \"master\" pour faire référence à un instantané particulier dans l'historique, au lieu d'une longue chaîne hexadécimale.
\n\nUn détail est que nous voulons souvent une notion de \"où nous sommes actuellement\" dans l'historique, de sorte que lorsque nous prenons un nouvel instantané, nous savons ce qu'il est par rapport à (comment nous définissons le champ parents du commit). Dans Git, ce \"où nous sommes actuellement\" est une référence spéciale appelée \"HEAD\".
Enfin, nous pouvons définir ce qu'est (approximativement) un dépôt Git : ce sont les données objects et references.
Sur le disque, tout ce que Git stocke sont des objets et des références : c'est tout ce qu'il y a dans le modèle de données de Git. Toutes les commandes git correspondent à une manipulation du DAG de commits en ajoutant des objets et en ajoutant/mettant à jour des références.
Chaque fois que vous tapez une commande, pensez à quelle manipulation la commande effectue sur la structure de données graphique sous-jacente. Inversement, si vous essayez d'apporter un type particulier de modification au DAG de commits, par exemple \"annuler les modifications non validées et faire pointer la référence 'master' vers le commit 5d83f9e\", il y a probablement une commande pour le faire (par exemple dans ce cas, git checkout master; git reset --hard 5d83f9e).
C'est un autre concept qui est orthogonal au modèle de données, mais c'est une partie de l'interface pour créer des commits.
\n\nUne façon dont vous pourriez imaginer implémenter la prise d'instantanés comme décrit ci-dessus serait d'avoir une commande \"créer un instantané\" qui crée un nouvel instantané basé sur l'état actuel du répertoire de travail. Certains outils de contrôle de version fonctionnent comme cela, mais pas Git. Nous voulons des instantanés propres, et il n'est peut-être pas toujours idéal de créer un instantané à partir de l'état actuel. Par exemple, imaginez un scénario où vous avez implémenté deux fonctionnalités distinctes, et vous voulez créer deux commits distincts, où le premier introduit la première fonctionnalité, et le suivant introduit la deuxième fonctionnalité. Ou imaginez un scénario où vous avez des instructions d'impression de débogage ajoutées partout dans votre code, ainsi qu'une correction de bug ; vous voulez valider la correction de bug tout en supprimant toutes les instructions d'impression.
\n\nGit s'adapte à de tels scénarios en vous permettant de spécifier quelles modifications doivent être incluses dans le prochain instantané grâce à un mécanisme appelé la \"zone de staging\".
\n\nPour éviter de dupliquer les informations, nous n'allons pas expliquer les commandes ci-dessous en détail. Consultez le très recommandé Pro Git pour plus d'informations.
\n\nLa commande git init initialise un nouveau dépôt Git, avec les métadonnées du dépôt stockées dans le répertoire .git :
$ mkdir myproject\n$ cd myproject\n$ git init\nInitialized empty Git repository in .git\n$ git status\nOn branch master\nNo commits yet\nnothing to commit (create/copy files and use \"git add\" to track)\nComment interpréter cette sortie ? \"No commits yet\" signifie essentiellement que notre historique de version est vide. Corrigeons cela.
\n\n$ echo \"hello, git\" > hello.txt\n$ git add hello.txt\n$ git status\nOn branch master\nNo commits yet\nChanges to be committed:\n (use \"git rm --cached <file>...\" to unstage)\n new file: hello.txt\n$ git commit -m 'Initial commit'\n[master (root-commit) 4515d17] Initial commit\n 1 file changed, 1 insertion(+)\n create mode 100644 hello.txt\nAvec cela, nous avons ajouté un fichier à la zone de staging avec git add, puis validé ce changement avec git commit, en ajoutant un simple message de commit \"Initial commit\". Si nous ne spécifions pas d'option -m, Git ouvrirait notre éditeur de texte pour nous permettre de taper un message de commit.
Maintenant que nous avons un historique de version non vide, nous pouvons visualiser l'historique. Visualiser l'historique comme un DAG peut être particulièrement utile pour comprendre l'état actuel du dépôt et le connecter avec votre compréhension du modèle de données Git.
\n\nLa commande git log visualise l'historique. Par défaut, elle affiche une version aplatie, qui cache la structure du graphe. Si vous utilisez une commande comme git log --all --graph --decorate, elle vous montrera l'historique complet du dépôt, visualisé sous forme de graphe.
$ git log --all --graph --decorate\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa (HEAD -> master)\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nCela ne ressemble pas vraiment à un graphe, car il ne contient qu'un seul nœud. Faisons quelques modifications supplémentaires, créons un nouveau commit et visualisons à nouveau l'historique.
\n\n$ echo \"another line\" >> hello.txt\n$ git status\nOn branch master\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git checkout -- <file>...\" to discard changes in working directory)\n modified: hello.txt\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git add hello.txt\n$ git status\nOn branch master\nChanges to be committed:\n (use \"git reset HEAD <file>...\" to unstage)\n modified: hello.txt\n$ git commit -m 'Add a line'\n[master 35f60a8] Add a line\n 1 file changed, 1 insertion(+)\nMaintenant, si nous visualisons à nouveau l'historique, nous verrons une partie de la structure du graphe :
\n\n* commit 35f60a825be0106036dd2fbc7657598eb7b04c67 (HEAD -> master)\n| Author: Subramanya N <subramanyanagabhushan@gmail.com>\n| Date: Tue Dec 21 22:26:20 2020 -0500\n| Add a line\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nNotez également qu'il affiche le HEAD actuel, ainsi que la branche actuelle (master).
\n\nNous pouvons consulter les anciennes versions en utilisant la commande git checkout.
$ git checkout 4515d17 # hachage du commit précédent ; le vôtre sera différent\nNote: checking out '4515d17'.\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by performing another checkout.\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -b with the checkout command again. Example:\n git checkout -b <new-branch-name>\nHEAD is now at 4515d17 Initial commit\n$ cat hello.txt\nhello, git\n$ git checkout master\nPrevious HEAD position was 4515d17 Initial commit\nSwitched to branch 'master'\n$ cat hello.txt\nhello, git\nanother line\nGit peut vous montrer comment les fichiers ont évolué (différences, ou diffs) en utilisant la commande git diff :
$ git diff 4515d17 hello.txt\ndiff --git c/hello.txt w/hello.txt\nindex 94bab17..f0013b2 100644\n--- c/hello.txt\n+++ w/hello.txt\n@@ -1 +1,2 @@\n hello, git\n +another line\ngit help <command> : obtenir de l'aide pour une commande gitgit init : crée un nouveau dépôt git, avec les données stockées dans le répertoire .gitgit status : vous indique ce qui se passegit add <filename> : ajoute des fichiers à la zone de staginggit commit : crée un nouveau commit\ngit log : affiche un journal aplati de l'historiquegit log --all --graph --decorate : visualise l'historique comme un DAGgit diff <filename> : affiche les modifications que vous avez apportées par rapport à la zone de staginggit diff <revision> <filename> : affiche les différences dans un fichier entre les instantanésgit checkout <revision> : met à jour HEAD et la branche actuelleLe branchement vous permet de \"bifurquer\" l'historique des versions. Il peut être utile pour travailler sur des fonctionnalités ou des corrections de bugs indépendantes en parallèle. La commande git branch peut être utilisée pour créer de nouvelles branches ; git checkout -b <branch name> crée une branche et y bascule.
La fusion est l'opposé du branchement : elle vous permet de combiner des historiques de versions bifurqués, par exemple, fusionner une branche de fonctionnalité dans master. La commande git merge est utilisée pour la fusion.
git branch : affiche les branchesgit branch <name> : crée une branchegit checkout -b <name> : crée une branche et y bascule\ngit branch <name>; git checkout <name>git merge <revision> : fusionne dans la branche actuellegit mergetool : utilise un outil sophistiqué pour aider à résoudre les conflits de fusiongit rebase : rebase un ensemble de correctifs sur une nouvelle basegit remote : liste les dépôts distantsgit remote add <name> <url> : ajoute un dépôt distantgit push <remote> <local branch>:<remote branch> : envoie des objets au dépôt distant et met à jour la référence distantegit branch --set-upstream-to=<remote>/<remote branch> : établit la correspondance entre la branche locale et la branche distantegit fetch : récupère les objets/références d'un dépôt distantgit pull : identique à git fetch; git mergegit clone : télécharge le dépôt depuis un dépôt distantgit commit --amend : modifie le contenu/message d'un commitgit reset HEAD <file> : retire un fichier de la zone de staginggit checkout -- <file> : annule les modificationsgit config : Git est hautement personnalisablegit clone --depth=1 : clone superficiel, sans l'historique complet des versionsgit add -p : staging interactifgit rebase -i : rebasing interactifgit blame : affiche qui a modifié quelle ligne en derniergit stash : supprime temporairement les modifications du répertoire de travailgit bisect : recherche binaire dans l'historique (par exemple pour les régressions).gitignore : spécifie les fichiers intentionnellement non suivis à ignorer