« Git/Branches » : différence entre les versions

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

<pre>

* master

Créons une nouvelle branche que nous allons appeler <code>ma-branche</code>.

 

git branch ma-branche

 

Constatons les effets :

 

git branch ma-branche

<pre>

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

<pre>

Switched to branch 'ma-branche'

On a basculé, et <code>git branch</code> nous le confirme.

 

git branch

<pre>

* ma-branche

Faisons les même modifications que précédemment :

 

echo "Ceci est un test de git" > mon_nouveau_fichier.txt

git add 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'''.

Regardons le <code>log</code> que cela produit :

 

git log --decorate --graph

<pre>

* commit 635ace69f901dfb1aaff187e6abc54b0c95fe51e (HEAD, ma-branche)

D'abord, se placer sur master :

 

git checkout master

<pre>

Switched to branch 'master'

Puis demander à git de fusionner la branche '''ma-branche''', sans {{lang|en|fast forward}}<ref>http://stackoverflow.com/questions/9069061/what-is-the-difference-between-git-merge-and-git-merge-no-ff</ref> 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 <code>-m</code> 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

<pre>

* commit abd3ef0a5978b90db042bf076e82d64c3576194b (HEAD, master)

Nos changements sont intégrés à master, la branche est désormais inutile. Supprimons-la :

 

git branch -d ma-branche

<pre>

Deleted branch ma-branche (was 635ace6).

La suppression de la branche peut échouer si la branche à supprimer n'a pas été fusionnée dans ''master'' :

 

git branch -d ma-branche

<pre>

error: The branch 'ma-branche' is not a strict subset of your current HEAD.

Git se prémunit donc d'effacer des changements potentiellement non vérifiés. Comme git l'indique, on peut forcer la suppression malgré tout :

 

git branch -D ma-branche

}}

 

==== 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 :

== 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 <code>--set-upstream</code> (alias <code>-u</code>) s'utilise uniquement à la création de la branche sur le serveur distant. Elle doit ensuite être mise à jour avec <code>push</code> tout court.