Quand un commit de contrôle de version est-il trop volumineux? [fermé]

J'ai entendu à plusieurs endroits "Ne fais pas de gros commits" mais je n'ai jamais vraiment compris ce qu'est un "gros" commit. Est-ce important si vous travaillez sur plusieurs fichiers, même s’ils sont liés? Sur combien de parties d'un projet devriez-vous travailler en même temps?

Pour moi, j'ai du mal à essayer de faire de "petits commits" car j'oublie ou crée quelque chose qui crée autre chose qui crée autre chose. Vous vous retrouvez alors avec des choses comme ceci:

File d'attente sortante personnalisée

Bot
-Nouveau champ msgQueue qui n'est rien d'autre qu'un SingleThreadExecutor
-sendMsg bloque jusqu'à ce que le message soit envoyé et ajoute un délai d'attente entre le moment où les messages sont reçus
envoyé
Appels -adminExist mis à jour (voir contrôleur)
-Appels supprimés à sendMessage

Manette
-Nouveau champ msgWait indique le temps d'attente entre les messages
-Le démarrage des plugins de service déplacés vers reloadPlugins
-adminExists a été déplacé du serveur à cause des administrateurs globaux. Contrôles au canal,
serveur, et niveau global

Admin
-Nouvelles méthodes getServer et getChannel qui obtiennent l'objet approprié Admin
appartient à

BotEvent
-toString () affiche également extra et extra1

Canal
-channel champ renommé en nom
Typo -Fixed dans le canal (int)

Serveur
-Moved adminExists to Controller

PluginExecutor
-Minor test ajouté, sera supprimé plus tard

Plugins JS
-Mis à jour aux modifications du framework
-Replaced InstanceTracker.getController () avec Controller.instance
-VLC parle maintenant dans son propre fichier

Diverses mises à jour et modifications du projet NB

---

Fichiers concernés
Modifier /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Modifier /trunk/Quackbot-Core/dist/README.TXT
Modifier /trunk/Quackbot-Core/nbproject/private/private.properties
Modifier /trunk/Quackbot-Core/nbproject/private/private.xml
Modifier /trunk/Quackbot-Core/src/Quackbot/Bot.java
Modifier /trunk/Quackbot-Core/src/Quackbot/Controller.java
Modifier /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Modifier /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Modifier /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Modifier /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Modifier /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Modifier /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Modifier /trunk/Quackbot-GUI/dist/README.TXT
Modifier /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Modifier /trunk/Quackbot-GUI/nbproject/private/private.properties
Modifier /trunk/Quackbot-GUI/nbproject/private/private.xml
Modifier /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Modifier /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Supprimer /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Modifier /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Modifier /trunk/Quackbot-Impl/dist/README.TXT
Modifier /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Modifier /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Modifier /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Modifier /trunk/Quackbot-Impl/lib/javarebel.stats
Ajouter /trunk/Quackbot-Impl/lib/jrebel.info
Modifier /trunk/Quackbot-Impl/nbproject/private/private.properties
Modifier /trunk/Quackbot-Impl/nbproject/private/private.xml
Modifier /trunk/Quackbot-Impl/nbproject/project.properties
Modifier /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Ajouter / trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
Modifier /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Modifier /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Modifier /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Modifier /trunk/Quackbot-Impl/plugins/listeners/onJoin.js
Modifier /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Modifier /trunk/Quackbot-Impl/plugins/testCase.js
Ajouter /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
Modifier /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Ajouter / trunk / Quackbot-Impl / vlc_http
Ajouter /trunk/Quackbot-Impl/vlc_http/current.html
Modifier /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Modifier /trunk/Quackbot-Plugins/dist/README.TXT
Modifier /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Modifier /trunk/Quackbot-Plugins/nbproject/private/private.properties
Modifier /trunk/Quackbot-Plugins/nbproject/private/private.xml
Modifier /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Ajouter / trunk / Quackbot-Plugins / vlc_http
Ajouter /trunk/global-lib/jrebel.jar

Oui....

