Meilleures habitudes de contrôle de version pour développeur solo?

36

Je suis développeur unique dans mon travail et je comprends les avantages de VCS; J'ai du mal à m'en tenir aux bonnes pratiques. À l’heure actuelle, j’utilise Git pour développer principalement des applications Web (qui ne seront jamais de sources ouvertes à cause de mon travail).

Mon flux de travail actuel consiste à apporter de nombreuses modifications au site de développement, à tester, à réviser, à tester, à être heureux et à valider les modifications, puis à pousser la validation sur le site actif (donc, si je travaille sur un nouveau changement important; valider une fois par semaine, mais mon IDE a une bonne histoire d'annulation pour des choses non engagées).

Fondamentalement, je n’utilise git que lorsqu’on passe d’une machine à l’autre (p. Ex. Ordinateur dev dev., Ordinateur dev dev ou ordinateur live), mais pendant la journée, je ne vois pas vraiment les avantages. Cela me conduit à de longues listes de modifications (et j’ai du mal à trouver les bons messages pour chaque commit; et chaque fois que je suis pressé, j’ai tendance à laisser des messages de merde comme «divers changements d’admin et de templates»).

À quelle fréquence devrais-je m'engager? Chaque changement d'une ligne doit-il avoir un commit? Devrais-je m'engager avant tout test (par exemple, au moins pour les erreurs de syntaxe / compilation et ensuite pour l'annuler totalement; car l'idée n'a pas fonctionné ou le message est un mensonge)?

Dois-je m'assurer de m'engager chaque matin / après-midi avant d'arrêter de travailler pour le dîner alors qu'il est encore frais? Qu'est-ce qui me manque en ayant de mauvaises habitudes VCS?

dr jimbob
la source
2
L’une des raisons pour lesquelles vous pensez que VCS ne fonctionne pas pour vous est que vous utilisez Git en tant que développeur solo? Git me semble exagéré pour un seul développeur. Peut-être que quelque chose de plus simple avec moins de fonctionnalités comme SVN sera plus facile à utiliser?
maple_shaft
6
@maple_shaft: Je n'ai pas utilisé Git, mais Mercurial est aussi simple que Subversion pour les tâches de développement en solo de base. (Plus simple, en fait, car créer l'équivalent référentiel est plus facile.)
David Thornley
15
Pourquoi git serait-il excessif?
Tamás Szelei
1
@maple_shaft le bénéfice réel vient plus tard. Pas besoin de se contenter de moins.
3
Cela vaut la peine de mentionner que pour DVCS, comme git et mercurial, il faut tirer parti des avantages d’une sauvegarde hors site de votre contrôle de code source (comme indiqué dans certaines réponses), et ne pas simplement s’engager.
Remorqueurs

Réponses:

24

Vous manquez beaucoup.

Je suis solo aussi, d'une certaine manière. Je m'engage chaque fois que je fais un changement important ou avant d'en commencer un pour que je puisse revenir en arrière si je gâche les choses, et de temps en temps même si je ne fais rien de grand. Pas tous les jours vraiment, mais proche. Parfois quelques fois par jour.

Ce que je comprends, c'est que je peux y retourner quand je veux. C'est beaucoup. En outre, le fait de commander les branches aide.

Je suppose que cela me donne beaucoup d'ordre.

J'utilise svn et j'en ai marre. Mais ne peut pas passer plus de temps à apprendre autre chose.

Bonne chance.

cauchy
la source
+1 J'ai récemment commencé à utiliser VCS moi - même, et GIT est la chose pour moi :)
yati sagade
1
J'avais évité le contrôle de version pendant longtemps, car j'avais l'impression qu'il était trop volumineux / moche / ennuyeux. Il y a quelques mois, j'ai décidé de me familiariser avec Subversion et je ne jure que par elle.
Dalin Seivewright
1
J'ai plusieurs projets en solo: certains sur Github, d'autres non. J'utilise toujours git même si je ne fais que construire quelque chose dans le seul but d'apprendre une API / un outil particulier. Il impose de bonnes habitudes pour les projets réels où il est plus utile, comme décrit @jbcolmenares.
Sarumont
2
Je contrerai votre "ne peut pas passer plus de temps à apprendre autre chose" avec hginit.com . Comptez le temps que vous passez à être en colère contre svn pendant une semaine, puis prenez le temps nécessaire pour lire hginit la semaine suivante.
tdammers
@tdammers jettera un coup d'oeil
cauchy
18

