Comment les DVC sont-ils utilisés dans les grandes équipes?

Mon équipe de mon ancien employeur utilisait Git, et cela a bien fonctionné pour nous. Nous n'étions pas si grands (peut-être 16 ou plus, avec peut-être 8 committers vraiment actifs?), mais j'ai des réponses à vos questions:

1. les fusions n-Way NE sont pas très courantes. Nous avons trouvé quelques conventions sur la dénomination des branches qui nous ont permis d'écrire des scripts qui ont facilité le processus" release engineering " (j'utilise des citations effrayantes parce que nous n'avions pas d'ingénieur de publication), et les gens créaient des branches de fonctionnalités privées, mais nous avons rarement eu un problème avec la fusion de plus de deux branches (voir le prochain).
2. (et #3). Nous avions un référentiel central sur un serveur de développement pour trois raisons: (a) la machine de développement avait un RAID5 (plus tolérant aux pannes) et des sauvegardes nocturnes (les postes de travail de développement n'étaient pas nocturnes), (B) les versions de production étaient construites sur le serveur de développement et (c) un référentiel central simplifiait les scripts. En conséquence, les fusions n-way ne se sont tout simplement jamais produites. La chose la plus proche que nous avions À N-way a quand quelqu'un a fusionné latéralement, puis fusionnées verticalement.

Git était vraiment une bonne chose pour nous en raison de son haut degré de flexibilité; cependant, nous avons dû établir des conventions (noms de branches et de balises, emplacements de repo, scripts, etc., processus) ou cela aurait pu être un peu chaotique. Une fois que nous avons mis en place les conventions, La flexibilité que nous avions était tout simplement fantastique.

Update: nos conventions étaient donc essentiellement:

• un répertoire sur notre serveur NFS qui logé tous les dépôts centraux
• nous avions plusieurs projets qui partageaient des composants, donc nous les avons divisés en bibliothèques, essentiellement, avec leurs propres dépôts, et les projets livrables les ont simplement inclus en tant que sous-modules git.
• Il y avait des chaînes de version et des noms de version qui nous étaient imposés d'en haut, Donc nous avons juste utilisé des variantes de celles-ci comme noms de branche
• de même, pour les tags, ils ont suivi les noms de version dictés par le processus
• les projets livrables contenaient un fichier de propriétés que j'ai lu dans les scripts shell, et qui m'a permis d'écrire un seul script pour gérer le processus de publication pour tous les projets, même si chacun avait de légères variations sur le processus-les variations ont été prises en compte dans ces fichiers de propriétés
• j'ai écrit des scripts qui reconstruiraient un paquet livrable à partir de n'importe quelle balise
• l'utilisation de git nous a permis de contrôler L'accès en utilisant PAM et / ou les autorisations utilisateur normales (ssh, etc)
• Il y avait d'autres conventions qui sont plus difficile à mettre dans une liste à puces, comme quand les fusions devraient se produire. Vraiment, moi et un autre gars étions en quelque sorte les "gourous git" internes, et nous avons aidé tout le monde à comprendre comment utiliser les branches et quand fusionner.
• amener les gens à s'engager en petits morceaux et à ne pas laisser tomber des bombes diff dans la branche master était un défi. Un gars a laissé tomber environ deux semaines solides de travail en un seul engagement, et nous avons finalement dû démêler tout. Unénorme perte de temps, et frustrant de tout.
• commentaires informatifs et détaillés pour aller avec commits

Il y a d'autres choses que vous apprenez à mesure que votre équipe est expérimentée et apprend à travailler les uns avec les autres, mais cela a suffi pour nous aider à démarrer.

Update : tous ceux qui suivent de telles choses le savent déjà, mais Vincent Dreissen a écrit une version solide et assez complète (mais pas exaustive) sur l'ingénierie de branchement et de publication en utilisant Git . J'aimerai fortement encourager en utilisant son processus comme point de départ parce que pour deux raisons:

• beaucoup d'équipes le font de cette façon ou utilisent une variante proche (y compris Linux, Git et de nombreuses autres équipes de projet OSS), ce qui signifie que cette méthode a été testée et modifiée pour réussir dans la plupart des circonstances. Il est très peu probable que vous fassiez face à un problème qui n'a pas été rencontré et résolu dans les contraintes de ce modèle.
• en raison de ce qui précède, presque tout ingénieur ayant une expérience Git comprendra ce qui se passe. Vous n'aurez pas à écrire de documentation détaillée sur la nature fondamentale de votre processus de publication; vous n'aurez qu'à documenter des éléments spécifiques à votre projet ou à votre équipe.