Comment fonctionnent les branches Git ? – Informatique CloudSavvy

Les branches sont une fonctionnalité essentielle du suivi des versions de Git et sont constamment utilisées par les équipes travaillant sur la même base de code logicielle. Nous verrons comment ils fonctionnent sous le capot et comment vous pouvez les utiliser pour améliorer votre flux de travail Git.

Que sont vraiment les succursales ?

Les branches sont utilisées pour séparer l’historique de Git. Vous pouvez considérer les commits Git comme une ligne de modifications remontant dans le temps. Vous pouvez « vérifier » n’importe lequel de ces commits et déplacer votre répertoire local dans le temps jusqu’à l’état dans lequel il se trouvait lorsque ce commit a été effectué.

Les branches sont couramment utilisées pour travailler sur des fonctionnalités expérimentales, ou des modifications qui prennent un certain temps, ou toute autre chose qui pourrait autrement casser le référentiel. Par exemple, vous travaillez peut-être sur la refactorisation d’un gros composant de votre base de code, et jusqu’à ce que ce soit fait, vous voulez master branche pour être stable.

Une fois le nouveau feature branche est stable, elle peut être fusionnée dans mastersouvent par le biais d’un demande d’extractionqui est un processus qui permet d’effectuer une révision et des tests de code avant que des modifications ne soient apportées.

Cependant, sous le capot, les branches fonctionnent un peu différemment de ce à quoi vous pourriez vous attendre. Dans Git, les branches ne sont que des étiquettes ou des pointeurs vers un commit spécifique. Ça y est, le master branche pointe simplement vers le dernier commit effectué sur master; lorsque vous faites un nouveau commit, l’étiquette est mise à jour pour pointer vers le nouveau commit.

Bien qu’il soit utile de penser que les commits avancent dans le temps ; en réalité, les commits de Git pointent l’un vers l’autre. Chaque commit a une référence au dernier commit, et cette chaîne est utilisée pour construire l’état du référentiel.

Si vous créez une nouvelle branche, les choses fonctionnent un peu différemment. Quelle que soit la succursale que vous avez visitée (avec git checkout <branch>) sera utilisé comme étiquette pour le nouveau commit.

Pour créer la branche dans cet exemple, vous devez d’abord vous assurer que votre référentiel HEAD est défini sur master branche. En effet, vous pouvez réellement créer des branches à partir de n’importe où, y compris des commits passés ou des commits sur d’autres branches.

git checkout master

Ensuite, créez une nouvelle branche et échangez-la :

git branch feature
git checkout feature

À ce stade, rien dans votre référentiel n’a changé. Les deux feature et master les étiquettes de branche pointent vers le même commit.

Cependant, tout ce que vous engagez à partir de ce moment sera ajouté au feature branche. Plus précisément, un nouveau commit sera créé, défini pour pointer vers le commit actuel, et l’étiquette « feature » sera mise à jour pour pointer vers ce nouveau commit.

Vous pourriez même checkout master et faire plus de commits sur la branche principale. Cela n’affectera pas la feature branche, car tout ce que l’étiquette sait, c’est qu’elle pointe vers ce commit spécifique. Il ne sera pas mis à jour avec le master étiqueter.

Fusion et changement de base

Bien sûr, les branches ne seraient pas très utiles si elles y étaient bloquées pour toujours, alors Git fournit des outils pour les fusionner dans le master branche. Techniquement, vous pouvez fusionner des sous-branches dans n’importe quelle autre branche, tant que les historiques sont compatibles.

Le cas le plus simple est celui où vous avez une branche simple qui doit juste être fusionnée. Vous pouvez consulter le master branche, puis exécutez git merge feature pour « rejouer » tous les commits effectués sur la branche de fonctionnalité sur master.

Cela les intègre dans la chronologie principale et crée un nouveau « commit de fusion » avec les modifications.

Ce n’est pas toujours aussi simple cependant, et dans de nombreux cas, vous devrez fusionner les conflits qui doivent être résolus. Cela peut inclure des branches modifiant les mêmes lignes dans des fichiers, des déplacements ou des suppressions de fichiers, ou d’autres types de bogues qui surviennent lorsque le logiciel est modifié depuis la feature branche a été créée.

Si vous avez une longue durée feature branche, une façon de minimiser ce problème est d’effectuer des fusions fréquentes, en sens inverse cette fois, à partir de master dans feature. Cela garde feature à jour, et même si cela ne réduit pas vraiment la charge de travail requise, cela l’empêche de s’accumuler dans un énorme gâchis.

Cette stratégie est courante pour les branches à longue durée de vie et est généralement considérée comme la meilleure pratique pour Git.

Un autre outil qui est également utilisé dans ce scénario est rebasage. Fondamentalement, le rebasage revient à récupérer la branche entière et à la déplacer pour démarrer à partir d’un nouvel emplacement, souvent le dernier commit du référentiel. Cela conduit à un historique Git plus propre dans certains cas et constitue la solution préférée pour certaines situations compliquées.

Cependant, l’historique de Git est « immuable » et, à cause de cela, le rebasage copie les commits au lieu de les déplacer. Cela peut entraîner de nombreux problèmes sur les branches partagées, s’il n’est pas correctement coordonné avec votre équipe. Si vous rebasez et que votre collègue effectue un nouveau commit sur « l’ancienne » branche de fonctionnalité maintenant supprimée, elle restera bloquée. Ils devront stocker le commit et le placer sur la nouvelle branche pour concilier les modifications.

Comment utilisez-vous les succursales ?

Pour commencer à créer une nouvelle branche, vous devez mettre votre référentiel dans l’état approprié afin que la nouvelle étiquette de branche commence là où vous le souhaitez. Si vous bifurquez de master, il suffit de vérifier la branche entière pour commencer au dernier commit. Sinon, vous pouvez mettre votre référentiel dans un état HEAD détaché en extrayant un commit individuel.

git checkout master

git checkout aa3e570923b8ee61414cec17d9033faab4f084a6

Ensuite, vous pouvez créer la nouvelle branche et y basculer avec le paiement :

git branch feature
git checkout feature

Cela peut être fait en une seule commande, avec le -b drapeau à la caisse :

git checkout -b feature

À ce stade, tous les commits effectués dans votre dépôt seront effectués dans la nouvelle branche.

Si vous avez besoin d’échanger à nouveau des branches, exécutez simplement git checkout master être remis à la normale.

Si vous avez des modifications locales que vous devez déplacer, vous pouvez les mettre dans git stash. Les modifications seront stockées et pourront être réappliquées après l’échange de branches.

git stash 
git checkout feature
git stash apply