Vous devriez vous engager souvent. Vous devriez certainement vous engager après avoir atteint un jalon logique. Si cela prend plus d'une journée, vous devriez au moins vous engager à la fin de votre journée de travail ou, mieux encore, diviser votre travail en morceaux plus petits.

Il y a plusieurs raisons à cela. Par exemple, que se passe-t-il si votre ordinateur tombe en panne? Il vaut bien mieux ne perdre qu'une journée de travail plutôt qu'une semaine ou un mois. Une autre raison est que les commits fréquents facilitent l'isolement d'un bogue. Vous pouvez effectuer une recherche binaire et déterminer le petit changement à l'origine du bogue.

Autre chose: avant de vous engager, vous devriez faire un diff et regarder tous les changements que vous avez apportés. Cela vous permet de vérifier que tous les changements ont un sens et que vous n’avez rien oublié. Cela vous aide également à créer un meilleur message de validation. Et, bien sûr, c’est une autre raison de s’engager souvent: il est beaucoup plus facile de passer par une journée de changements que par un mois.

Dima
la source
"Que se passe-t-il si votre ordinateur tombe en panne" - les fichiers sont sauvegardés assez souvent sur le disque et les sauvegardes sont effectuées de nuit (si vous voulez dire si le disque dur tombe en panne). Cependant, +1 pour la recherche binaire de bogues pourrait être utile. Je suis assez bon pour trouver rapidement 95% de mes bugs; mais de temps en temps, il y a le bogue vraiment étrange résultant d'un changement apparemment sans conséquence dans une autre partie du programme.
dr jimbob
Oui, je veux dire "si le disque se casse", ou "si le plafond s'effondre" ou "si un périphérique EMP s'éteint à proximité". :) Tout ce qui peut causer une perte de données. La validation est souvent le moyen le plus simple de sauvegarder votre travail. Elle vous permet également d’effectuer facilement une sauvegarde hors site, à l’aide d’un serveur de contrôle de version distant.
Dima
1
@Dima: vous aurez besoin de pousser et non seulement de vous engager pour votre sauvegarde
liberforce
@liberforce Tous les systèmes de contrôle de version ne disposent pas d'opérations Push. Cette réponse date de 2012. J'utilisais à l'époque Subversion, qui n'est pas distribué. Donc, pas de pression.
Dima
2
@ Dima: bien sûr, mais l'OP utilisait git, les instructions peuvent donc être trompeuses car vous n'avez pas dit que vous parliez de SVN.
Liberforce
10

Pour tirer le meilleur parti de CVS, vous devez travailler sur une fonctionnalité / correction de bogue à la fois et valider une fois cette fonctionnalité / correction de bogue terminée. En faisant cela, vous gagnerez:

  • les messages de validation seront plus faciles à créer et auront plus de sens;
  • suivi plus facile des futurs bogues dans les changements qui les ont introduits;
  • plus facile de revenir à un état précédent (même si cela impliquait de perdre une fonctionnalité en échec mais de conserver les corrections de bugs qui se produisaient par la suite).

De plus, puisque vous changez de PC, vous devez avoir au moins deux branches:

  • une branche "Ready to go" qui fonctionne toujours (sauf les bugs sur lesquels vous travaillez dans la branche de développement, bien sûr)
  • une branche de développement qui peut être dans un état inattaquable de temps en temps (comme pendant votre voyage de retour du travail;).
Ethan Furman
la source
1
+1 pour la branche prête à l'emploi! Je ne sais pas combien de fois on me demande de montrer le logiciel pendant que le patron et les clients potentiels nous rejoignent. C'est bien d'avoir une version qui fonctionne réellement et non dans un état de flux.
bluebill
Une version qui fonctionne et qui est testée est généralement étiquetée. C’est ce que vous devriez montrer, à moins que le patron ne veuille voir les derniers changements. Dans ce cas, il vous suffit de git stashmontrer ce que vous avez ou de valider un commit spécifique. Bien sûr, si vous avez des modifications importantes qui sont un travail en cours, celles-ci doivent se trouver dans une branche de travaux en cours distincte, de sorte que votre branche principale soit la branche stable de facto.
Liberforce
7

Chaque changement d'une ligne doit-il avoir un commit?

Si c'est ce qui corrige un bogue, bien sûr.

Qu'est-ce qui me manque en ayant de mauvaises habitudes VCS?

