Le fait de travailler avec un système de gestion des versions ne signifie pas nécessairement qu'une saine gestion des versions est effectuée. Il est possible de tout faire tout croche si on n'adopte pas une méthodologie bien définie.
La méthodologie proposée ici est une version très simplifiée de Git-Flow, une norme de gestion des version.
Vous venez de soumettre votre première révision à votre système de gestion de versions. Bravo ! Mais saviez-vous que c'était la seule fois où, dans une saine gestion des versions, vous pouviez soumettre une révision directement dans la branche principale de votre système ?
Toutes les révisions devraient être soumises dans une branche qui n'est pas la branche principale. La branche principale du système ne sera nourrie que par les fusions avec ces branches.
Avec une telle approche, vous pourrez ajouter une série de modifications et de corrections de bogues dans une application sans interférer avec le noyau stable de l'application.
Pour connaître la liste des branches de l'application :
git branch
Si vous n'avez pas encore créé de branche, vous verrez qu'il existe tout de même une branche : master. C'est la branche principale de votre système de gestion de versions.
Dans la sortie à l'écran, le nom de la branche est précédé d'un astérisque pour indiquer que c'est la branche courante, sur laquelle les prochaines versions seront soumises.
vagrant@homestead:~/code/monprojet$ git branch
* master
Vous venez de créer votre première révision dans la branche master et vous êtes prêts à commencer à travailler sur une nouvelle fonctionnalité de votre application ou de corriger un bogue ? C'est le temps de créer une branche.
git branch nombranche
Cette commande a pour effet de créer un nouveau pointeur dans l'arborescence de Git.
Afin de faciliter la gestion des branches, le nom des branches contenant de nouvelles fonctionnalités débuteront par feature- (ex : feature-televersement-photos) et le nom des branches contenant des corrections de bogues débuteront par hotfix- (ex : hotfix-save-checkbox-usager-actif).
Avant de pouvoir soumettre une révision dans une branche, il faut que cette branche devienne la branche courante.
git checkout nombranche
Attention : n'utilisez pas la commande git checkout à la légère : vous pourriez écraser les fichiers de votre répertoire de travail par ceux contenus dans la branche ciblée.
Un checkout doit toujours être précédé par un git commit afin qu'il n'y ait plus de modifications en attente dans le répertoire de travail et dans l'index de la branche qu'on s'apprête à quitter.
Cette fois, un git branch montrera qu'il y a deux branches et que la branche active a été modifiée.
vagrant@homestead:~/Code/MonProjet$ git branch
* nombranche
master
Plutôt que de créer la branche à l'aide de git branch puis de se positionner dessus à l'aide de git checkout, il est possible de combiner les deux opérations :
git checkout -b nombranche
Une fois que la branche est active, il est possible d'y ajouter des révisons avec git add puis git commit.
Notez que selon certains auteurs, les branches feature- devraient être locales (ne pas être partagées sur le serveur Git distant). Dans notre méthodologie simplifiée, toutes les branches pourront être partagées.
Il peut y avoir une, deux, trois révisions et même plus avant qu'une fonctionnalité soit entièrement terminée. Par exemple, si on ajoute une fonctionnalité de gestion des produits, on pourrait avoir une révision lorsque la liste des produits sera complétée, une autre pour l'ajout d'un produit, une troisième pour la modification d'un produit, etc.
Quand tous les aspects de la fonctionnalité sont terminés et que la dernière révision a été soumise à la branche (git commit), il est temps de fusionner cette branche avec la branche principale.
Cette opération nécessite deux étapes : il faut d'abord se positionner sur la branche qui recevra les modifications (ici : la branche principale) puis effectuer la fusion.
git checkout master
git merge nombranche
Lors d'une fusion, Git recherchera l'ancêtre commun aux deux branches. Autrement dit, il recherchera la révision qui est commune aux deux branches, soit celle qui était la dernière dans master au moment où l'autre branche a été créée.
Il vérifiera ensuite les modifications dans master depuis l'ancêtre commun puis les modifications dans l'autre branche, toujours depuis l'ancêtre commun.
Il saura ainsi ce qui a été modifié dans la branche et qui ne se reflète pas dans master. Ce sont ces différences qui seront ajoutées à master.
Lorsqu'une branche a été fusionnée, elle doit être supprimée.
git branch -d nombranche
Il y aura conflit lorsqu'on tente de fusionner une branche dans une autre et que le même fichier a été modifié dans les deux branches après l'ancêtre commun. Ceci pourrait se produire lorsque plusieurs personnes partagent des révisions sur un serveur Git distant.
Dans une telle situation, Git ne peut pas faire de miracle. Il doit nous demander de valider quelle version du fichier doit être conservée.
Ainsi, après avoir fait un git merge qui génère un conflit, vous obtiendrez un message du genre « CONFLICT (content) : Merge conflict in ... ».
La fusion sera mise en pause tant que vous n'aurez pas réglé le conflit. La commande git status affichera un message du genre « You have unmerged paths. » suivi de la liste des fichiers en conflit.
Git aura pris soin d'ajouter dans les fichiers en conflit des séparateurs indiquant à quel endroit le conflit a été repéré : « <<<<<<< » et « >>>>>>> ». Entre ces séparateurs, il a indiqué le texte qui a été modifié dans l'une et l'autre des branches à fusionner.
Pour résoudre le conflit, il faut remplacer tout ce qui se trouve entre ces séparateurs par la version du texte à conserver puis supprimer les séparateurs.
Ensuite, il faut ajouter les fichiers nouvellement modifiés à l'index à l'aide de git add puis effectuer un git commit.
« Using Branches ». Learn Git. https://www.atlassian.com/git/tutorials/using-branches
▼Publicité
