Quand devrais-je effectuer le premier commit sur le contrôle de source?


118

Je ne suis jamais sûr qu'un projet est suffisamment avancé pour s'engager d'abord dans le contrôle de source. J'ai tendance à différer mon engagement jusqu'à ce que le projet soit terminé, et j'engage principalement les fonctionnalités à partir de ce moment. (Je n'ai pas fait de projets personnels assez importants pour avoir un cadre de base trop grand pour cela.) J'ai le sentiment que ce n'est pas la meilleure pratique, même si je ne suis pas sûr de ce qui pourrait mal tourner.

Disons, par exemple, que j'ai un projet qui consiste en un seul fichier de code. Il faudra environ 10 lignes de code standard et 100 lignes pour que le projet fonctionne avec des fonctionnalités extrêmement basiques (1 ou 2 fonctionnalités). Dois-je d'abord m'enregistrer:

  1. Le fichier vide?
  2. Le code standard?
  3. Les premières fonctionnalités?
  4. A un autre moment?

Aussi, quelles sont les raisons pour vous enregistrer à un moment donné?


10
avant de rentrer chez vous, vous vous engagez dans votre propre branche d'activité.
Reactgular

59
Le premier engagement doit toujours être effectué après la création d'un projet Sourceforge, la configuration d'un site Web, la configuration de la liste de diffusion et la publication d'un blog sur le projet pendant plusieurs années. :)
Kaz

15
Quel est l'inconvénient de s'engager trop tôt ou souvent?
Isaac Rabinovitch

13
mkdir myproj; cd myproj; git init; commence travail.
Eddie B

10
J'ai appris à gérer la sauvegarde des progrès grâce au bouton de sauvegarde rapide dans les jeux vidéo. La règle est la suivante: Will I mind having to redo that part ? Save : SaveAnyway;j'adopte la même approche du contrôle de source, je n'attends pas que quelque chose fonctionne ou que je sois presque complet, j'attends simplement d'avoir trouvé quelque chose ou apporté suffisamment de modifications que je ne souhaite pas. être obligé d'essayer de trouver une nouvelle solution ou d'apporter ces modifications, puis je vérifie. C'est pourquoi les gens suggèrent de sauvegarder après la création du projet; Créer des projets est agaçant, vérifiez donc que vous n’aurez plus à le refaire.
Jimmy Hoffa

Réponses:


103

Vous devez vous engager dès que vous avez une "unité" complète complète.

Qu'est-ce qu'une unité? Cela dépend de ce que vous faites. Si vous créez un projet Visual Studio, par exemple, validez la solution immédiatement après sa création, même si elle ne contient rien.

A partir de là, continuez à vous engager aussi souvent que possible, mais n'enregistrez que des "unités" complètes (par exemple, des classes, des configurations, etc.); cela vous facilitera la vie si quelque chose ne va pas (vous pouvez annuler un petit ensemble de modifications) et réduira le risque de conflits.


27
Je m'engage presque constamment dans une branche de travail et je fusionne cette branche dans la ligne principale en unités. Cela donne le meilleur des deux mondes en ce que la ligne principale est composée d'unités avec de petites séries de modifications à revenir, mais la branche thématique peut me permettre de revenir en arrière un peu à la fois.
Jeff Ferland

16
Un commit n'est jamais trop petit! Ne vous abstenez pas de valider vos modifications!
Leonardo Herrera

1
Je dirais +1 à de nombreux petits commits fréquents, en fonction de votre flux de travail et du nombre de personnes intéressées par votre dépôt pour effectuer leur travail. La capacité de Git à réécrire un peu l’histoire de telle sorte que ces 15 commits FooSerializerpuisse devenir une chose avant que vous ne vous y aidiez.
Tim Post

1
@ loldop: Cela dépend du logiciel de contrôle de version que vous utilisez. Supposons que vous utilisiez Git: vous pouvez cacher ce que vous avez fait, corriger le problème, le valider, réappliquer les modifications stockées et recommencer à travailler dessus. Dans Subversion, vous pouvez effectuer une autre extraction du référentiel dans un autre dossier, corriger le bogue et valider le référentiel sans affecter votre refactoring. Ou créez un fichier de correctif, annulez votre modification, corrigez le bogue, validez, appliquez de nouveau le correctif. Il y a plusieurs façons de le faire.
Albireo

1
Peut-être que c'est une bonne réponse au 2ème, 3ème commit, etc. Mais le premier devrait être simplement vide.
Felipe

143

En ce qui me concerne, votre référentiel de contrôle de source fait partie de la configuration de base du projet. Je m'engage dès que je génère mon projet vide.


29
Engagez-vous tôt, engagez-vous souvent.
Leonardo Herrera

11
Je suis d'accord avec cela plus que la réponse acceptée. Je considère également le contrôle de source (je veux dire DVCS) comme un gros bouton d'annulation si je me trompe royalement. Je recommande également vivement d'utiliser semver (via des balises) et de commencer avec la version 0
Antony Scott

2
Merci @AntonyScott Je suis d’accord à 100% avec la réponse acceptée, mais lorsque j’ai écrit ceci, j’avais eu cette vision de brouiller les pistes avec un essai de 1500 mots sur la façon dont je gère le contrôle de source et pourquoi. J'ai donc décidé de rester simple et précis.
John MacIntyre

2
Oui, +1. Si vous vous sentez mal à propos d'un commit vide, commencez par le .gitignore (ou son équivalent) comme l'a écrit Xion dans une autre réponse [ programmers.stackexchange.com/a/176845/5405] . C'est un premier engagement très naturel.
Hanno Fietz

J'ai remarqué le drapeau "réponses longues" sur la question et je ne peux pas m'empêcher de penser que cela fait référence à cette réponse. AFAIC j'ai répondu «pourquoi? question avec le "repo de contrôle de source fait partie de la configuration de base du projet" partie de la réponse. Comme je l'ai dit, je pourrais écrire un essai sur l'ensemble de ma philosophie sur l'utilisation du contrôle de source, mais cela ne ferait que nuire à cette réponse. Si quelqu'un a une question précise au sujet de ma réponse, je serai ravi d'y répondre, mais je ne veux pas non plus donner une réponse plus compliquée à des fins de verbage. Si vous voulez le supprimer, allez-y.
John MacIntyre

77

Hier

... alternativement, si vous êtes incapable de voyager dans le temps ...
(peut-être que votre voiture ne peut pas atteindre 88 mph, ou votre condensateur de flux cassé)

Maintenant

Les nouveaux projets doivent être lancés sur le point sanglant, ce qui est dingue, et les systèmes DVCS contemporains ont supprimé toutes les excuses possibles pour éviter les commits : git init . ; git add * ; git commit -m initial-commitmaintenant, avant qu'il ne soit trop tard, comme cela pourrait déjà être le cas.

Une question plus raisonnable et discutable aurait pu être: "Quand devrais-je fusionner mes commits avec un contrôle de source partagé sur un référentiel géré par une équipe sur un projet établi ?" (notez les adjectifs, les adjectifs sont importants) Et j'ai le sentiment que la plupart des autres réponses tentent réellement de répondre à cela.

Votre branche personnelle devrait s’engager à aimer les fous , au moins une fois par jour , avant de se coucher. Vous pourriez vous réveiller le lendemain matin et ne plus avoir la moindre idée de ce que vous prépariez, la nuit précédente. Le VCS doit vous protéger contre cela, et avoir la possibilité de revenir à une version très récente d'une sous-version d'une sous-version qui compile bien, fonctionne bien et / ou réussit les tests pourrait être votre meilleure option.


3
Cela ne me dérange pas que des modifications engageantes qui ne se compilent pas, surtout en fin de journée. Le lendemain, vous avez quelque chose qui ne se compile pas mais vous avez toujours votre historique de commit. Si vous ne voulez pas que votre historique soit "sale", il existe des options de restauration dans chaque bon DVCS (je pense que nous sommes tous d'accord pour dire que le DVCS est le seul moyen de go.)
Leonardo Herrera

@LeonardoHerrera Je comprends votre POV, bien que dans les projets de langage interprété avec plusieurs points d'entrée, vous finissiez par commettre une branche non compilante pour des raisons légitimes (comme le partage de corrections de bugs sur un point d'entrée différent), cela peut certainement être fait mieux et plus agréable , mais alors cela devient un peu une question de goûts ... et de gustibus non est disputandum .
ZJR

20

Je dirais engager au plus vite. L'objectif principal du contrôle de source est de vous permettre de revenir en arrière en cas de problème, ce qui résonne avec la pratique du "commettre tôt et souvent".

Personnellement, mon premier commit ne contient généralement que le fichier .gitignore (ou l’équivalent) avec peu de filtres nécessaires, comme * .py [co] pour le code Python. La configuration de base du projet et / ou le premier prototype le plus simple est ce qui suit habituellement.


Je fais quelque chose de similaire. Depuis que j'utilise GitHub, j'ai aussi toujours un fichier README de base, même s'il ne contient que le nom du projet. Je trouve que le fichier existe depuis le début rend beaucoup plus probable le fait de le mettre à jour ultérieurement :).
Tikhon Jelvis

16

Le premier commit peut être un fichier README avec un résumé du projet d'une ligne ou suffisamment d'informations sur le premier jalon du projet. Les sujets généraux peuvent également inclure:

  • introduction
  • Description du projet
  • Structure de projet
  • Conventions de codage
  • Instructions sur la façon de:
    • construire
    • tester
    • déployer
  • Problèmes connus et solutions de contournement
  • liste de choses à faire
  • Conditions d'utilisation

La pratique consistant à mettre à jour le fichier README avant d'apporter des modifications à un projet est également appelée développement basé sur le fichier Lisez-moi. Elle vous permet de réfléchir aux modifications avant d'investir du temps dans ces modifications.

Toute personne souhaitant contribuer ou utiliser ce logiciel commencera par le fichier README.


12

Si vous avez effectué un travail que vous ne voudriez pas perdre, cela devrait être dans votre système de contrôle de code source.

Ceci s’applique certainement aux systèmes distribués comme Git. Si vous utilisez un système centralisé et que la seule façon d’enregistrer une tâche est de la rendre visible par tout le monde , vous pouvez attendre, ou envisager de créer votre propre référentiel git local et de la soumettre au système centralisé. système lorsque vous êtes prêt.


3
Ma règle est la suivante, mais je souhaite également que ce soit un "moment où le code est compilé". Commettre ce qui ne compile pas et ne coupe pas en deux devient d'autant plus gênant, si jamais vous devez trouver quand vous avez cassé quelque chose.
Warren P

Une branche temporaire ne pourrait-elle pas répondre à cette question, du moins pour git? Je n'ai pas git bisectbeaucoup utilisé .
Keith Thompson

J'utilise mercurial sans rebase, donc je traite tous les commits comme étant permanents
Warren P

7

Ma règle d'or consiste à archiver une fois mon fichier de solution (ou un autre élément de script de construction) terminé, même s'il contient quelques fichiers vides. C'est une bonne pratique lorsque plusieurs personnes travaillent sur le projet. Ce fichier a tendance à présenter les pires problèmes de fusion initialement car les utilisateurs ajoutent des éléments au projet, ils doivent donc s’engager tôt et souvent.

Même si vous êtes le seul à travailler sur le projet et que celui-ci ne contient qu'un fichier, je trouve qu'il est plus facile de suivre le même flux de travail et d'enregistrer la pensée pour le problème à résoudre.


6

Je ne sais pas si cela a été mentionné.

Mais assurez-vous que ce que vous commettez est exécuté / compilé! Donc pas d'erreur de syntaxe, etc.

Rien de plus frustrant que de vérifier le code qui est cassé.


en effet, cela a du sens!
Aquarius_Girl

Je ne suis pas d'accord. Si mon code ne se compile pas lorsque je souhaite valider, j'écris WIP quelque part dans le message de validation. Ensuite, je peux simplement ignorer ces commits lorsque j'ai besoin de la dernière version compilée.
Minthos

5

Un autre point de vue plus lié aux tests logiciels (approche TDD) serait de s’engager dès que vous aurez de nouveaux cas de tests en vert. Cela voudrait dire que vous avez une nouvelle "unité" de code complétée.


Pour couvrir une méthode, vous pourriez (principalement) avoir besoin de plusieurs tests unitaires. Ce n'est pas vraiment vrai de dire que si vous réussissez un test, cela signifie que vous avez terminé une unité de travail. Ce n'est même pas vrai de dire que finir cette méthode est une unité de travail non plus.
Behnam Rasooli

5

Juste avant de faire quelque chose de stupide.

Pour ceux d'entre nous sans pouvoirs magiques, cela signifie peu et souvent.

Si vous travaillez seul, faites-le chaque fois que vous prenez un verre ou autre chose.

Si vous travaillez en équipe, vous devez probablement vous assurer que la chose est compilée, de sorte que si quelqu'un d'autre a les dernières nouvelles, il n'aura pas beaucoup d'erreurs. Mais à part ça, autant que vous le pouvez.


4

Environ 2 ~ 3 heures dans le projet.

Je rigole. Il n'y a pas une seule bonne réponse qui convienne à toutes les situations. Tout d'abord, si vous avez un système de contrôle de version distribué (tel que git ou Mercurial), alors vous engager dans votre référentiel local ne conservera pas vos données en cas de défaillance grave. Mais un repo distant distant peut vous coûter de l’argent, par exemple sur github. Vous préserverez l'historique des commissions, mais d'après mon expérience, vous n'en aurez pas besoin jusqu'à ce que votre projet soit un peu avancé.

En outre, vous ne voudrez probablement pas trop de désabonnement au début, surtout si vous déplacez des fichiers. Commettre des changements sera un fardeau, ne serait-ce que pour un petit. Vous pouvez même décider de jeter la chose. Mais si vous perdez des modifications qui ne sont pas faciles à répliquer, vous manquerez d'avoir fait une copie de sauvegarde, et les systèmes de contrôle de version constituent des systèmes de sauvegarde extrêmement précieux.

De nos jours, certaines personnes utilisent DropBox ou similaire pour stocker leur code. Ce peut être un bon compromis au début d’un projet car sa mise en place ne demande aucun effort. Il s’agit toutefois d’une habitude barbare dans le développement de logiciels sérieux, surtout si plusieurs personnes touchent le code en même temps.

Ainsi, j’ai tendance à configurer le contrôle de version chaque fois que j’ai quelque chose de précieux, c’est-à-dire qu’il n’est pas trivial de le reproduire. La valeur est subjective (et dépend de ses capacités) donc vous devrez faire votre propre jugement. À ce stade, je stocke un deuxième dépôt sur un disque externe, ou sur github s'il s'agit d'un projet public ou si mon compte payant le conservera.


3

Beaucoup de gens ont déjà répondu "Tout de suite" et je suis tout à fait d'accord. J'aime aussi la suggestion de Xion de commencer avec les modèles d'ignorance du VCS (c'est .gitignore-à- dire ou l'équivalent).

Je suppose qu'il est assez largement convenu qu'il n'y a pas d'inconvénients à ce que les premiers engagements soient pris. J'aimerais ajouter des avantages:

  • Vous êtes moins susceptible de commettre des choses que vous avez choisi de rejeter, mais qui persistent encore. Lorsque je commence un nouveau développement, je code et dissèque rapidement les éléments, et lorsque je commets plus tard, quand il y a déjà beaucoup de fichiers, j'ai accidentellement commis des éléments dans le seul but de les supprimer lors du prochain commit. Ceci, par opposition aux commits petits, voire vides, est un vrai bruit dans l’histoire.
  • Si vous êtes un type systématique et que vous avez des premières étapes typiques dans vos projets, leur utilisation en tant que points de validation peut être une instruction pour vous ou pour d’autres, et peut même être l’occasion de créer une branche à un moment donné et de créer un talon de projet réutilisable. J'ai travaillé sur des projets basés sur Maven où cela était utile (car lors de la mise en place d'un projet Maven, certaines petites étapes initiales peuvent déjà définir une base assez substantielle, et bien que ces étapes ne soient pas très complexes , elles peuvent nécessiter suffisamment de réflexion pour être justifiées. réutilisabilité).