J'ai travaillé avec un gars qui avait de "mauvaises habitudes VCS". Il aimait travailler tout seul et était responsable d'une gamme de produits rapportant environ 1 000 000 $ par an. Il ne s'engageait que lorsque le patron le harcelait. Puis un jour, son disque dur s'est écrasé. Après avoir obtenu un remplacement pour lui, nous avons découvert que son dernier enregistrement avait eu lieu 6 mois auparavant. Étant donné que le VCS était Source Safe, vous pouvez deviner ce qui a mal tourné: le dernier commit a été corrompu. Nous avons dû revenir plus d'un an pour obtenir une version non corrompue de sa gamme de produits. Il n'a pas été viré, même s'il aurait dû l'être.

Une autre anecdote concerne moi-même. Je stockais du code pour des projets de loisir et de recherche sur des disques durs amovibles. Un jour, mon appartement a été cambriolé. L'ordinateur portable (qui était en panne) et tous les disques durs amovibles ont été volés. Chaque DVD (à l'exception de Red Dawn) a été volé. Aucun des ordinateurs de bureau n'a été volé. Si j'avais le contrôle à la source hors site, je n'aurais pas perdu 15 ans de projets, d'autant plus que certains étaient basés sur des projets académiques - de nombreux profs ont quitté le monde universitaire pour aller dans le secteur privé, de sorte que ces projets ont disparu dans un trou noir de la propriété intellectuelle code perdu impossible à récupérer.

À quelle fréquence devrais-je m'engager?

Je décompose en quelques mesures:

  • Combien de travail êtes-vous prêt à perdre si votre ordinateur meurt? ou se fait voler?

  • Si cela corrige Bug_1234, alors archivez le code avec le commentaire "Corrige Bug_1234".

  • S'il s'agit d'une livraison / d'un jalon logique, alors enregistrez-le avec un commentaire du type "Bug_1234, form_xyz" (ou Task_1234 selon le cas).

  • Vérifiez toujours le code vendredi soir avant de rentrer chez vous. Faites également un enregistrement (ou annulez les départs) de tout avant de partir en vacances.

  • Chaque fois que la politique de l'entreprise l'exige.

Tangurena
la source
1
Je conviens que le gars aurait dû être viré. Ne pas s'engager, même au moins pour les sorties, c'est de la folie. Comment pouvez-vous trouver les bogues apparus dans la version 1.2 si vous ne savez pas quel code est en 1.2? Le gars était-il en train de faire des copies du code et de compresser son disque dur?
Liberforce
5

Ne pensez pas en termes de nombre de changements de lignes. Pensez en morceaux de fonctionnalité. VCS vous permet de donner un titre à un emplacement central pour chaque bloc de fonctionnalité afin que vous puissiez facilement voir "ce qui est arrivé ici" avec, par exemple, le journal git.

De plus, les IDE comme Eclipse vous permettent de pointer sur une ligne donnée et d'aller au commit qui l'a amenée à la forme que vous voyez. En d'autres termes, vous pouvez accéder directement à la validation depuis une ligne source. Si le commit est petit et porte un bon message, il est beaucoup plus utile que "des tonnes de bugs fixes".


la source
4

Je dirais que la chose la plus importante qui vous échappe en regroupant les changements de cette manière est la possibilité de repérer quand et où les bogues ont été introduits.

D'après mon expérience, il y a eu quelques fois où un bogue a été remarqué deux ou trois semaines après son introduction et il est difficile de passer au crible une semaine, bien après coup. Dans ces cas, il était utile de simplement effectuer une recherche binaire dans les commits pour déterminer quel changement individuel était à l'origine du problème. Ces bogues étaient principalement des bogues d'utilisation de la mémoire sur du code C ++. Cela risque donc de ne pas se produire aussi souvent pour votre projet.

D'autres avantages entrent en jeu lors du développement en équipe: de simples commentaires de validation, des fusions plus simples, des corrections de corrections de bogues, etc.

Dans votre flux de travail, je suppose que si vous commencez à vous engager quotidiennement ou semi-quotidiennement, vous devrez utiliser des balises ou des signets pour savoir quelle version du code est utilisée sur le site actif. Je dirais que c'est la chose la plus importante à suivre.

remorqueurs
la source
4

Je suis aussi développeur solo, j'utilise SVN et j'adore ça. J'ai même écrit un outil pour convertir la structure de ma base de données et les données de test qu'il contient en XML afin de pouvoir l'inclure dans le contrôle de source.

