Remerciements à mes collègues

Depuis les 9 mois que je travaille chez PMSIpilot, je crois que je dois bien un grand merci à mes collègues, surtout ceux de mon équipe avec qui je travaille directement. Ils me supportent chaque jour, avec mes remarques graveleuses (ou alors ils font leurs choqués pour laisser croire qu’ils sont des gentlemen ?), mais surtout, ils ont subi quelques catastrophes à mes débuts.

Maintenant, je fais très attention, je fais toujours un git status avant le git commit, et ce, même si nous avons des hooks de pré-commit en place. Je jette un oeil au git diff, et souvent au git diff –cached avant de commiter, je merge en local avant de pusher, et je me refais un git log avant de pusher. Je teste mes patchs SQL sur ma DB (sauf avant de partir en congés, apparemment, ahem :$). Et je ne bouge pas de ma chaise durant les commits de merge. Je relis ce que j’ai mis dans mes boucles (requêtes ? instanciation d’objets ?)

Toutes ces opérations sont des automatismes paranoïaques, acquis suite à quelques faits d’armes, que voici (ni dans l’ordre de gravité, ni dans l’ordre chronologique) :

  • commiter des .gitignore locaux
  • ne pas commiter les fichiers du modèle
  • commiter des patchs SQL foireux
    • qui ne passent pas, à cause des commentaires, par exemple
    • ou encore qui comportent le nom de ma base de données de dév dans la requête SQL)
  • mélanger des branches au point de péter une version complète (commiter une branche de fork dans le master, en gros)
    • Pour cette catastrophe, j’ai lancé un merge, qui a généré des conflits ; j’ai résolu les conflits mais je n’ai pas fait mon commit de merge-résolution de conflits.
    • J’ai changé de branche pour aller vers une branche ‘master’ (comment git me laisse faire cela ? – je ne sais plus, j’ai bien dû forcer quelques paramètres) et je me suis retrouvée avec quasiment tous les fichiers de conflits à commiter sur ma branche.
    • J’ai commité mes fichiers en masse, et j’ai continué à travailler par là-dessus. Evidemment, à un moment, j’ai pushé mes modifications et donc tué le ‘master’ du repository distant.
  • pusher des commits foireux, et passer au git rebase interactif (4 fois en un trimestre)
J’hésite à préciser que nous avons un serveur de dév avec Jenkins pour l’intégration continue, mais surtout, j’ai, en local, mon propre Jenkins avec les principaux jobs de validation des dévs disponibles.

Vous aussi, vous faites parfois des boulettes qui vous ont beaucoup appris ?

Une réflexion sur “Remerciements à mes collègues

  1. Uhu, ça me rassure. En fait à te lire je me rends compte que je suis une toute petite joueuse au niveau des boulettes.😀
    En fait j’ai tellement les boules de tout casser que je passe mon temps à scrupuleusement contrôler ce que je m’apprête à commiter. Sauf de temps en temps. Par exemple je garde un souvenir ému de cette classe PHP pleine de log(‘Je suis passée par ici !’) et autres log(‘Je repasserai par là !’) qui s’est retrouvée chez le chef de projet. Et aussi de ce jour où j’ai copié-collé, d’un projet à l’autre, un dossier avec tous ses .svn. J’ai découvert 2 choses ce jour-là : 1. Avec SVN, on peut commiter sur deux dépôts en même temps. 2. La commande svn export.
    Et j’ai aussi eu droit à un commentaire de commit où j’apparaissais nommément ! (« Correction des bouses d’Agnès. ») Aha je suis fière. Mais je ne recommencerai pas. Non non non.

Ajouter mes idées

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s