Git Rebase
Le Git rebase permet de reconstruire un historique soit par rapport à une autre branche,soit reconstruire l'historique de la branche elle même.
la commande :
git rebase -i HEAD~4
signifie : reprends tant de commit avant HEAD, HEAD étant notre point actuel. donc en gros ici : reprends 4 commit en arrière, et je vais te dire quoi faire avec (avec le fameux -i, qui va nous permettre d'interagir au fur et à mesure qu'il reconstruit l'historique de commits)
Vous, vous avez votre branche, avec votre travail. Le temps que vous finissiez votre travail, il est très probable que d'autres aient mergé leur feature, ce qui fait que fatalement, vous ne serez plus à jour avec master. Et pour faire votre merge request, vous aurez besoin d'être à jour avec master.
C'est là qu'intervient le git Rebase, qui permet de reconstruire l'historique de votre branche par rapport à master.
pour ceci :
git rebase -i branche-master votre-branche.
par exemple :
git rebase -i integration/preprod fix/docker-gulp
pour décortiquer : il y le git rebase, l'option -i sert à avoir l'interactivité, les infos, au fur et à mesure que le rebase aura lieu (des infos en ligne de commande en fait.).
Ensuite, il y a la branche master, ou celle qui est à jour pour vous, puis vient la branche qu'on souhaite mettre à jour.
le rebase aura pour effet de "déplacer" votre branche avec tous les commits qui avaient été faits sur cette branche pour venir les mettre à la suite de la branche master.
Vous gardez bien votre branche mais le rebase réécrit tous les commits que vous n'aviez pas de master dans votre branche à vous. Ce qui fait qu'après un rebase, on peut se retrouver avec 73 commits, s'il y a vraiment eu beaucoup de changements sur la master par exemple :).
Et pouf voilà, votre branche est à jour!
1. Reconstruire l'historique de la branche en elle même.
Mettons que vous ayez une branche. Avec 53 commits, et que parmis ces commits, nombreux sont ceux qui ne sont qu'un petit fix de 3 bouts de code, avec un message du genre, "fix". Idéalement, il vaut mieux avoir moins de commits avec des messages clairs, que pleins de commits pour une seule fonctionnalité. En général, le moins de commit il y a à la fin, le mieux c'est.la commande :
git rebase -i HEAD~4
signifie : reprends tant de commit avant HEAD, HEAD étant notre point actuel. donc en gros ici : reprends 4 commit en arrière, et je vais te dire quoi faire avec (avec le fameux -i, qui va nous permettre d'interagir au fur et à mesure qu'il reconstruit l'historique de commits)
2. Reconstruire l'historique par rapport à une autre branche.
Supposons donc que vous ayez une branche master. Celle-ci avance au fur et à mesure des merge de chacun.Vous, vous avez votre branche, avec votre travail. Le temps que vous finissiez votre travail, il est très probable que d'autres aient mergé leur feature, ce qui fait que fatalement, vous ne serez plus à jour avec master. Et pour faire votre merge request, vous aurez besoin d'être à jour avec master.
C'est là qu'intervient le git Rebase, qui permet de reconstruire l'historique de votre branche par rapport à master.
pour ceci :
git rebase -i branche-master votre-branche.
par exemple :
git rebase -i integration/preprod fix/docker-gulp
pour décortiquer : il y le git rebase, l'option -i sert à avoir l'interactivité, les infos, au fur et à mesure que le rebase aura lieu (des infos en ligne de commande en fait.).
Ensuite, il y a la branche master, ou celle qui est à jour pour vous, puis vient la branche qu'on souhaite mettre à jour.
le rebase aura pour effet de "déplacer" votre branche avec tous les commits qui avaient été faits sur cette branche pour venir les mettre à la suite de la branche master.
Vous gardez bien votre branche mais le rebase réécrit tous les commits que vous n'aviez pas de master dans votre branche à vous. Ce qui fait qu'après un rebase, on peut se retrouver avec 73 commits, s'il y a vraiment eu beaucoup de changements sur la master par exemple :).
Et pouf voilà, votre branche est à jour!
Commentaires
Enregistrer un commentaire