Comment utiliser les branches Git pour structurer votre projet de programmation

Les films et la télévision décrivent la programmation comme une activité frénétique Hollywood Hacks: le meilleur et le pire piratage dans les films Hollywood Hacks: le meilleur et le pire Le piratage dans le cinéma Hollywood et le piratage ne font pas bon ménage. Bien que le piratage dans la vie réelle soit difficile, le piratage de film consiste souvent à cogner sur un clavier, comme si vos doigts se démodaient. Lire la suite . Le compte à rebours d’une bombe compte, et l’accompagnateur ringard qui était jusqu’à présent un fardeau travaille fiévreusement sur un ordinateur portable. Le code traverse l'écran jusqu'à ce que la touche de retour final soit frappée avec un résultat satisfaisant. claquement! La minuterie s'arrête et tout est à nouveau dans le monde. Mais la programmation n’a rien de tel. 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 débutant (comme moi).

Maintenant, vous êtes peut-être déjà convaincu de l'intérêt de conserver vos projets de codage dans le contrôle de source. Qu'est-ce que Git & Pourquoi utiliser le contrôle de version si vous êtes développeur? Qu'est-ce que Git & Pourquoi utiliser le contrôle de version si vous êtes développeur? En tant que développeurs Web, nous avons souvent tendance à travailler sur des sites de développement locaux, puis il nous suffit de tout télécharger lorsque nous avons terminé. C'est bien quand c'est juste vous et que les changements sont petits,… Lire la suite. La validation de tous ces essais et erreurs dans votre référentiel donnera lieu à un projet volumineux et désordonné, comportant de nombreuses révisions. La plupart des commits que vous effectuez contiendront des éléments brisés, alors pourquoi les sauvegarder? Le git branche fonctionnalité peut aider à garder tout ce code en désordre loin de la substance que vous savez fonctionne.

Dans cet article, nous verrons ce que signifie votre code de branchement, comment le faire et comment gérer les mises à jour du “principale” branche.

Créer une branche Git

Nous avons appris de notre introduction au contrôle de source Gérer votre version de fichiers comme un programmeur avec Git Gérer votre version de fichier comme un programmeur avec Git Les programmeurs ont créé des systèmes de contrôle de version (VCS) pour résoudre les problèmes de contrôle de version de fichier. Regardons les bases du contrôle de version utilisant le système le plus performant d’aujourd’hui, Git. Lisez-en plus sur le fait 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 le voyez pas, consultez certains de nos articles précédents sur l'affichage masqué. La méthode la plus simple pour afficher les fichiers et dossiers cachés dans Windows 10, 8.1 et 7 La méthode simple pour afficher les fichiers et les dossiers cachés dans Windows 10, 8.1 et 7 Besoin de voir les fichiers et dossiers cachés sous Windows? Voici comment les afficher dans Windows 10, 8.1 et 7 afin que rien ne vous soit caché. Lire plus de fichiers Masquer et rechercher tous les fichiers sous Mac OS X Masquer et rechercher tous les fichiers sous Mac OS X Il n’existe aucun moyen simple de masquer ou de révéler rapidement les fichiers cachés sous Mac OS X comme il existe sous Windows - mais c’est possible. Lire la suite . 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 afficher un certain nombre de sous-répertoires. L'un d'eux s'appelle “refs” (montré dans l'image ci-dessous), et son “les têtes” Le sous-répertoire contient les listes de toutes les branches de votre projet. Au début, vous n’en aurez qu’un, surnommé “maîtriser.”

Le répertoire refs conserve un enregistrement de la branche, mais pas la branche elle-même. Du moins, pas la branche tu es utilisant actuellement. Ces fichiers sont conservés dans le répertoire de travail (“~ / Temp / post-programmation-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é “premier-fichier.txt”) dans le répertoire de travail, c.-à-d.. à l'extérieur le répertoire .git. Cochez cette option en utilisant les commandes fiables de l’introduction précédente à l’article Git. Gérez votre versioning de fichier comme un programmeur avec Git Gérez votre versioning de fichier comme un programmeur avec Git Les programmeurs ont créé des systèmes de contrôle de version (VCS) pour résoudre les problèmes de contrôle de version de fichier. Regardons les bases du contrôle de version utilisant le système le plus performant d’aujourd’hui, Git. Lire la suite :

Nous pouvons voir maintenant que le répertoire de travail a deux fichiers, celui que nous avons validé et l'autre créé automatiquement par git (il contient le message de validation que nous venons d'entrer).

Maintenant, créons une nouvelle branche git appelée “essai”:

test de branche git

Vérifier la succursale et y travailler

Nous pouvons émettre la commande ci-dessus sans nom afin d’obtenir une liste de toutes les branches, ainsi que celle que nous utilisons actuellement (c’est-à-dire “vérifié”):

Maintenant, si nous examinons la structure de répertoires, nous verrons “.git / refs / têtes” a maintenant deux fichiers, un pour “maîtriser” et “essai.”

