Est-ce que chaque git commit doit laisser le projet en état de marche?

Je suis curieux de savoir quelle est la meilleure pratique en vigueur. Les commits de git doivent-ils être appliqués de telle sorte que le projet soit dans un état de fonctionnement (construit correctement, tous les tests réussissent, etc.), ou commettre un code erroné est-il correct?

Par exemple, si vous renoncez à cette exigence, vous pouvez être plus flexible avec les commits (utilisez-les comme des blocs logiques, même si l'application n'est pas en état de fonctionnement, etc.). Cependant, si vous l'appliquez, vous aurez la possibilité de sélectionner plus tard un commit donné ...

Je suis généralement cette règle:

• Chaque fusion de masterbranche doit laisser le projet en état de fonctionnement.
• Chaque fusion avec une developbranche principale doit laisser le projet en état de marche (et il doit au moins être construit);
• Chaque engagement individuel a pour objectif principal d’expliquer pourquoi le changement a été apporté, à quoi sert-il et quelles parties du projet il a touchées. Tous les autres objectifs, tels que laisser le projet en état de marche, sont facultatifs.

Utilisez votre clone local du référentiel pour tout ce qui vous rend confortable tout en développant.

J'engage régulièrement du code erroné et, lorsque je suis prêt à le mettre à la disposition des autres développeurs, j'utilise une fonctionnalité intéressante:

git rebase -i HEAD~4

Cela me permet de compresser mes commits intermédiaires (dans ce cas 4), éventuellement cassés, en un seul commit. Un éditeur vous sera présenté vous permettant de choisir le mode de compactage de ces commits. En général, j'ai marqué le premier commettre «commettre», et marquer le «squash» des autres.

Ensuite, je peux pousser ce commit atomique, ou en fait, si ma nouvelle fonctionnalité est vraiment prête, utilisez "git cvsexportcommit" pour intégrer mon travail dans le dépôt CVS existant.

Le contrôle de version offre deux avantages intéressants: il permet aux développeurs de récupérer les versions précédentes de leur travail et aux utilisateurs d’essayer simultanément des modifications différentes, voire conflictuelles. Le contrôle de version donne aux développeurs la liberté d'essayer des idées susceptibles d'échouer.

Les développeurs doivent être encouragés à créer des branches et à s’engager régulièrement dans leur travail, qu’il soit construit ou non. Refuser d'autoriser le branchement ou les commits cassés revient à bloquer vos développeurs et à faire un mauvais usage de vos outils.

Cela dit, c’est une excellente pratique d’exiger que les commits soient toujours construits dans certaines branches. De nombreuses organisations vont plus loin et interdisent aux développeurs de s’engager dans certaines branches. Par exemple, il peut être demandé aux développeurs de fusionner leur travail dans la branche de développement principale, mais seul le développeur principal peut être autorisé à fusionner ces modifications du développement à la branche de production.

Nous suivons généralement les deux approches. Dans le référentiel local de ma boîte, je commets tout ce que je veux. Lorsqu'il est temps de passer au référentiel central de mon équipe, je commence par créer une rebase interactive et à mouler mes commits en packages logiques. Généralement, un commit par histoire, avec l'identifiant de l'histoire (ou du défaut) inclus dans le commentaire (nous sommes une boutique basée sur kanban).

Ensuite, sur notre repro centrale, Jenkins écoute et lance la compilation et tous les tests. Si quelque chose échoue, nous autorisons généralement les personnes à essayer de résoudre le build avec un autre commit. Si le résultat n'est pas bon, il est facile de revenir en arrière sur le commit défectueux.

Puisque git commit que n'affecte que votre propre copie du référentiel, il n'est pas nécessaire que le projet soit en état de fonctionner après chaque validation. Allez-y et engagez-vous chaque fois que vous souhaitez enregistrer le travail que vous avez effectué. Une bonne règle est probablement qu'une validation est appropriée lorsque vous pouvez décrire les modifications que vous avez apportées au message de validation.

C'est ce git pushqui affecte les autres utilisateurs. La décision de votre équipe de développement est de décider des règles à suivre. Pousser du code qui ne fonctionne pas sur la branche principale est sans doute un non-non, mais il est probablement correct de pousser du code qui ne fonctionne pas sur une branche distincte (tant que personne d'autre n'essaiera de créer une version à partir de cette branche).

Nous utilisons git flow au travail, et nous commettons également du code inachevé ou cassé - car il ne tombe que dans des branches locales ou distantes conçues pour ce problème spécifique. Une fois la tâche terminée, elle est fusionnée dans la branche de développement (qui représente la copie de travail actuelle dans le modèle de flux). De cette façon, nous pouvons également collaborer sur le code (certains collègues sont dans une autre ville, y compris le chef de projet) et nous entraider.

Cependant, cela dépend de la façon dont vous et vos collègues pensez. Personnellement, je pense que les commits de branche sont acceptables, car vous aurez peut-être besoin d’un historique des modifications avec un refactor plus grand ou similaire.

En fin de compte, c’est à vous et aux personnes avec qui vous travaillez ou qui travaillez, car git n’impose aucune règle.

Ma pratique consiste à éviter tout engagement qui aggrave intentionnellement le système. Chaque commit doit soit être un refactoring ou implémenter une exigence. Si je fais un mauvais commit et que je le découvre avant de le pousser, je le modifierai ou le rebaser pour le retirer de l’histoire.

Je pense que cela facilite la lecture du journal git dans une requête d'extraction, car chaque commit doit être autonome, en tant que refactoring ou implémentation de certaines exigences. Ajouter du code mort qui sera bientôt rendu à la vie comptera pour une refactorisation. Ce sont mes "morceaux logiques".

Vous pouvez toujours faire preuve de souplesse en ce qui concerne la structure de vos commits. Par exemple, vous pouvez écrire des tests à l'avance, mais les marquer tous comme ignorés dans le premier commit, de sorte que votre suite de tests ne signale pas d'échec, puis annulez leur suppression une fois l'implémentation terminée.

En supposant que vous utilisiez des branches et que vous utilisiez de bons messages de commit, commettre du code "cassé" sur une branche avec un message de validation expliquant que cela serait clair serait bien tant que votre équipe conviendra que c'est une bonne pratique de travail.

Vous clonez également le référentiel git localement, de sorte que vous pourriez bien avoir une branche locale avec des commits locaux non poussée à l'origine où vous commettez du code "cassé" au fur et à mesure; ensuite, lorsque tout fonctionne, vous pouvez le fusionner en maître ou dans une autre branche et supprimer votre branche en cours de travail avec les divers commits "cassés".

Pour moi, il s'agit avant tout de convenir avec votre équipe de ce qui est acceptable. certaines équipes n'accepteront même pas de code erroné sur une branche, d'autres l'accepteront.