Donc pour les questions:

• Quels sont certains facteurs à prendre en compte lorsqu'un commit devient trop important (éléments non évidents )?
• Comment pouvez-vous prévenir de tels commits? S'il vous plaît donner des détails
• Qu'en est-il lorsque vous en êtes à un stade peu avancé du développement, lorsque les choses évoluent rapidement? Les gros commits sont-ils toujours acceptables?

Pour moi, j'ai du mal à essayer de faire de "petits commits" car j'oublie ou crée quelque chose qui crée autre chose qui crée autre chose.

C'est un problème. Il semble que vous ayez besoin d' apprendre à décomposer votre travail en morceaux plus petits et plus faciles à gérer.

Le problème avec les grands commits sont:

• Dans un projet multi-personnes, une plus grande probabilité que vos validations entraînent des conflits pour la résolution d'autres développeurs.
• Il est plus difficile de décrire avec précision ce qui a été fait dans les messages de journal.
• Il est plus difficile de suivre l'ordre dans lequel les modifications ont été apportées et donc de comprendre la cause des problèmes.
• Cela augmente la probabilité de perdre beaucoup de travail non engagé.

Parfois, les gros commits sont inévitables. Par exemple, si vous devez changer une API majeure. Mais ce n'est pas normalement le cas. Et si vous vous trouvez dans cette situation, c’est probablement une bonne idée de créer une branche et de faire votre travail là-dedans… avec beaucoup de petits commits… et de vous réintégrer lorsque vous avez terminé.