Chacun de ceux-ci est une liste des commits qui composent la branche. Par exemple, si nous examinons les “maîtriser” branche avec le “journal git” commande, on peut voir une ligne pour chacun des commits faits à cette branche.

Le processus de “check out” une branche signifie que les modifications que vous apportez aux fichiers feront partie de cette branche, mais pas d'autres branches. Par exemple, supposons que nous vérifions la branche testing git avec la commande suivante:

test de caisse git

Ensuite, nous ajoutons une ligne de texte à first-file.txt, bien sûr, nous le commettons par la suite. Si vous revenez à la branche principale, vous constaterez que le fichier est toujours vide (le chat commande affiche le contenu d'un fichier dans le terminal):

Mais revenant à la “essai” branche, le fichier a toujours le texte ajouté:

Mais tout ce que nous voyons dans le répertoire est le fichier unique “premier-fichier.txt.” Où sont alors ces deux versions alternatives du même fichier? Le répertoire .git prend en compte ces modifications, mais pas de la manière habituelle..

Comment Git stocke les choses

Si vous examiniez 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. 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 réellement “svn copy” en tant que commande pour créer une branche dans Subversion! D'autre part, git opère sur le concept de “changements.”

La sortie de ce qui précède nous dit tout le contenu de “tronc” (Version de SVN de “maîtriser”) a été copié. Un coup d'oeil dans un gestionnaire de fichiers le confirme:

le “.git / objets” répertoire est ce qui contient toutes ces petites modifications, et chacune est suivie avec un identifiant. Par exemple, dans l'image ci-dessous, vous verrez des fichiers avec des noms de style ID longs. Chacun réside dans un dossier nommé avec deux caractères hexadécimaux (8c et 8d au dessous de).

Ensemble, ces noms de dossier et de fichier constituent l'ID d'une modification particulière (en fait, un hachage SHA1). Vous pouvez explorer leur contenu en utilisant le git cat-file commander. Basé sur leurs dates modifiées, nous pouvons voir celui qui commence “8d” est venu en premier, et ça ne montre rien. Alors que celui qui commence “8c” contient la ligne de texte que nous avons ajoutée au fichier dans le “essai” branche.

La conclusion est que les branches de git (y compris la valeur par défaut) “maîtriser”) ne sont pas séparés “Dossiers” contenant des copies de fichiers. Ce sont plutôt des 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 (pause?) Dans une branche git y reste jusqu'à ce que vous la fusionniez.

Stratégies de fusion pour revenir à la branche principale (supprimer ou ne pas supprimer?)

Supposons que vous ayez un projet existant avec un certain nombre de fichiers, que vous avez ensuite branché dans “essai,” et fait quelques travaux sur elle. Maintenant, vous voulez que ces changements reviennent dans le “maîtriser” branche. Vous pouvez faire avec ce qui suit de la “maîtriser” branche:

test de fusion git

Pourvu qu'il n'y ait pas de conflits, le changement composé du nouveau texte sera appliqué à “maîtriser.” Le résultat est “premier-fichier.txt” sera identique dans les deux branches. Pourtant, il n'y avait jamais vraiment alterner les versions du dossier.

Vient maintenant la question, que faire avec la branche? Il existe deux stratégies communes pour traiter avec les branches.

1. On est de garder une branche de git comme “essai” jouer (voir ci-dessus). Vous essayez certaines choses et, si vous pouvez les faire fonctionner, fusionnez les modifications dans “maîtriser.” Ensuite, vous pouvez arrêter de travailler sur cette branche ou même vous en débarrasser complètement. Cela signifie que votre “maîtriser” est la version la plus stable du code, car il ne devrait contenir que des éléments que vous savez travailler. Vous pouvez aussi penser à cette approche en utilisant “branches caractéristiques.” C’est parce que leur but est d’affiner un (ou plusieurs) ajouts spécifiques au code.
2. Une approche différente consiste à effectuer tout votre travail principal dans “maîtriser” branche, faisant commet le long du chemin. Une fois que vous êtes satisfait de la fonctionnalité, vous créez une branche dans laquelle vous allez réparer les bogues, etc. Cela se traduit par plus d'un “branche de libération” (ci-dessous), à la fin de la publication. Cela signifie aussi que votre “maîtriser” branche est généralement la version la plus instable de votre code.

Utilisez la méthode qui vous convient le mieux

La première approche est plus courante lorsque vous travaillez avec git. Ses autres fonctionnalités (notamment les balises) permettent de marquer facilement un instantané particulier du code. “stable.” Il se prête également mieux à des projets plus vastes et collaboratifs. Mais lorsque vous travaillez sur vos propres projets personnels, n'hésitez pas à utiliser celui qui vous convient le mieux. L'avantage de l'utilisation de git est que vous capturez tous vos changements, de sorte que vous pouvez toujours revenir en arrière et trouver quelque chose. Et organiser votre projet avec les 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 jeter après? 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 traiter les branches dans vos projets git!