2

Cela peut dépendre du VCS que vous utilisez.

Avec Git, je valide un répertoire vide (ou avec un fichier README presque vide). Le fait est que je peux revenir en arrière et réinitialiser ma branche à cet état vide si je veux tout recommencer à zéro alors que je suis encore au début du processus de développement (avant de passer en amont). Je commettrais ensuite mes fichiers "générés" (solution Visual Studio, par exemple). Ensuite, lorsque je coderai, je commencerai à engager chaque unité comme vous le feriez normalement.

Avec SVN, vous vous engagez en amont avec chaque engagement, vous n'avez donc pas le luxe de recommencer à zéro, comme vous le faites avec Git. Dans ce cas, il ne serait peut-être pas avantageux de vous engager tôt si vous pensez procéder à une refonte majeure au tout début du processus. Ce sera à la personne de coder si.


2

Lorsque je commence un nouveau projet, je commence généralement par le commettre avant l'ajout de code. Une règle générale que j'ai toujours suivie est la suivante: si votre PC tombe en panne et efface toutes vos données, quel code préféreriez-vous ne pas avoir à écrire de la mémoire. Il y a dix ans, avant TDD et de meilleures pratiques de programmation, j'étais plutôt optimiste quant à ce dont je pouvais me souvenir. Maintenant, j'ai tendance à être plus prudent. Comme beaucoup d'autres affiches ont déclaré s'engager tôt et souvent. Vous ne perdez rien en le faisant.

