Est-il correct d'avoir rompu les validations intermédiaires, tant que la validation finale dans n'importe quel push fonctionne?

Connexes: chaque git commit devrait - il laisser le projet dans un état de fonctionnement?

Supposons que je fasse les commits suivants localement:

• Modifiez le schéma de la base de données, interrompant l'application.

• Mettez à jour l'application afin qu'elle soit à nouveau compatible avec le schéma de base de données.

Tant que je pousse les deux commits, masterreste dans un état de fonctionnement. Cependant, une version historique est cassée.

Je sais que je peux utiliser git rebase -ipour écraser les commits ensemble. Cependant, le commit résultant sera volumineux et moins descriptif. Si je dois rechercher dans l'historique des validations pour savoir pourquoi j'ai changé quelque chose, je préfère trouver la validation d'origine montrant ce que j'ai fait et pourquoi.

Mes questions sont:

• Quelqu'un a-t-il rencontré des difficultés dues à des engagements historiques brisés dans master?

• Dans l'affirmative, existe-t-il un moyen simple d'éviter de telles difficultés, sans rejeter les messages de validation et les modifications individuels?

Cela dépend en grande partie de la stratégie de branchement de votre tenue, mais je pense qu'avoir rompu les commits sur les branches de développement a un sens en général - le vrai gros "gain" en utilisant le contrôle de code source est de pouvoir annuler de petits changements et parfois vous êtes en faire un tas et tu dois casser des œufs pour faire des omelettes.

Le moyen simple de conserver les commits individuels sans polluer le maître est d'utiliser des branches. Vous pouvez y mettre les informations de rupture / expérimentales afin d'avoir une histoire fine sans polluer l'histoire de la branche principale.

Les commits brisés sont quelque chose qui «se produit», ne devrait pas signifier la fin du monde. J'ai une petite voix lancinante à l'arrière de ma tête qui me dit que l'on ne devrait pas sciemment vérifier le code cassé, par principe et donc inclure des versions historiques, mais ce n'est pas quelque chose que j'irais en guerre.

Le modèle de branchement très apprécié de Git permet de conserver les validations brisées de branches spécifiques, par exemple si votre équipe adopte gitflow ou une version simplifiée de celle-ci. Tout ce qui a une politique de «maître propre». Dans ce cas, vous pouvez archiver la version finale et fonctionnelle en tant que commit de fusion, où les versions historiques (rompues) sont disponibles dans le référentiel mais hors de la ligne principale.

Si votre équipe n'a pas adopté un tel modèle de branchement, alors vous avez une excuse valable pour simplement pousser le tout à maîtriser et à en finir.

Non, ça ne va pas.

Si vous avez déjà fait un git bisect(et qui n'aime pas cette fonctionnalité tueuse), vous connaissez la valeur d'une histoire où chaque commit se construit.

Si vous avez plusieurs commits pendant un bisectbuild qui ne se construit pas, vous aurez beaucoup de git bisect skips qui rendent difficile la recherche du dernier bon commit.

Si vous terminez une branche d'entité et la fusionnez dans master, nettoyez la branche avant de fusionner afin que votre historique soit clair et en construction.

Quelqu'un a-t-il rencontré des difficultés dues à des engagements historiques brisés dans master?

Oui. Les rétroportages, les retours et les bissectrices sont plus difficiles. Il en va de même pour la lecture de l'histoire (voir ci-dessous).

Dans l'affirmative, existe-t-il un moyen simple d'éviter de telles difficultés, sans rejeter les messages de validation et les modifications individuels?

Pas que je sache, bien que les succursales soient une solution décente.

Cependant, je pense que rejeter (ou plutôt écraser) l'individu commet est la bonne chose à faire.

Pendant le développement, en particulier lors de TDD, s'engager tôt et souvent est bon. Vous voulez la trace complète de ce que vous faites afin que vous puissiez revenir en arrière, ou savoir exactement quand les choses ont commencé à mal tourner (ou peut-être vous êtes-vous retrouvé dans une refactorisation plus grande que vous ne pouvez mâcher). Engagez-vous.

Cependant, une fois qu'une fonctionnalité / modification est prête à être poussée, une validation est un changement groupé - idéalement atomique afin qu'il puisse être [révisé, rebasé, fusionné, sélectionné par les cerises, annulé, visualisé en annoté] aussi indépendamment des autres modifications que possible .

En examinant l'historique d'un projet, un changement de logiciel doit être évalué seul. Construit-il? Vient-il avec des tests? Est-ce que ça marche? Qu'est ce que ça fait? Quels fichiers devaient être modifiés pour offrir cette fonctionnalité?

Devoir assembler des commits, bien que possible (et aidé par des fusions), rend cela plus difficile. Par conséquent, je pense que nettoyer votre histoire avant de pousser est approprié, même si cela signifie perdre la trace de la façon dont vous êtes arrivé là où vous êtes.

Réponse courte: Oui

Essai:

Le développement piloté par les tests signifie que vous écrivez des tests qui échouent (c'est-à-dire qui montrent un échec).
Ensuite, vous écrivez le code pour faire fonctionner les tests.

Développement:

Engagez-vous petit, engagez-vous souvent.
Chaque validation est un point de restauration. Si vous vous rendez compte que vous êtes sur le mauvais chemin, vous pouvez revenir assez facilement à un point précédent. Si vos commits sont suffisamment fins, vous pouvez revenir au bon point.

Caveat:

Cela ne veut pas dire

1) Vous vérifiez le code cassé dans le maître.
2) Vous devez pousser tous les micro-commits pour que tout le monde les examine.

Utilisez des branches pour faire votre travail. Comprimez potentiellement les micro-commits pour les processus de révision afin qu'ils soient dans des unités logiquement distinctes avec des commentaires appropriés. Si vous utilisez git, vous ne perdrez pas l'ensemble de validations d'origine, vous pouvez simplement créer un nouvel ensemble de validations plus logique pour les processus de révision qui seront fusionnés dans master.

Je pense que tant que les commits sont locaux et non poussés aux autres, ce n'est pas seulement ok, c'est en fait une bonne façon de travailler. Il suffit de ne pas pousser le code cassé vers les autres.