Je m'engage généralement chaque fois que j'ai terminé une unité de travail autonome. Parfois, si j'effectue une série de corrections simples sur une ligne triviales et non liées ici et là, je les valide toutes ensemble, mais si une correction sur une ligne se produit entre deux grandes unités de travail autonomes non liées, elle prend alors sa propre commettre, il n'y a rien de mal à cela.

De plus, je valide toujours le code qui compile et presque toujours le code qui passe également tous les tests de base. Sinon, je m'assure d'inclure "NE FONCTIONNE PAS" dans le message de validation. Le seul cas où cela se produit est lorsque j'ai apporté des modifications importantes que je ne souhaite pas perdre, même si elles ne fonctionnent pas encore. En plus de cela, je suis sur le point de me lancer dans une grande aventure de refactoring que je ne suis pas sûr de savoir si ce sera réussi. J'utilise donc le référentiel en tant que sauvegarde du travail que j'ai effectué jusqu'à présent, avant de risquer de le gâcher et de le jeter à la poubelle.

Cela signifie que je commets toujours lorsque mon code source doit être validé; il est absolument insensé d’avoir des règles de consignation du matin ou du soir. C'est l'état dans lequel se trouve le code qui détermine si le moment est venu de commettre.

Les messages que vous mettez dans le référentiel importent peu. Si vous ne pouvez absolument pas trouver quelque chose de significatif, il est toujours préférable de vous engager avec un message vierge plutôt que de ne pas vous engager du tout quand vous le devriez.

Si vous ne pouvez pas penser à un bon message de commit parce que tout ce que vous proposez a l'air stupide, gardez à l'esprit que c'est correct; Les messages commit doivent énoncer une évidence, ils vous donneront donc l'air stupide lorsque vous les écrivez. Mais croyez-moi, si vous devez examiner les anciennes révisions un mois plus tard, vous serez reconnaissant même pour les messages stupides sans aucun message.

Mike Nakis
la source
1

Engagez-vous chaque fois que vous effectuez un changement "logique". Par exemple, si vous implémentez une nouvelle fonctionnalité, vous le faites étape par étape. Chacune de ces étapes dépendent généralement les unes des autres. Vous pouvez donc simplement valider ces étapes séparément et expliquer dans le message de validation pourquoi chaque étape est requise.

Le message de validation est vraiment important. Vous devez éviter de dire ce que vous faites, pourquoi vous le faites. Le code documente déjà les modifications, mais dans 6 mois, vous serez heureux de voir pourquoi vous les avez effectuées.

Ceci est également utile si, par hasard, quelqu'un entre dans le jeu et que vous n'êtes plus seul. Même pour vous, un historique vierge facilite l’utilisation de git blamepour savoir quand et pourquoi cette ligne qui a un bogue a été modifiée.

Faire de petits commits au lieu de gros changements de boue vous permet également de tester l'état intermédiaire. Vous pouvez cacher les modifications si vous devez publier quelque chose d'urgence. Si vous introduisez un bogue alors qu'il fonctionnait auparavant, vous pouvez stocker et vérifier si ce sont vos modifications non validées qui introduisent le bogue ou s'il s'agissait d'un commit plus ancien.

Vous pouvez également libérer la puissance de git bissectce qui vous indiquera le commit que ce méchant bug. Si le commit est long de 2 000 lignes, cela aide toujours, mais pas tant que ça ...

Une autre chose est que c'est la première étape pour l'intégration continue (CI) et ensuite le déploiement continu (CD). CI et vos tests peuvent être déclenchés sur un nouveau commit, vous indiquant ainsi chaque fois que vous poussez vos modifications si elles cassent quelque chose ou non. De cette façon, vous pouvez savoir si le déploiement est sécurisé ou non, et en être averti au moment où le problème est introduit et pas juste avant votre libération lorsque vous êtes pressé.

A propos de vos autres questions:

  • ne commettez pas de choses que vous n'avez même pas compilées, à moins que vous ne souhaitiez réécrire votre historique pour cela (en utilisant git rebase --interactive).
  • une modification d'une ligne mérite un commit si elle a un objectif distinct (corrige un bogue ou n'a aucun lien avec vos modifications actuellement non validées). Utilisez git add --patchpour mettre en scène ceux-ci.
  • inutile de vous forcer à vous engager avant le dîner, sauf si vous avez des choses importantes que vous ne pouvez pas vous permettre de perdre. Dans ce cas, vous voudrez peut-être engager votre travail en cours dans une branche distincte.
  • commettre et pousser dans un référentiel distant est une sauvegarde. Si vous vous engagez et appuyez une seule fois par semaine, vous pouvez, dans le pire des cas, perdre une semaine de travail.