(Un autre cas concerne une importation initiale, mais ce n'est PAS problématique du point de vue des problèmes énumérés ci-dessus.)

Le principe de responsabilité unique.

Chaque validation de contrôle de source ne doit servir qu’un seul objectif. Si vous devez insérer le mot "et" ou "aussi" dans votre résumé, vous devez le séparer.

Il est très courant de se retrouver avec de nombreuses modifications distinctes ou non liées dans votre copie de travail. C'est ce qu'on appelle le "problème de copie de travail enchevêtré" et il est en fait très difficile à éviter, même pour les développeurs disciplinés. Cependant, Git et Mercurial vous donnent tous les deux des outils pour le résoudre - git add -p ou chunk selection et Mercurial Queues in TortoiseHg, respectivement.

Imaginons que le client demande de faire un changement particulier - par exemple pour ajouter une règle selon laquelle quelque chose ne peut pas être fait dans les deux jours suivant la date "peu importe". Ensuite, une fois que vous avez effectué le changement, ils changent d’avis. Vous voudrez annuler votre commit. Si certaines choses vous empêchent de changer l'ordre de tri des rapports non liés, votre vie est une misère.

Un élément de travail, un changeset. Une demande du client, un changeset. Une chose sur laquelle vous pourriez changer d’avis, un changeset. Parfois, cela signifie que c'est une seule ligne de code. Parfois, il s'agit de dix fichiers différents, y compris le schéma de base de données. C'est très bien.

Les gros commits sont lorsque vous avez des tonnes de changements qui ne vont pas tous dans le même seau. Si je change la logique du contrôleur, le modèle de connexion à la base de données, puis quelques autres. scripts, je ne devrais pas tout regrouper sous un seul commit.

Prévenir, c'est commettre selon ce que vous accomplissez. Dans l'exemple ci-dessus, je commettrais après la logique du contrôleur, après le travail de la base de données et après les scripts. Ne tardez pas à vous engager simplement parce que vous savez ce qui a changé. D'autres personnes regarderont votre message de journal de consignation de «produit modifié» et se demanderont ce que vous fumiez.

Les importations initiales sont probablement les plus gros engagements que vous devriez avoir. Mettre en place un système à partir de zéro? Bien sûr, avoir quelques gros commits. Une fois que vous avez réglé le problème, il est temps de garder les choses organisées.

Si vous savez que vous allez travailler sur une grande quantité de code au préalable, je vous suggérerais de créer une branche pour votre fonction spécifique tout en extrayant périodiquement le code de la ligne principale pour vous assurer que votre code reste synchronisé. Une fois que vous avez fini de travailler sur la branche, fusionnez toutes vos modifications dans la ligne principale. De cette façon, les autres membres de l'équipe ne seront pas surpris et / ou ennuyés lorsqu'ils verront un gros commit. En outre, il y a beaucoup moins de chances de casser des choses. Continuez à pratiquer pour décomposer les choses en plus petits commits. Avec le temps, cela deviendra une seconde nature.

Cet exemple montre un commit trop volumineux.

En règle générale, décrivez le changement en une phrase ou une ligne de texte. (Sur la base de cette règle, le commit devrait être divisé en 10-15 plus petits.) Si vous ne pouvez pas commenter correctement un commit sur une ligne, il est déjà trop volumineux.

Pour effectuer de plus petites commissions, prenez des notes dans votre bloc-notes (ou dans le bloc-notes) sur ce que vous avez déjà modifié ou ajouté. Engagez-vous avant que la liste ne devienne longue ou avant que vous ne fassiez une modification de code sans rapport avec ce que vous avez déjà dans le bloc-notes.

Dans mon domaine (modélisation physique), je découvre un bogue dans la sortie aujourd'hui qui ne figurait pas dans le référentiel il y a 6 mois. Lorsque cela se produira, je ferai une recherche binaire sur les révisions:

1. Run model à partir de 3 mois
2. Si le bogue est toujours en sortie, exécutez le modèle il y a 4,5 mois
3. ... répète jusqu'à ce que je trouve le commit qui donne un mauvais résultat

Lorsque le bug a été introduit dans un commit monstrueux, je dois m'asseoir avec un peigne fin pour trouver la source du problème. Si le commit a touché un petit nombre de fichiers, il est moins pénible de localiser la ou les lignes de code à l'origine du problème.

Je recommanderais de décomposer votre problème en une série de tâches plus petites (idéalement, placez chaque tâche dans un gestionnaire de bogues). Faites un commit lorsque vous terminez chaque tâche (et fermez ce bogue / cette fonctionnalité dans votre gestionnaire de bogues).

Ce n'est pas la taille de l'engagement qui importe vraiment, c'est l' ampleur du changement qui devrait déterminer la manière dont vos engagements sont organisés.

Vous pourriez, par exemple , changer tous les cas de __macro1à __macro2dans une grande base de code, qui change de 200 fichiers. 200 engagements ne seraient pas sains d'esprit dans ce cas.

Ce que vous voulez obtenir est de pouvoir extraire le référentiel à n'importe quelle révision et de faire en sorte que la construction fonctionne. Avez-vous changé de libfooà libbar? J'espère que ce changement inclut également la mise à jour de vos scripts de construction et de vos Makefiles (ou ce qui est applicable).

Parfois, vous devrez peut-être effectuer une série de modifications expérimentales qui accomplissent une chose. Dans ce cas, vous devez déterminer quelle étendue est la plus importante pour vous si vous devez revenir ultérieurement. Est-ce que l'un dépend de l'autre? Commettez-les tous en même temps dans une seule révision. Sinon, dans ce cas, je suggérerais un commit par changement. De toute façon, vous devriez faire quelque chose comme ça dans une autre branche ou dans un autre dépôt.

Bien que oui, vous avez le pouvoir de revenir d’un fichier à une version précédente (ce qui permet de sauvegarder un fichier sur un engagement plus important), ce qui fausse vraiment les outils comme la bissection, et pollue l’historique.

Si vous vous arrêtez et pensez "Ok, les tests réussissent, je pense que cela fonctionne ... mais si ça ne va pas, puis-je facilement revenir en arrière?" .. vous finirez par prendre des engagements raisonnables.

Ce qu'il faut comprendre, c'est que "Large" dans ce contexte concerne le nombre de changements distincts et non la taille physique du commit (bien que les deux vont généralement de pair).

Son pas une question de « ne font pas grand commits » comme faire faire des petits commits - l'idéal étant de commettre petits AUTONOME changements.

Il est clair dans le journal des changements que vous avez une série de choses qui auraient pu être commises séparément (et en toute sécurité) et il est donc assez évident que c'est trop grand.

La raison pour laquelle cela peut poser problème est que votre dernière validation est votre point de référence pour les modifications que vous apportez actuellement. Si, par exemple, vous obtenez le premier bit correct puis le second, vous vous trompez, vous n’êtes pas un moyen facile pour ramener votre travail au point où vous avez commencé à faire des erreurs (BTDTGTTS).

Bien sûr, parfois, les modifications ne sont que grandes - refactorisation à grande échelle - et comme le suggèrent d’autres, c’est là que vous devez créer une branche, de cette manière même si vos commits peuvent casser des choses, ils sont séparés du tronc principal du développement, ce qui n’est problème et vous continuez à vous engager tôt et souvent.

Encore une chose - si quelque chose se passe au milieu de votre travail qui nécessite une attention plus immédiate, vous devez le modifier séparément (idéalement dans un ensemble de dossiers complètement distinct) et le valider séparément.

Le véritable défi dans tout cela n’est pas la mécanique, c’est l’esprit: un commit n’est pas simplement une copie de sauvegarde que vous faites de temps en temps, mais chaque commit est un galet de pouce et qu’il n’ya rien de mal à beaucoup de petits commits et regrouper différentes choses dans un commet de mob est aussi mauvais qu'un regroupement d'éléments de fonctionnalité vaguement liés dans un bloc de code.

Entraînez-vous au moins à vous engager lorsque vous pensez à vous-même "J'aime mes progrès jusqu'ici et je ne veux pas les perdre si les changements que je suis sur le point d'apporter sont catastrophiques". Vous avez ensuite la possibilité de tirer parti du VCS pour éliminer les impasses que vous avez essayées ou le code de débogage spécial que vous avez ajouté pour détecter un problème. (par exemple avec git reset --hardou rm -rf *; svn update)

Il n'y a pas de règle absolue ni de ligne de démarcation au-delà de laquelle votre engagement est trop important.

Il existe cependant une directive selon laquelle les plus petits commits sont meilleurs, dans les limites du raisonnable (c.-à-d. Que chaque ligne est probablement trop longue).

Je garde ces lignes directrices à l'esprit:

• Un seul commit devrait inclure des modifications pour un seul correctif
• Un seul commit ne devrait pas inclure plus d'une demi-journée de travail
• Un seul commit ne devrait pas casser la construction

Bien sûr, c’est ce que je garde à l’esprit: le YMMV. Différents développeurs favorisent différents niveaux de granularité.

Plus le commit est petit, plus il sera facile de trouver exactement d'où provient une régression potentielle.

Idéalement, un commit devrait être atomique , au sens du plus petit changement cohérent apporté à la base de code (lié à un bogue, à une fonctionnalité, etc.).

En ce qui concerne les astuces spécifiques pour garder la taille de commit petite, cela dépend grandement de votre VCS et de sa configuration: vous devez être capable de valider localement ou de travailler dans votre propre branche sur le serveur.

L'important est de vous engager dans votre branche "privée" chaque fois que vous effectuez un changement atomique, puis de fusionner régulièrement votre branche, par exemple toutes les semaines.

En utilisant un DVD, votre flux de travail pourrait ressembler à ça:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

Utilisation d’un vcs centralisé:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Vous avez probablement entendu le dicton qui dit que la perfection, c'est quand on ne peut rien enlever de plus. Cela devrait également décrire votre standard pour la taille de commit.

Cela dépend de votre projet où se trouve cette taille "parfaite". Si vous expédiez à des clients externes, une bonne taille pourrait être le plus petit incrément que vous seriez à l'aise d'expédier si vous ne finissiez pas le suivant à temps. Si vous créez des applications internes fréquemment déployées, la meilleure taille peut être le plus petit incrément qui ne casse rien (et vous rapproche de l'endroit souhaité).

Les systèmes de contrôle de version modernes vous aident à créer de bons commits avec des branches faciles, un rebasage interactif, une zone de transfert, etc.

Les messages de validation ne doivent comporter qu'une seule ligne (et pour git max 60 caractères). La quantité de code en cours de validation doit être suffisamment petite pour que le message descriptif reste dans cette limite.

J'ai tendance à commettre à chaque fois (et plus encore maintenant que nous sommes passés à git). J'ai un morceau de papier car il permet de capturer le "pourquoi" les choses ont été faites de cette façon.

Parfois, vous avez travaillé toute la journée sur plusieurs chagnes distinctes sur le plan logique et vous avez oublié de valider votre code entre les deux. Utiliser git citoolpeut être très utile pour diviser votre travail en beaux morceaux à la fin de la journée, même si vous n’êtes pas si prudent pendant la journée pendant que vous travailliez.

git citool peut vous permettre de sélectionner les morceaux spécifiques d'un fichier (ou les lignes spécifiques) à valider dans un commit particulier, afin que vous puissiez diviser (sans chevauchement) les modifications apportées au même fichier en plusieurs commits.

(Il semble que vous utilisiez Subversion. Je ne connais pas d'outil qui le fasse pour Subversion, mais vous pourriez envisager d'utiliser git-svnl'adaptateur Subversion pour git, ce qui changera votre vie.)

Plus le commit est important, plus vous risquez de casser le build et d'être payé par le reste de votre équipe. J'essaie de valider les modifications deux fois par jour. Juste avant le déjeuner et avant que je rentre à la maison. Donc, à 12 heures et à 16 h 30, j'essaie de tout faire fonctionner et de pouvoir s'engager. Je trouve que cette pratique fonctionne pour moi.

Pour répondre à tes questions:

1) Pour moi, le commit standard est considéré comme important s'il fait plus d'une chose. Par chose, je veux dire réparer un bogue ou ajouter une fonctionnalité.

2) Prévenez de tels commises en en faisant une habitude et une règle à commettre chaque fois que vous terminez quelque chose.

3) Au début du développement, j'autorise les commits à inclure la première création des fichiers qui seront utilisés ultérieurement.

