Il arrive que la code review nous empêche de merge nos PR assez vite et qu’on se retrouve à tirer une branche d’une branche de travail pour avancer 😔
Une fois la première PR squash et merge, la PR issue de la seconde branche se retrouve avec des conflits 💥
Si vous avez déjà vécu cette situation, il y a de bonnes chances que vous ayez cherry-pick vos commits de travail sur une branche qui partait de main pour régler facilement ces conflits.
Dans cet article, on va voir une méthode bien plus efficace grâce à git rebase --onto ! ✨
Sommaire
1. Vous commencez à travailler sur une deuxième branche de feature
Vous avez travaillé sur la branche feat 1 qui est actuellement en code review.
Vous travaillez actuellement sur la branche feat 2 qui part de feat 1 car elle a besoin du code de feat 1.
2. Votre première branche est merge
Comme on a Squash, Git considère que les commits de Feat 2 issus de Feat 1 sont des commits différents du commit de merge, d’où les conflits.
On va rebase nos commits de travail (les deux rouges sur le schéma) pour faire comme s’ils partaient du dernier commit de main pour avoir comme historique:
Pour ça, on doit récupérer le hash du parent qu’on veut remplacer (le dernier issu de Feat 1) et du parent qu’on veut à la place (le commit issu du merge de Feat 1).
Une fois qu’on les a, il suffit de jouer la commande
git rebase --onto <Hash du parent qu’on veut garder> <Hash du parent qu’on veut remplacer>
Donc dans notre cas git rebase --onto 456 123
Je veux que le parent à garder soit le dernier commit de main, je fais donc:
git fetchgit rebase --onto origin/main bd0825a15b6c609e3facb6e1df759d7dae3fdf73 git push --force-with-lease 
Cette méthode est plus efficace que de tirer une branche et de cherry-pick certain commits à la main, j’espère que ça vous permettra de gagner du temps 🙂
Written By
Il arrive souvent que pour tester unitairement des règles de validation, on doive tester le même cas mais avec des exemples différents. Sans tests paramétrés, ça revient à faire un test par cas ce qui peut alourdir notre fichier de tests. On va voir comment simplifier tout ça avec des tests paramétrés. Prenons l’exemple d’une classe “Nom de Royaume” où je veux m’assurer ...
Avant .Net 8, tester du code qui utilise DateTime.Now() n’était pas trivial, on devait faire en sorte de mocker la Clock dans nos tests. Depuis .Net 8, c’est beaucoup plus facile grâce à TimeProvider inclut par défaut ! En deux mots, TimeProvider est une...
La gestion des erreurs de son API est très importante pour que les consommateurs puissent avoir une description claire du problème mais c’est souvent fastidieux à maintenir. On va voir comment avoir des statuts de réponse cohérent et des messages d’erre...
On va voir comment avoir en quelques minutes des assertions qui vont vérifier les endpoints de notre API avec des scénarios de ce genre: Feature: Create a new account As a visitor, I can create an account to access the game Scenario: A visitor c...