Je travaille toute seule la plupart du temps, donc je dois avouer que je commence à me relâcher, mais je m'engage généralement avant de rentrer chez moi. Ainsi, si je ne pars pas demain, mes collègues pourront reprendre là où je me suis arrêté.

J'utilise actuellement Tortoise / SVN au travail.


2

Commettez le projet vide tout de suite. Continuez à vous engager plusieurs fois par heure de travail sur le projet. S'engager même si le code ne compile pas. Je marque de tels commets avec "WIP" dans le massage commit pour les suivre.

J'ai également un script qui valide automatiquement tous mes projets toutes les 10 minutes dans un référentiel de sauvegarde, au cas où j'oublierais de valider manuellement. Appelons cela mon tampon d'annulation annulé.

Arrivée (aka. Pousser ) le projet d'une prise en pension d'équipe lorsque vous avez besoin de votre équipe pour voir votre code. Ce qui est probablement avant que votre code soit prêt à être lu par votre équipe, si vous ressemblez à moi.

Si vous voulez être gentil avec votre équipe, écrasez vos commits avant de les pousser vers le dépôt de l'équipe.


1

J'ai parcouru tous les articles et je pense que nous avons déjà beaucoup de bonnes solutions, mais j'aimerais partager ma méthodologie avec vous.