Je voudrais noter que par terminé, je veux dire que tous les bugs que vous pouvez identifier ont été corrigés et que vous ne casserez pas la construction en commettant.

Oui, cela génère un grand nombre de validations, mais cela vous permet de revenir exactement sur ce qui a cassé, au lieu de devoir annuler une grande série de modifications qui ont été validées au moment même où une seule modification est à l'origine du problème.

J'aimerais également souligner que les règles changent un peu pour les systèmes de contrôle de version distribuée (DVCS) tels que Mercurial et Git. Dans le cas où vous en utilisez un, vous vous engagez chaque fois que vous apportez une modification, mais que vous ne l'avez pas encore testée, puis vous accédez au référentiel central lorsqu'il fonctionne. Ceci est préférable car cela vous permet de réviser plus de modifications de votre code sans craindre de casser la construction.

Dans mon cas, j'essaie de valider les fichiers d'un serveur dans le système de référentiel (SVN). Ceci est la validation initiale et ne souhaite pas la télécharger car il s’agit d’un projet très volumineux (quelques Go) et je souhaite effectuer la validation initiale à partir du serveur clients.

Le problème est que le client est sur un serveur partagé, le client svn est tué (ou tout autre logiciel) s'il s'exécute plus d'une minute.

Une alternative serait de télécharger le projet sur mon ordinateur et de faire le commit initial à partir de là, mais je suis intéressé de savoir s'il existe une option dans SVN pour scinder le gros commit en plusieurs méthodes, similaires aux méthodes de transaction.

Le développeur avant moi n'a jamais utilisé de système de contrôle de version.

La société pour laquelle je travaille force une révision du code par chaque pair pour chaque commit. Par conséquent, tout engagement qui rend difficile pour un pair de comprendre ce qui se passe et de le réviser dans un délai raisonnable est trop important.