Tout en évaluant les avantages et les inconvénients de la déplacement de notre référentiel basé sur la subversion sur Git, une question intéressante est arrivée.
Même si nous sommes tout à fait friands de GIT, il pourrait arriver que certains développeurs (ou une équipe de développeurs) oublient de pousser une fonctionnalité / bugfix sur le référentiel à partir de laquelle les packages sont construits.
Je suis sûr que cette préoccupation a déjà été soulevée dans d'autres équipes de développement de logiciels, je me demandais comment vous avez abordé ce problème.
4 Réponses :
De la même manière que vous traitez avec des personnes qui travaillent pendant une semaine dans leur copie de travail locale SVN sans s'engager.
C'est le même problème exact.
Ce n'est pas tout à fait la même chose. Avec Git, il est beaucoup plus facile de résoudre le problème qu'avec SVN.
@WILLIAM - J'aurais probablement résoudre le problème en balançant une indice d'indice à quatre à la tête de Dev de la pertinence. Même niveau d'effort de toute façon ...;)
Je ne suis pas d'accord pour dire que c'est la même chose. Un «commit» à Subversion est très différent d'un engagement dans Git. Avec Git, il est parfaitement logique de commettre des choses cassées / expérimentales / folles, de sorte que vous le faites très souvent. Ce n'est pas le cas avec subversion. Si mentalement, faire un commit est détaché de «publier votre travail».
@Frerich - un «commit» dans la subversion est la même chose qu'un «push» dans Git; Et vous demandiez comment traiter les Devs qui ne poussent pas. Donc, vous traitez de la même manière que quelqu'un qui ne s'engage pas à Subversion. En ce qui concerne la validation de changements expérimentaux, c'est ce que sont les succursales de Dev, même en subversion.
@retracttile: un "commit" dans Subversion est techniquement (plus ou moins) équivalent à un "push" dans git. Ce dont je parle est la perception d'un commit dans Git. C'est une opération facile, il peut être annulé, il peut être réécrit, ce n'est pas visible pour les autres en soi. Donc, vous faites cela tout le temps en git, mais vous ne le faites pas en subversion. Avec Git, il est facile de développer des fonctionnalités avec vos pairs et d'oublier de publier vos modifications à l'hôte du bâtiment du package.
"Mais vous ne le faites pas en subversion", sauf que je le fais; Toutes ces choses que vous vous engagez dans Git, je vous engage également dans SVN, sur les branches. Fondamentalement, c'est un problème social - enseigne à votre DevS de pousser leur travail sur le serveur régulièrement (pas seulement "quand il est prêt"); Obtenez-les à l'aise avec des branches afin qu'ils puissent le faire sans interférer avec les autres. Qu'ils utilisent SVN ou GIT ne changent pas le problème social; juste les détails techniques. Jusqu'à ce qu'il soit sur le serveur, il n'existe pas.
Bien qu'il existe des solutions techniques, c'est vraiment un problème social. Je commencerais par parler avec les développeurs et leur expliquer qu'ils fonctionnent essentiellement de manière isolée du reste du projet. Cet isolement est un risque pour le projet. N'oubliez pas que ce n'est probablement pas l'ignorance volontaire. Ils oublient simplement qu'un commit ne va plus au serveur central SVN.
Je suis d'accord que, idéalement, vous pouvez résoudre ce problème simplement en essayant de donner de nombreux rappels. Quelques réflexions diverses:
Tout ce qui renforce l'idée de contrôle de la version distribuée aidera à faire en sorte que les gens y réfléchiront plus naturellement. Par exemple, je suis favorable à un flux de travail qui inclut l'utilisation de succursales locales et de modifier / rebasting engage jusqu'à ce que je veux exactement. Si vous enseignez comment faire cela, il devient évident que ce sont des choses dans votre propre région. À mesure que les développeurs deviennent plus conscients que leur repo est différent de celui central, rappelez-vous d'appuyer pour pousser beaucoup plus facilement.
Si vous êtes sur votre branche principale (ou une autre branche qui suit une succursale d'origine), Vous pourriez, si vous vouliez vraiment, écrivez un crochet post-validation qui notifie simplement à l'utilisateur à quelle distance ils ont divergé de l'origine. Il existe de nombreuses façons de l'approcher, en fonction de votre flux de travail - peut-être simplement dupliquer ce message de statut, trouver peut-être le plus ancien commit sur la branche actuelle qui n'est pas d'origine, vous pouvez leur faire savoir combien de temps ça a été ... Notez que, y compris les crochets avec le référentiel, n'est pas trivial: .git / hameçons n'est pas suivi, vous devez donc symboliser le répertoire ou les crochets à l'intérieur du repo. Cela peut être automatisé par un script d'installation, cependant, ce n'est pas trop mauvais!
Statut Git-Statut vous donnera des rappels comme "Votre succursale est en avance sur" / Maître 'par 1 commit. " Vous verrez également cela lorsque vous vérifiez le maître.
Accepter cette réponse depuis que j'aime vraiment l'idée de crochet post-validation.
Faire une seule personne (chef de projet) responsable de la tirage d'autres devs.
C'est une très bonne idée. C'est beaucoup plus sûr également parce que le responsable technique peut examiner les codes avant qu'ils ne soient contrôlés dans le dépôt béni.
Un problème avec ceci est qu'il peut avoir tendance à supprimer la capacité de forcer les mises à jour pour être rapides. Une modification peut être basée sur l'origine / maître lorsque le développement le fait, mais lorsque l'intégrateur le tire, il peut y avoir plusieurs modifications de ce type d'autres Devs. L'histoire devient alors moins linéaire et l'intégrateur doit effectuer de vraies fantasmes. Et bien sûr, il enlève l'un des principaux avantages de permettre de pousser - libérer le temps précieux de quelqu'un pour faire de véritables travaux au lieu de l'intégration.
Cela fonctionnerait probablement, mais nous sommes très brefs sur la main-d'œuvre. Je préfère donc diffuser les responsabilités sur tous les développeurs au lieu de la concentrer sur une personne. Surtout depuis que le «chef de projet» ne peut souvent pas dire quels changements sont prêts à être tirés et qui ne sont pas.