Nous avons pour l’instant utilisé Git sur une seule branche : nos commits représentent une ligne qui va du commit le plus ancien au commit le plus récent.
Mais la force de Git est le concept d’arborescence (d’arbre) constituée de branches.
Théoriquement, une branche n’est qu’un pointeur vers un commit, une sorte de raccourci vers un commit particulier, qui est mise à jour à chaque fois que l’on crée un nouveau commit sur telle branche.
Créer une branche se fait avec la sous-commande checkout
et l’option -b
:
git checkout -b <nom_de_branche>
Si la branche existe déjà, il suffit d’utiliser git checkout
suivi du nom de branche :
git checkout <nom_de_branche>
Il existe plusieurs méthodes d’organisation dans Git par rapport à l’utilité des branches
stable
et une branche development
qui représente une version plus beta de l’applicationfeature branch
git-flow, le workflow le plus ancien, un peu trop complexe
master
feature branch
pour chaque fonctionnalité en développementParfois il faut donc utiliser quelques commandes plus avancées de Git pour expliquer aux gens lisant l’historique Git quand on a voulu raconter que :
L’historique Git, c’est un peu raconter une histoire de comment on est arrivé à ce bout de code, ajouté pour telle fonctionnalité à telle version du logiciel.
Pour arriver à cela il y a 2 outils importants :
git cherry-pick <commit>
: prend un commit et l’ajoute à la branche actuelleLe rebase interactif est un outil un peu compliqué à manipuler, qui nous permet de réécrire l’historique d’une branche en choisissant quels commits on va fusionner ensemble, effacer, ou réordonner. C’est la commande git rebase -i
L’article suivant, extrêmement riche, est une référence à laquelle on peut revenir en cas de doute sur le choix de merge ou de rebase : Bien utiliser Git merge et rebase, par Delicious Insights