J'utilise git pour des projets personnels et je pense que c'est génial. Il est rapide, flexible, puissant et fonctionne parfaitement pour le développement à distance.
Mais maintenant, c'est obligatoire au travail et, franchement, nous avons des problèmes.
Hors de la boîte, git ne semble pas bien fonctionner pour le développement centralisé dans une grande organisation (plus de 20 développeurs) avec des développeurs de capacités et de niveaux de sophistication variables - en particulier par rapport à d'autres systèmes de contrôle de source comme Perforce ou Subversion, qui visent ce genre d'environnement. (Oui, je sais, Linus ne l'a jamais prévu pour ça.)
Mais - pour des raisons politiques - nous sommes coincés avec git, même si ça craint ce que nous essayons d'en faire.
Voici quelques-unes des choses que nous voyons:
- Les outils de l'interface graphique ne sont pas matures
- En utilisant les outils de ligne de commande, il est beaucoup trop facile de bousiller une fusion et d'effacer les modifications de quelqu'un d'autre
- Il n'offre pas d'autorisations de référentiel par utilisateur au-delà des privilèges globaux en lecture seule ou en lecture-écriture
- Si vous avez une autorisation sur N'IMPORTE QUELLE partie d'un référentiel, vous pouvez faire la même chose pour CHAQUE partie du référentiel, vous ne pouvez donc pas faire quelque chose comme créer une branche de suivi en petit groupe sur le serveur central que d'autres personnes ne peuvent pas jouer avec.
- Les workflows autres que "tout va bien" ou "dictateur bienveillant" sont difficiles à encourager, encore moins à appliquer
- Il n'est pas clair s'il vaut mieux utiliser un seul grand référentiel (qui permet à tout le monde de tout gâcher) ou beaucoup de référentiels par composant (ce qui crée des maux de tête pour essayer de synchroniser les versions).
- Avec plusieurs référentiels, il n'est pas clair non plus comment répliquer toutes les sources de quelqu'un d'autre en extrayant du référentiel central, ou faire quelque chose comme tout récupérer à partir de 4h30 hier après-midi.
Cependant, j'ai entendu dire que les gens utilisent git avec succès dans les grandes organisations de développement.
Si vous êtes dans cette situation - ou si vous avez généralement des outils, des conseils et des astuces pour rendre l'utilisation de git plus facile et plus productive dans une grande organisation où certaines personnes ne sont pas des fans de ligne de commande - j'aimerais savoir ce que vous avez suggérer.
BTW, j'ai déjà posé une version de cette question sur LinkedIn, et je n'ai pas obtenu de vraies réponses, mais beaucoup de "bon sang, j'aimerais savoir ça aussi!"
MISE À JOUR: Permettez-moi de clarifier ...
Là où je travaille, nous ne pouvons rien utiliser d'autre que git . Ce n'est pas une option. Nous sommes coincés avec ça. Nous ne pouvons pas utiliser mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, ou même le bon vieux projecteur d'Apple que j'ai utilisé en 1987. Donc, même si vous êtes invité à discuter d'autres options, vous n'obtiendrez pas la prime si vous ne discutez pas de git.
De plus, je recherche des conseils pratiques sur l'utilisation de git dans l'entreprise . Je mets toute une liste de problèmes que nous rencontrons en haut de cette question. Encore une fois, les gens sont invités à discuter de théorie, mais si vous voulez gagner la prime, donnez-moi des solutions.
a process
... (je déteste ce mot)