Tout en travaillant sur la création de framework (à partir de zéro), de nombreux changements vont avoir lieu pour chaque module jusqu'à ce que le module soit terminé ou finalisé. J'ai donc toujours 2 sites, l'un nommé DYNAMIC et l'autre STATIC. Lorsque des modifications sont en cours et que le cadre n’est pas encore finalisé, il a été validé à l’emplacement DYANMIC et, une fois terminé et finalisé, je le déplace vers l’emplacement STATIC. J'ai donc un contrôle de source complet.

Merci


0

Quelle que soit l'application, vous passerez un certain temps à concevoir les composants. Vous devez connaître, en gros ou en détail, vos espaces de noms, projets, références externes, bibliothèques tierces, etc.

Si vous faites partie d'une équipe, je suggérerais à votre responsable, ou à celui qui est choisi, de créer le projet de base, de définir le jeu de dépendances et de vérifier le squelette (la fondation sur laquelle votre projet sera construit).

Vous voulez également vous assurer que vos tâches, libérations, troncs, etc., sont spécifiés avant l'archivage afin que votre processus soit solide.

Si vous travaillez sur une nouvelle "tâche" pour un projet déjà en cours et que vous êtes dans votre propre branche de tâche, effectuez vos enregistrements nocturnes afin de préserver votre travail.


