Quel est le meilleur processus de révision de code lors de lutilisation de GIT? Nous avons un fournisseur GIT externe (Unfuddle) et avons des limites sur lutilisation des ressources – nous ne pouvons donc pas avoir de dépôts distants dédiés pour chaque développement.
Processus actuel:
- Nous avoir un serveur GIT avec une branche
masterà laquelle tout le monde sengage - Les développeurs travaillent sur le miroir
masterlocal ou branche de fonctionnalité locale - Les développeurs poussent vers la branche
masterdu serveur - Les développeurs demandent la révision du code lors de la dernière validation
Problème:
- Tout bogue dans la révision du code est déjà dans master au moment où il est détecté.
- Pire, généralement quelquun a brûlé quelques heures en essayant pour comprendre ce qui sest passé …
Donc, nous aimerions
- Faire une révision du code AVANT la livraison dans le « maître ».
- Avoir un processus qui fonctionne avec une équipe mondiale (pas de avis sur l’épaule !)
- quelque chose qui n’exige pas qu’un développeur individuel soit à son bureau / machine être mis sous tension pour que quelquun dautre puisse à distance je n (supprimer les dépendances humaines, les développeurs rentrent chez eux à des fuseaux horaires différents)
Nous utilisons TortoiseGIT pour une représentation visuelle dune liste de fichiers modifiés, de fichiers différents, etc. Certains dentre nous tombent dans un Shell GIT lorsque linterface graphique nest pas suffisante, mais idéalement, nous aimerions que le flux de travail soit simple et basé sur linterface graphique (je veux que loutil soulève nimporte quel fardeau, pas mes développeurs).
Commentaires
- Faites-vous un test unitaire avant de vous engager?
- @GuyCoder: Nous le faisons surtout.
- Si votre hébergeur ne fournit pas de révision de code capacité, obtenez un meilleur hôte. Jetez un œil à Gerrit et voyez si vous pouvez trouver un hôte qui le fournit.
Réponse
A Le modèle simple mais efficace est le modèle GitHub pull request , où les demandes des contributeurs « veuillez fusionner dans mon code ». Un responsable examine les ensembles de modifications et décide sils ont besoin de plus de travail ou sils sont adaptés à la fusion. Il peut alors fusionner dans la branche principale. Les committers ne sont généralement pas autorisés à pousser directement vers la branche master (cela peut être personnalisé selon vos goûts, nous autorisons les commits « mineurs » à entrer directement).
Commentaires
- Nous avons une équipe restreinte de 7 développeurs professionnels (vs contributeurs anonymes) dans le monde, il est donc prudent de laisser chacun pousser directement vers notre maître distant. Bien que ce ' soit un lien + une intro vs une réponse autonome que je préfère, dans ce cas, cela a du sens. Excellente rédaction au lien, merci!
- @Sid Avec une équipe de 3, je ne ' pas les laisser tous pousser vers le maître.
- Les demandes dextraction sont également disponibles dans Rhodecode et Atlassian Stash
- @Andrew: Pourquoi pas? Il existe de nombreux problèmes qui peuvent être générés en canalisant le travail des équipes entières via un point détranglement. Tout cela peut être atténué, mais une structure de commande et de contrôle en un seul point est plus adaptée à certaines situations quà dautres.
Réponse
Git est un système de contrôle de version distribué: ne pas avoir quun seul référentiel avec une branche!
Vous pouvez configurer plusieurs référentiels – un pour chaque développeur – et un autre qui est le référentiel maître. Lorsquune de leurs branches est prête à être fusionnée, le développeur demande une fusion et ses modifications sont extraites de sa branche / dépôt dans le master.
Avant que cette fusion ne se produise, le réviseur peut intégrer les modifications dans leur environnement, et passez-les en revue avant de les pousser à maîtriser.
Les avantages supplémentaires sont que de cette façon, un développeur peut avoir autant de branches quil le souhaite, nommées comme il veut, sans interférer les uns avec les autres ni même avoir pour voir autant le linge sale de lautre.
Aussi, apprenez le jargon: par « Les développeurs sengagent dans la branche principale du serveur » voulez-vous dire quils envoyer leurs modifications au maître?
Commentaires
- ouais, ils
pushleur travail. Nous ne pouvons ' t avoir des dépôts distants uniques sur le serveur GIT car nous payons un hébergeur GIT et ils facturent par dépôt. Voulez-vous dire avoir plusieurs succursales distantes par développeur? Et quand vous ditesthe reviewer can pull the changes into their environmentquelles commandes GIT exactes (ou flux TortoiseGIT) voulez-vous dire? - Non, je veux dire avoir plusieurs dépôts; un par développeur, et sur ce référentiel, ils peuvent avoir autant de branches quils le souhaitent. Quant à
pull, je ne sais ' quelle serait la commande dans TortoiseGIT – mais la commande est git pull . Cest ' lopposé dun push – vous extrayez les modifications du référentiel distant pour mettre à jour votre environnement avec le travail que dautres développeurs auraient pu faire. - Je sais
git pull🙂 …Je demandais la syntaxe complète pour inspecter le système repo / branch / tag pour les push / pulls auxquels vous faisiez référence. En ce moment, nous faisonsgit pullde toute façon, il ' est juste à côté de remote: master – ce qui cause les problèmes. Quoi quil en soit, les liens de Steven ' étaient super. Merci - À toutes fins pratiques, dans ce cas, une branche du dépôt hébergé est exactement la même chose quun autre dépôt.