liberforce
la source
0

À quelle fréquence devrais-je m'engager?

En tant que développeur solo, je m'engage généralement lorsque j'ai le sentiment d'avoir apporté un changement important, après des tests élémentaires et lorsque je quitte un projet à la fin de la nuit.

Chaque changement d'une ligne doit-il avoir un commit?

Non, à moins que ce changement d'une ligne ne modifie de manière significative une fonctionnalité ou un bogue.

Devrais-je m'engager avant tout test (par exemple, au moins pour les erreurs de syntaxe / compilation et ensuite pour l'annuler totalement; car l'idée n'a pas fonctionné ou le message est un mensonge)?

Probablement pas. Au moins pour moi, je fais l'essentiel de mes tests et de mon codage sur une "copie de travail", puis je m'engage après avoir été satisfait de mes modifications. Dans de nombreux IDE, il me montrera ce qui a changé avant que je ne fasse réellement le commit et me donne l'occasion d'associer des notes au commit.

Dois-je m'assurer de m'engager chaque matin / après-midi avant d'arrêter de travailler pour le dîner alors qu'il est encore frais? Qu'est-ce qui me manque en ayant de mauvaises habitudes VCS?

Je ne connais pas très bien VCS ni les mauvaises habitudes qu’il provoque. Je pense avoir surtout partagé mon opinion à ce sujet en réponse à la première question.

En réponse à la question générale postulée, vous semblez utiliser principalement les commits en tant que branches, ce qui est abordé dans un autre message de réponse. Je ne sais pas quel IDE vous utilisez a un bon historique d'annulation, etc., mais je n'en ai trouvé aucun qui, à mon avis, était bien au-delà des redémarrages de l'IDE et de la transition entre les machines.

dbuell
la source
I am not very familiar with VCS or what bad habits it causes.Quel chanceux êtes-vous!
Yannis
1
Je ne suis pas sûr de savoir comment j'ai lu cela plusieurs fois de manière incorrecte, mais j'ai continué à le lire en tant que "VSS" comme dans Visual source safe. Je connais assez bien certains systèmes de contrôle de version, y compris SVN et GIT, et les utilise fréquemment en tant que développeur solo, mais j'ai probablement quelques mauvaises habitudes moi-même, étant donné que je ne les ai pas vraiment utilisées dans le contexte d'un grand scénario impliquant plusieurs développeurs. .
jeudi
Eh bien, comme je me bats avec SourceSafe depuis plus de 3 ans, mon commentaire est toujours valable: chanceux! Pour vous donner un exemple, VSS6 pourrait gérer des référentiels d'environ 200 à 300 Mo. Par la suite, si vous aviez la chance, quelques fichiers seraient corrompus de manière aléatoire. Bien sûr, il y avait plusieurs correctifs et solutions de contournement, et VSS n'a jamais été conçu par MS comme un vcs complet, mais considérez-vous comme chanceux de ne jamais avoir à y faire face ...
yannis
0

Je suis un committer habituel et j'ai trouvé que cela me convenait, mais mes messages de commit sont presque toujours du type,

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

Je ne peux donc pas dire avec exactitude que des commits aussi fréquents et habituels dans ma branche (mercurial) ont encouragé les journaux de commit les plus détaillés. Parfois, je commets même le code à moitié terminé si, par exemple, ma femme me demande de sortir pour le dîner et que je copie simplement à la hâte et utilise le message de validation précédent "Travailler sur [...]".

Mes modèles de journal de validation sont généralement les suivants: "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

D'un autre côté, cela m'a sauvé les fesses. Parfois, je rencontre un cas extrême que je n'avais ni anticipé ni testé. À ce stade, les commits fréquents m'aident à comprendre exactement où j'ai introduit l'erreur.

Donc, je ne connais pas les meilleures habitudes et je ne suis certainement pas du genre à écouter autant que possible les habitudes de consignation, mais je peux certainement dire que s’engager plus souvent peut certainement aider à régulariser la régression.

Chaque changement d'une ligne doit-il avoir un commit?

J'ai déjà effectué des modifications sur une ligne, mais généralement difficiles et je manquais peut-être de temps. Mes commits ne ressemblent pas toujours à des unités de travail ou de changement parfaites et complètes. Comme dit, parfois, ils sont juste le résultat de ma femme me demandant de sortir pour le dîner de façon inattendue.

