Git/Branches
Précédemment, nous avons vu comment apporter des modifications à une branche telles que ajouter, modifier ou supprimer un fichier et codice_1 nos modifications. Cela fonctionne parfaitement et cela peut suffire pour travailler seul sur un petit projet. Toutefois, ce n'est pas la meilleure façon de procéder sous git qui propose des mécanismes plus élaborés pour développer sur un projet.
L'approche de git est de favoriser l'utilisation de branche pour toute modification du code de l'application.
Ainsi, il ne faut jamais travailler directement sur la branche *master* : cette branche doit rester stable et ne doit être utilisée que pour baser son travail dans d'autres branches.
Pour mieux comprendre, nous allons refaire, pas à pas, exactement les mêmes modifications que celles que nous avons faites précédemment mais, cette fois, nous allons utiliser une branche afin de nous familiariser avec ce concept.
Reprenons notre dépôt d'exemple :
git clone https://gerrit.wikimedia.org/r/p/test/mediawiki/extensions/examples.git
cd examples
Créer une première branche.
D'abord, demandons à git de nous indiquer où nous en sommes au niveau des branches :
git branch
Git nous indique qu'il existe une seule branche appelée codice_2 et que c'est sur cette branche que nous travaillons comme l'indique l'astérisque en face de codice_2.
Créons une nouvelle branche que nous allons appeler codice_4.
git branch ma-branche
Constatons les effets :
git branch ma-branche
Il y a maintenant deux branches : *master* et *ma-branche*. Actuellement, nous travaillons toujours sur *master* comme l'indique toujours l'astérisque.
git log --decorate --graph
On peut voir, sur la première ligne que *master* et *ma-branche* sont au même niveau, sur le même commit. Nous allons maintenant demander à git de nous basculer sur *ma-branche* afin de pouvoir travailler sur celle-ci et non sur *master*.
git checkout ma-branche
On a basculé, et codice_5 nous le confirme.
git branch
Faire les modifications.
On peut désormais faire les modifications dans ma-branche que l'on peut développer, sans prendre le risque de modifier master.
Faisons les mêmes modifications que précédemment :
echo "Ceci est un test de git" > mon_nouveau_fichier.txt
git add mon_nouveau_fichier.txt
git commit -m "ajout d'un fichier"
echo "Une seconde ligne" » mon_nouveau_fichier.txt
git add mon_nouveau_fichier.txt
git commit -m "ajout d'une seconde ligne dans le fichier"
echo "Une troisième ligne" » mon_nouveau_fichier.txt
git add mon_nouveau_fichier.txt
git commit -m "ajout d'une troisième ligne dans le fichier"
Et ainsi de suite. Vous pouvez commiter et faire autant de commits que vous voulez dans ma-branche.
L'idée est que pour chaque évolution du logiciel développé, il faut créer une branche. Ainsi, on peut garder la branche aussi longtemps que nécessaire et continuer de travailler dessus tant qu'on a pas fini la fonctionnalité.
Regardons le codice_6 que cela produit :
git log --decorate --graph
Examinons ce graphique : master est en retard tandis que ma-branche est en avance de trois "commits".
Fusionner la branche dans master (merge).
Supposons que nous sommes satisfaits du travail réalisé dans notre branche. Nous avons fait plusieurs "commits", nous avons vérifié que nous n'avons pas créé de bogue, etc. Supposons que notre branche est prête et qu'on peut intégrer les modifications dans master.
D'abord, se placer sur master :
git checkout master
Puis demander à git de fusionner la branche ma-branche, sans pour éviter de perdre la topologie de la branche :
git merge ma-branche --no-ff -m "intégration de ma nouvelle fonctionnalité dans master"
Git va faire un commit pour intégrer les changements. Comme précédemment, nous avons choisi d'utiliser codice_7 pour préciser le message de commit mais on aurait pu ne rien mettre et git nous aurait ouvert l'éditeur de texte.
Examinons
git log --decorate --graph
On retrouve bien quatre "commits" nous appartenant (symbolisés par une * dans le graphe). On retrouve les trois premières modifications et un quatrième "commit" pour le codice_8. On voit que les branches ont convergé sur le graphique et que master est de nouveau sur la première ligne tout en haut du graphe. Nos changements ont bien été intégré à master.
Effacer une branche.
Locale.
Nos changements sont intégrés à master, la branche est désormais inutile. Supprimons-la :
git branch -d ma-branche
NB : une branche ne peut pas être supprimée si on n'a pas fait le dernier commit.
Distante.
 git push <remote_name> --delete <branch_name>
Supprimer les veilles branches.
Lorsque l'on tape "git branch" après un certain temps, la branche active apparait au milieu d'une multitude d'anciennes branches généralement fusionnées, et donc inutile de conserver en local. Pour les nettoyer on utilise donc :
git remote prune origin
Mais parfois il reste encore un paquet de branches locales qui ont été mergées sur le serveur. Pour éviter d'avoir à les supprimer une par une :
 git branch -D `git branch --merged | grep -v \* | xargs`
Sinon, nommer la branche dans laquelle elles furent fusionnées. Par exemple, pour supprimer les branches mergées dans "master" :
 git branch -D `git branch --merged master | grep -v \* | xargs`
Renommer une branche.
Il faut renommer la locale, supprimer la distante, puis pusher la locale :
 git branch -m vieille_branche nouvelle_branche
 git push origin :vieille_branche
 git push --set-upstream origin nouvelle_branche
L'option codice_9 (alias codice_10) s'utilise uniquement à la création de la branche sur le serveur distant. Elle doit ensuite être mise à jour avec codice_11 tout court.
Continuer.
Vous pouvez à tout moment créer des nouvelles branches depuis master et ce, à chaque nouvelle fonctionnalité ou nouvelle modification qu'il faudrait apporter au projet. Git vous permet de gérer plusieurs branches en parallèle et ainsi de cloisonner vos travaux et d'éviter de mélanger des modifications du code source qui n'ont rien à voir entre elles.
En gardant une branche master saine, vous vous laissez la possibilité de créer de nouvelles branches simplement et vous conservez ainsi une version du logiciel prête à être livrée à tout instant (puisqu'on ne codice_8 dedans que lorsque le développement est bien terminé.
codice_13 vous permet de retrouver dans l'historique les branches qui ont été créées, et les différents "commits" réalisés pour une même fonctionnalité sont bien regroupés entre eux.

Git/Synchroniser le dépôt local avec le dépôt distant