Dans nos précédents tutoriels pour le logiciel de contrôle de version git, nous avons appris les commandes de base essentielles pour utiliser git, comme ainsi que comment travailler avec Github.com pour établir un référentiel et pousser le code de notre projet sur le site Web.
Il est maintenant temps de commencer à travailler avec GitHub (et git) comme ils sont censés être utilisé: apporter des modifications au projet en toute sécurité d’un côté et les fusionner dans le projet d’origine une fois qu’elles se sont avérées correctes. Ou du moins pas désastreux.
À présent, vous comprenez que git enregistre chaque version de votre projet comme un instantané du code exactement tel qu’il était au moment où vous l’avez validé. Essentiellement, créer une chronologie des versions d’un projet au fur et à mesure de sa progression, afin que vous puissiez revenir à une version antérieure en cas de catastrophe.
La façon dont git et GitHub gèrent cette chronologie – en particulier lorsque plus plus d’une personne travaille dans le projet et apporte des changements – c’est en utilisant des branches. Une branche est essentiellement un ensemble unique de modifications de code avec un nom unique. Chaque référentiel peut avoir une ou plusieurs branches. La branche principale – celle dans laquelle tous les changements sont finalement fusionnés et est appelée master. Ceci est la version officielle de travail de votre projet, et celle que vous voyez lorsque vous visitez le référentiel du projet à l’adresse github.com/yourname/projectname.
Ne plaisantez pas avec le maître. Si vous apportez des modifications à la branche principale d’un projet de groupe alors que d’autres personnes y travaillent également, vos modifications à la volée se répercuteront sur tout le monde et très rapidement il y aura des conflits de fusion, des pleurs, des déchirures de vêtements, et les invasions de sauterelles. C’est si grave.
Pourquoi est-il si important de ne pas jouer avec le maître? Un mot: la branche maître est déployable. C’est votre code de production, prêt à être déployé dans le monde. La branche master est censée être stable, et c’est le contrat social du logiciel open source de ne jamais, jamais pousser quoi que ce soit à maîtriser qui ne soit pas testé ou qui brise la construction. La raison pour laquelle GitHub fonctionne est qu’il est toujours sûr de travailler à partir du maître.
Branchement
Au lieu de cela, tout le monde utilise des branches créées du maître à l’expérimentation, apporte des modifications, des ajouts et des modifications , avant de réintroduire cette branche dans le maître une fois qu’elle a été approuvée et est connue pour fonctionner. Master est ensuite mis à jour pour contenir tous les nouveaux éléments.
Pour commencer à travailler sur quelque chose de nouveau dans un projet, ou pour changer des éléments existants, vous créez une branche hors de la branche master stable. Continuons à travailler avec l’exemple de projet créé pour notre précédent didacticiel, le bon vieux studious_octo_carnival. Veuillez maintenant ouvrir votre version sur votre ordinateur et le CD dans le répertoire.
Étape 1: Faites l’inventaire.
Avant de créer de nouvelles branches, nous voulons vérifier les autres branches existantes . Nous connaissons le maître, mais qui sait ce que peuvent faire nos collaborateurs de projet, ces singes espiègles? Nous pouvons donc afficher toutes les branches existantes en tapant « git branch -a » dans le terminal, ce qui indique à git que nous voulons voir TOUTES les branches de ce projet, même celles qui ne sont pas dans notre espace de travail local.
Cela renvoie la sortie que vous voyez dans l’exemple de code ci-dessous. Son apparence peut varier quelque peu en fonction de votre système d’exploitation et de votre application de terminal, mais les informations sont finalement les mêmes. L’astérisque à côté de « maître » dans la première ligne de la sortie indique que nous sommes actuellement sur cette branche. La deuxième ligne nous dit que sur notre télécommande, nommée origine, il y a une seule branche, également appelée master. (N’oubliez pas que notre télécommande est le dépôt GitHub pour ce projet).
Étape 2: Créer une nouvelle branche
Maintenant que nous savons comment afficher les branches, créons-en une! Gardez à l’esprit que nous avons notre branche principale, notre projet d’origine. Nous allons maintenant créer une nouvelle version du projet, une branche, pour jouer et apporter des modifications localement sur notre ordinateur – tandis que la version originale du projet, le maître, reste en toute sécurité sans encombre sur GitHub. Nous donnons à la nouvelle branche un nom descriptif pour nous rappeler ce que nous avons l’intention de faire en y travaillant. Dans ce cas, ce sera un simple truc « Hello World », alors appelons-le hello_octo.
Pour créer cette nouvelle branche, tapez « git checkout -b branchNameHere » (donc, dans notre cas, « git checkout -b hello_octo »).
En supposant que personne d’autre n’ait déjà créé une branche nommée « hello_octo », git renvoie « Switched to a new branch ‘hello_octo’. » (Dans le cas où une branche de ce nom existe déjà, git nous dirait à la place « fatal: Une branche nommée ‘hello_octo’ existe déjà. » Pas de problème, refaites simplement git checkout -b avec une nouvelle variation de nom).
Nous pouvons également utiliser la commande git checkout pour basculer entre nos deux branches. Tapez « git checkout branchName » pour basculer vers cette branche.Ainsi, « git checkout master » vous amène au master tandis que « git checkout hello_octo » vous ramène à la branche hello_octo.
Si vous essayez de basculer vers une branche qui n’existe pas, telle que « git checkout hello_kitty », git vous fera savoir que c’est interdit:
Comment git sait-il sur quelle branche vous êtes actuellement? Git surveille toujours ce que vous faites et garde un pointeur spécial appelé HEAD. Comme l’aiguille d’une boussole pointe toujours vers le nord, HEAD indique toujours le branche locale sur laquelle vous êtes actuellement.
(Nous aurions pu aussi créer notre branche en utilisant la commande git « git branch branchNameHere », puis y basculer avec git checkout. Cependant, le petit raccourci avec le « -b » dans « git checkout -b branchNameHere » crée à la fois la branche ET y bascule. Je ne peux pas vous dire combien de nouveaux codeurs git génèrent des messages d’erreur et de la frustration parce qu’ils n’ont tout simplement pas pensé à passer à leur nouvelle branche après avoir créé je t. Par conséquent, nous nous en tenons à git checkout -b, mmmkay?)
Apporter des modifications à notre branche de travail
Maintenant que nous avons plusieurs branches – notre branche de travail sur laquelle apporter des modifications, et notre branche principale reste sans encombre – nous pouvons nous mettre au travail. Dans notre scénario, nous allons utiliser notre branche « hello_octo » pour effectuer et tester nos modifications, puis les repousser vers la branche principale sur GitHub.
N’oubliez pas de vous assurer que vous êtes sur votre branche de travail, et non master, avec la bonne vieille branche git -a.
Étape 3. Créez un nouveau fichier vide, nommé « hello_octo_world »:
(Ce fichier vierge est juste à des fins de démonstration, donc ne vous inquiétez pas qu’il n’y ait pas de nom / type d’extension de fichier).
Comme il est tout neuf, à droite maintenant ce fichier est uniquement sur votre branche. Utilisez la commande « ls » pour l’afficher:
Cependant, rappelez-vous que nous sommes sur notre branche de travail, hello_octo, où nous avons créé cette nouvelle chose. Le maître ne sait rien de no hello_octo, car il est isolé en toute sécurité de tout changement bon gré mal gré que nous apportons ici sur la branche de travail. C’est toujours le même maître sereinement inchangé avec lequel nous avons commencé:
Étape 4: Mettre en scène et valider notre nouveau fichier dans la branche de travail.
Il est maintenant temps pour mettre en scène (ajouter) et valider notre nouveau fichier sur la branche de travail. (Cela vous semble familier?). Cela attachera cette nouvelle entité à la branche de travail en vue de la déplacer éventuellement vers master. Ce fichier existe maintenant sur la branche hello_octo; comme nous l’avons vu ci-dessus, il n’existe pas actuellement sur la branche master.
À ce stade, vous venez de prendre un instantané des modifications apportées à la branche. Dans un projet réel, il y a probablement plus de modifications et de travail être fait. C’est maintenant que vous iriez faire cela, en effectuant des commits en cours de route à des points logiques. N’oubliez pas que, sur GitHub, les validations représentent vos sauvegardes consécutives. Chaque commit a un message de commit associé, qui est une description expliquant spécifiquement ce que vous y avez fait et pourquoi. Les messages de validation capturent l’historique de vos modifications, afin que vous puissiez à l’avenir, ainsi que les autres contributeurs du projet, comprendre ce que vous avez fait et pourquoi.
Fusion du code entre les branches
Une fois que nous sont enfin terminés avec tous les changements et ajouts – et tout fonctionne * – il est temps de fusionner. La partie intéressante vient après que nous soyons revenus à notre branche master (ce que – dites-le avec moi! – nous faisons avec « git checkout master »). « Hello_octo_world » semble manquer, mais ce n’est pas le cas – actuellement, il existe sur notre travail branche et nous sommes sur notre branche principale. Je vous le montre à nouveau car c’est au cœur de la compréhension des branches dans git:
Maintenant: dans cet exercice , « hello_octo_world » représente toute modification d’un fichier (ou l’ajout d’un tout nouveau fichier) qui a passé tous les tests de notre branche de développement et est prêt à être en production. Le processus de déplacement du code entre les branches (souvent du développement à production) est connue sous le nom de fusion.
Très important: lors de la fusion, nous devons être sur la branche dans laquelle nous voulons fusionner. En gros, nous dirons à git, « Vous voyez cette nouvelle chose? Vous pouvez l’amener ici maintenant. »
Étape 5: Fusionner les modifications de la branche de travail
Dans ce cas, puisque nous voulons fusionner depuis notre branche de travail, où le » hello_octo_world » existe, dans notre branche master, nous devons être sur la branche master.
Une fois sur la branche master, tout ce que nous avons à faire est d’exécuter la commande merge. La meilleure façon de faire est de taper » git merge –no-ff »- le« –no-ff »supplémentaire indique à git que nous voulons conserver tous les messages de validation avant la fusion. Cela facilitera le suivi des modifications à l’avenir:
Revenir à GitHub
La dernière chose que nous devons faire maintenant est de faire savoir à GitHub que nous avons fait des singes avec maîtrisez ici notre environnement de développement local.
En d’autres termes, il est temps pour git push. Vous avez ceci!
La sortie git confirme que la fusion de votre branche de développement vers la branche master de votre environnement local, a maintenant été copié sur le serveur distant: « master → master. »
Et c’est tout! Nous avons réussi à créer une branche de travail distincte de master. Nous y avons apporté des modifications. Nous avons mis en scène et validé ces modifications. Nous les avons ensuite fusionnées de retour en maître sur notre environnement de travail local. Puis, enfin, tout a poussé vers GitHub pour que toutes les versions de notre projet soient les mêmes, partout!
Une note finale
Un nettoyage est dans l’ordre maintenant: puisque nous avons réussi à fusionner notre branche hello_octo, nous n’en avons plus besoin. Pour supprimer une branche fusionnée, tapez simplement « git branch -d branchName »:
Pas de soucis: si vous essayez accidentellement de supprimer une branche qui n’a pas encore été fusionnée, git lancera une erreur.
Alors! Jusqu’à présent, nous avons utilisé un exemple de projet extrêmement simplifié, car à ce stade, le plus important est de comprendre et d’assimiler le flux de travail git. Il y a beaucoup plus à fusionner que cela dans le monde réel – par exemple, que se passe-t-il si vous recevez des messages d’erreur parce que votre fusion comporte des conflits? Pas de soucis, nouveau git-ster, nous y arriverons.
Vos devoirs: créez (« touchez ») quelques nouveaux fichiers dans l’exemple de projet et entraînez-vous à faire des changements, à mettre en place, à valider et enfin à les fusionner Prenez soin de comprendre où pointe votre HEAD – c’est-à-dire quelle est votre branche actuelle. Ne validez les modifications que dans votre branche de travail.
Parce que, rappelez-vous: Ne faites pas de désordre. Avec. Le. Master .