On va prendre un cas concret: j’ai fait un commit et en relisant ma merge request, je me rend compte que certains fichiers ne devraient pas y être:
Dans mon cas c’est le fichier src/test/java/com/globaldashboard/unit/dependencies/domain/PomUrlTest.java
L’idée va être de défaire le commit en local et de le refaire:
output de git log
⚠️ Avant de commercer, n’hésitez pas à faire une branche de sauvegarde avec la commande git branch <ma-branche-de-sauvegarde> que vous supprimerez une fois la manipulation effectuée. En faisant ça, vous éliminez tout risque de perdre du travail 🙂
Je vais défaire le commit list-cve-on-dependencies avec la commande:
git reset --soft HEAD^
Cette commande va déplacer notre HEAD sur le commit précédent et mettre tous les fichiers qui étaient commitdans la staging area. En d’autres mots, tous les fichiers que vous aviez modifié dans ce commit sont déjà “add” avec vos modifications.
En faisant un git log, on peut voir qu’on est de retour sur main et en faisant un git status, on voit que nos fichiers sont bien dans la staging area.
output git log:
output git status:
On a plus qu’à enlever le ou les fichiers qu’on ne souhaite pas commit des fichiers qui sont “add”.
Une fois fait, on peut faire un git status pour bien être sûr que le fichier n’est plus présent.
On refait un commit puis on force push avec git push –force-with-lease et c’est bon 👍
Note: utiliser git push –force-with-lease plutôt que git push -f permet de ne pas écraser la branche distante si quelqu’un a push sur celle-ci un commit que vous n’avez pas récupéré en local. Ca permet de limiter le risque d’écraser le travail de quelqu’un d’autre sans le vouloir 🙂
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...
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 comme...
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...