0

En général, j’enregistre à chaque fois que j’ajoute quelque chose de nouveau, mais j’essaie de séparer les choses en commets discrets.

Cela signifie que si j'ajoute une nouvelle dépendance, je modifie les modifications jusqu'à ce qu'elles soient compilées ou suffisamment grandes pour qu'il soit trop tard pour les refaire, à partir de zéro. Si j'ai une tâche plus importante, j'essaye de valider plusieurs fois, quand cela se justifie (une fois par fonction, chaque fois que je le compile et qu'il s'exécute correctement, etc.).

Je m'engage également lorsque je veux un point de sauvegarde (par exemple, "si ce que j'essaie maintenant ne fonctionne pas ou devient trop compliqué, je veux revenir au code tel qu'il est actuellement", ou lorsque quelqu'un me demande de laisser tomber ce que je suis. faire et résoudre un problème urgent).

Si vous utilisez un système de contrôle de source centralisé, vous ne pouvez pas valider de manière arbitraire des points de sauvegarde, car une validation qui ne compile / fonctionne pas affecte tous les membres de votre équipe.

Habituellement, lorsque je commence à ajouter du code passe-partout (par exemple, ajouter une nouvelle application Web sur un site Web Django), je commets toutes les opérations que je fais.

Si je suis un didacticiel pour générer / écrire du code, j'utilise des noms d'étape dans le didacticiel pour les messages de validation. De cette façon, je peux comparer les révisions et voir ce qu’a fait une étape de tutoriel à tout moment.

Disons, par exemple, que j'ai un projet qui consiste en un seul fichier de code. Il faudra environ 10 lignes de code standard et 100 lignes pour que le projet fonctionne avec des fonctionnalités extrêmement basiques (1 ou 2 fonctionnalités).

Cela dépend de la difficulté d'ajouter des éléments:

  • s’il était trivial d’ajouter le code de la plaque de la chaudière, j’ajouterais le code et l’engage juste avant de commencer sur l’autre code (de cette façon, si je fais une erreur ou si j’introduis un bogue étrange plus tard, je peux simplement revenir au code standard et commencer encore).

  • Si le code n'était pas trivial, je commettrais chaque fois que j'ajoutais quelque chose de nouveau (n'importe où entre deux lignes de code modifiées, environ une centaine).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.