Bon nombre de mes commits qui suivent ce "Working on [...]"modèle de log ne modélisent pas des unités de changement cohérentes (pourquoi je ne peux souvent pas mieux faire passer un message que "Working on [...]"), mais simplement le résultat de ma respiration, comme celle de me préparer une tasse de café. Le "Completed [...]"message indique la fin de cette unité de travail, et j’écris souvent un message beaucoup plus détaillé avec les premiers "Started working on [...]"messages de type lorsque je commence à travailler sur quelque chose. Si vous commettez en moyenne comme une fois toutes les 15 minutes, alors les messages "Travailler sur [...]" ressemblent davantage à des inter-intermédiaires pour ce que quelqu'un pourrait commettre dans une validation plus volumineuse avec un message plus détaillé.

Devrais-je m'engager avant tout test (par exemple, au moins pour les erreurs de syntaxe / compilation et ensuite pour l'annuler totalement; car l'idée n'a pas fonctionné ou le message est un mensonge)?

Je me contente de le commettre avant même d'exécuter des tests parfois (encore une fois si j'avais un événement imprévu). De plus, même si je suis en solo, je pousse sur un serveur (un seul fonctionnant ici chez moi sur un réseau local) qui prend en charge le CI. Cela peut sembler exagéré, mais bon, je me suis tellement habitué à m'appuyer là-dessus dans mes anciens lieux de travail. De plus, je ne veux pas être dérangé d'avoir à exécuter tous les tests unitaires et d'intégration à la main à chaque fois. J'aime avoir tout cela lié à juste pousser. Si un test échoue, il est assez facile de travailler de manière avant-gardiste où je fais la régression, corrige l'erreur dans le dernier tour, et continue. Cela dit, au moins, je construis le code par rapport à une version de débogage avant de valider.

Dois-je m'assurer de m'engager chaque matin / après-midi avant d'arrêter de travailler pour le dîner alors qu'il est encore frais?

J'aime m'engager avant de sortir et de faire une pause entre la programmation. Je n’ai pas vraiment réfléchi à pourquoi jusqu’à ce que j’aie rencontré cette question. Je suppose que c'est pour m'empêcher de reprendre là où je me suis arrêté sans journal de validation à la place de l'endroit où je me suis arrêté que je peux me permettre de faire la différence et ainsi de suite. Hmm, je dois vous revenir là-dessus car ce n'est peut-être pas théoriquement nécessaire compte tenu de la fréquence à laquelle je commets. Je me sens toujours plus à l'aise pour engager et pousser avant de quitter l'ordinateur pour une raison quelconque. Certains pourraient être que l'ancienne peur psychologique de, par exemple, l’ordinateur s’enflamme après mon départ et que les chefs de projet reviennent à l’époque où nous utilisions SVN avec les développeurs parfois pendant des semaines sans commettre de souffler dans notre cou et de nous rappeler constamment de vérifier le code le plus souvent possible tout en nous rappelant que notre code est la propriété de l'entreprise. De plus, c'est un peu plus efficace, en particulier pour ce qui est de faire en sorte que mon processus de CI puisse commencer à exécuter tous les tests en mon absence, afin de pouvoir revenir voir les résultats.

Oh, et parfois je me saoule un peu après mon départ et c’est en général une mauvaise idée d’essayer d’écrire un code complexe tout en étant saoul (mais pas toujours; j’ai créé un système de menu contextuel vraiment sympa après un moment de boisson en état d'ivresse, mais je n'avais que 6 bières et ce n'était pas si complexe à coder). Si j'essaie de faire cela, au moins j'ai commis le code écrit sobrement avant de partir pour revenir au lieu de mélanger le code ivre avec le code sobre, à quel point mon journal de commit pourrait se lire comme "Reverting back to code written before Jagermeister shots."ceci , je ne le fais pas très souvent, à moins que je ne sois inspiré par du code ivre, mais dans ces rares cas, le fait d’avoir commis quelque chose avant de sortir et de me saouler m'a vraiment aidé.


la source
Règle de base pour vous: si vous avez deux commits consécutifs avec des messages identiques, vous vous trompez certainement. Soit ils doivent constituer un commit, soit vous devez comprendre ce qui les différencie et écrire des messages de consignation reflétant cette différence (par exemple, "définir de nouvelles données de peinture" et "définir les données de peinture correctement" plutôt que "travailler sur le système de peinture" x2).
Marnen Laibow-Koser