Les films et la télévision décrivent la programmation comme une activité frénétique. Le minuteur d'une bombe compte à rebours, et l'acolyte ringard qui était un fardeau jusque-là travaille fébrilement sur un ordinateur portable. Le code vole sur l'écran jusqu'à ce qu'elle appuie sur la dernière touche de retour avec un clac satisfaisant ! Le chronomètre s'arrête, et tout va bien dans le monde à nouveau. Mais la programmation n'a rien à voir avec ça. Il comprend des documents de conception, des maquettes d'interface utilisateur et des révisions de code. Et plus que tout, cela implique des essais et des erreurs, surtout si vous êtes un débutant (comme moi).
Maintenant, vous êtes peut-être déjà convaincu de l'intérêt de conserver vos projets de codage sous contrôle de code source. Commettre tous ces essais et erreurs dans votre référentiel créera un projet volumineux et désordonné, avec de nombreuses révisions. La plupart des commits que vous faites contiendront des éléments cassés, alors pourquoi les sauvegarder ? La branche git peut aider à éloigner tout ce code désordonné de tout ce dont vous savez qu'il fonctionne.
Dans cet article, nous verrons ce que signifie créer une branche dans votre code, comment procéder et comment gérer les mises à jour de la branche "principale".
Nous avons appris de notre introduction au contrôle de code source que vous pouvez créer un nouveau référentiel avec la commande suivante dans un terminal :
git init
Lorsque vous faites cela, il crée un répertoire caché dans votre chemin actuel, appelé ".git". Si vous ne pouvez pas le voir, consultez certains de nos articles précédents sur l'affichage des fichiers cachés. Ce répertoire contient toutes les informations nécessaires pour conserver l'historique de révision de vos fichiers. Une fois que vous avez configuré votre gestionnaire de fichiers pour afficher les fichiers cachés, vous pouvez ouvrir le dossier .git et voir un certain nombre de sous-répertoires. L'un d'eux s'appelle "refs " (montré dans l'image ci-dessous), et ses "têtes Le sous-répertoire " contient les listes de toutes les branches de votre projet. Au départ, vous n'en aurez qu'une, appelée "maître".
Le répertoire refs conserve un enregistrement de la branche, mais pas de la branche elle-même. Du moins, pas la branche que vous utilisez actuellement . Ces fichiers sont conservés dans le répertoire de travail ("~/Temp/post-programming-git-branch" dans l'exemple ci-dessus) afin que vous puissiez y accéder de manière normale. En faisant exactement cela, nous créons notre premier fichier (nommé "first-file.txt") dans le répertoire de travail, c'est-à-dire à l'extérieur le répertoire .git. Vérifiez ceci en utilisant les commandes de confiance de l'introduction précédente à l'article git :
Nous pouvons voir maintenant que le répertoire de travail a deux fichiers, celui que nous avons validé et un créé automatiquement par git (il contient le message de validation que nous venons de saisir).
Maintenant, créons une nouvelle branche git appelée "testing":
test de branche git
Nous pouvons émettre la commande ci-dessus sans aucun nom afin d'obtenir une liste de toutes les branches, ainsi que celle que nous utilisons actuellement (c'est-à-dire celle qui est "extraite") :
Maintenant, si nous examinons la structure du répertoire, nous verrons ".git/refs/heads " a maintenant deux fichiers, un pour "master" et un pour "testing".
Chacun d'eux est une liste des commits qui composent la branche. Par exemple, si nous examinons la branche "master" avec le "git log ", nous pouvons voir une ligne pour chacun des commits effectués sur cette branche.
Le processus d'"extraction" d'une branche signifie que les modifications que vous apportez aux fichiers feront partie de cette branche, mais pas des autres branches. Par exemple, supposons que nous vérifions la branche testing git avec la commande suivante :
test de paiement git
Ensuite, nous ajoutons une ligne de texte à first-file.txt, bien sûr en la validant par la suite. Si vous revenez à la branche master, vous constaterez que le fichier est toujours vide (le cat commande affiche le contenu d'un fichier dans le terminal) :
Mais en revenant à la branche "testing", le fichier contient toujours le texte ajouté :
Mais tout ce que nous voyons dans le répertoire proprement dit est le fichier unique "first-file.txt". Où sont donc ces deux versions alternatives du même fichier ? Le répertoire .git tient compte de ces changements, mais pas de la manière à laquelle vous pourriez vous attendre.
Si vous deviez examiner un référentiel pour d'autres systèmes de contrôle de version tels que Subversion, vous constateriez qu'ils conservent une copie par révision pour chaque fichier individuel. Cela signifie que si vous avez un référentiel d'un fichier, puis créez deux branches, le référentiel contient deux copies différentes de ce fichier. En fait, vous utilisez en fait « svn copy » comme commande pour créer une branche dans Subversion ! D'un autre côté, git fonctionne sur le concept de "changements".
La sortie de ce qui précède nous indique que tout le contenu de "trunk" (la version SVN de "master") a été copié. Un coup d'oeil dans un gestionnaire de fichiers le confirme :
Le ".git/objects " est ce qui contient tous ces petits changements, et chacun est suivi avec un ID. Par exemple, dans l'image ci-dessous, vous verrez des fichiers avec des noms longs de style ID. Chacun réside dans un dossier nommé avec deux caractères hexadécimaux ( 8c et 8d ci-dessous).
Ensemble, ces noms de dossier et de fichier constituent l'ID d'un changement particulier (en fait un hachage SHA1). Vous pouvez explorer leur contenu en utilisant le git cat-file commander. Sur la base de leurs dates modifiées, nous pouvons voir que celle commençant par "8d" est arrivée en premier, et cela ne montre rien. Alors que celui commençant par "8c" contient la ligne de texte que nous avons ajoutée au fichier dans la branche "testing".
Le point à retenir est que les branches git (y compris le "maître" par défaut) ne sont pas des "dossiers" séparés contenant des copies de fichiers. Il s'agit plutôt de listes de modifications apportées aux fichiers au fil du temps. C'est plus efficace en termes de stockage, mais le résultat est le même. Tout ce que vous faites (cassez ?) dans une branche git y reste jusqu'à ce que vous la fusionniez.
Supposons que vous ayez un projet existant avec un certain nombre de fichiers, que vous avez ensuite ramifié en "testing" et que vous avez travaillé dessus. Maintenant, vous voulez récupérer ces modifications dans la branche "master". Vous pouvez faire ce qui suit depuis la branche "master":
test de fusion git
S'il n'y a pas de conflits, le changement composé du nouveau texte sera appliqué maîtriser." Le résultat est "first-file.txt" sera identique dans les deux branches. Pourtant, il n'y a jamais vraiment eu de versions alternatives du fichier.
Vient maintenant la question, que faire de la branche ? Il existe deux stratégies courantes pour traiter avec les succursales.
La première approche ici est plus courante lorsque vous travaillez avec git. Ses autres fonctionnalités (en particulier les balises) permettent de marquer facilement un instantané particulier du code comme "stable". Il se prête également mieux aux grands projets collaboratifs. Mais lorsque vous travaillez sur vos propres projets personnels, n'hésitez pas à utiliser celui qui vous convient le mieux. L'avantage d'utiliser git est que vous capturez toutes vos modifications, vous pouvez donc toujours revenir en arrière et trouver quelque chose. Et organiser votre projet avec des branches git rend cela un peu plus facile à faire.
Comment abordez-vous les branches dans vos projets ? Les utilisez-vous pour expérimenter, puis les jetez-vous ensuite ? Ou représentent-ils un historique détaillé de votre travail sur le projet ?
Faites-nous savoir ci-dessous dans les commentaires si vous avez des moyens astucieux de gérer les branches dans vos projets git !
