Contrôle de code source basé sur Git dans l'entreprise: outils et pratiques suggérés?

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.

Contre l'opinion commune, je pense que l'utilisation d'un DVCS est un choix idéal dans un environnement d'entreprise car il permet des flux de travail très flexibles. Je parlerai d'abord de l'utilisation d'un DVCS vs CVCS, des meilleures pratiques et ensuite de git en particulier.

DVCS vs CVCS dans un contexte d'entreprise:

Je ne parlerai pas ici des avantages / inconvénients généraux, mais plutôt de votre contexte. C'est la conception courante, que l'utilisation d'un DVCS nécessite une équipe plus disciplinée que l'utilisation d'un système centralisé. En effet, un système centralisé vous offre un moyen simple d' appliquer votre flux de travail, l'utilisation d'un système décentralisé nécessite plus de communication et de discipline pour respecter les conventions établies. Bien que cela puisse sembler induire des frais généraux, je vois un avantage dans la communication accrue nécessaire pour en faire un bon processus. Votre équipe devra communiquer sur le code, sur les changements et sur l'état du projet en général.

Une autre dimension dans le contexte de la discipline est d'encourager les branchements et les expériences. Voici une citation de l'entrée bliki récente de Martin Fowler sur les outils de contrôle de version , il a trouvé une description très concise de ce phénomène.

DVCS encourage le branchement rapide pour l'expérimentation. Vous pouvez créer des branches dans Subversion, mais le fait qu'elles soient visibles de tous décourage les gens d'ouvrir une branche pour le travail expérimental. De même, un DVCS encourage le pointage du travail: la validation de modifications incomplètes, qui peuvent même ne pas compiler ou passer des tests, dans votre référentiel local. Encore une fois, vous pouvez le faire sur une branche de développeur dans Subversion, mais le fait que de telles branches se trouvent dans l'espace partagé rend les gens moins susceptibles de le faire.

DVCS permet des flux de travail flexibles car ils fournissent un suivi des modifications via des identificateurs uniques au monde dans un graphe acyclique dirigé (DAG) au lieu de simples différences textuelles. Cela leur permet de suivre de manière transparente l'origine et l'historique d'un ensemble de modifications, ce qui peut être très important.

Flux de travail:

Larry Osterman (un développeur Microsoft travaillant dans l'équipe Windows) a publié un excellent article sur le flux de travail qu'ils emploient dans l'équipe Windows. Plus particulièrement, ils ont:

• Un coffre de code propre et de haute qualité uniquement (repo principal)
• Tout le développement se produit sur des branches de fonctionnalités
• Les équipes de fonctionnalité ont des dépôts d'équipe
• Ils fusionnent régulièrement les dernières modifications du tronc dans leur branche de fonctionnalités ( Forward Integrate )
• Les fonctionnalités complètes doivent passer plusieurs critères de qualité, par exemple examen, couverture de test, questions et réponses (repos indépendant)
• Si une fonction est terminée et a une qualité acceptable, elle est fusionnée dans le coffre ( Reverse Integrate )

Comme vous pouvez le voir, en ayant chacun de ces référentiels en direct, vous pouvez découpler différentes équipes qui avancent à des rythmes différents. De plus, la possibilité de mettre en œuvre un système de porte de qualité flexible distingue DVCS d'un CVCS. Vous pouvez également résoudre vos problèmes d'autorisation à ce niveau. Seule une poignée de personnes devrait être autorisée à accéder au repo principal. Pour chaque niveau de la hiérarchie, disposez d'un référentiel séparé avec les stratégies d'accès correspondantes. En effet, cette approche peut être très flexible au niveau de l'équipe. Vous devez laisser à chaque équipe le soin de décider si elle souhaite partager son repo d'équipe entre elle ou si elle souhaite une approche plus hiérarchique où seul le chef d'équipe peut s'engager dans le repo d'équipe.

(L'image a été volée sur hginit.com de Joel Spolsky .)

Une chose reste à dire à ce stade cependant: - même si DVCS offre d'excellentes capacités de fusion, cela ne remplace jamais l' utilisation de l'intégration continue. Même à ce stade, vous disposez d'une grande flexibilité: CI pour le dépôt de tronc, CI pour les repos d'équipe, les dépôts de questions-réponses, etc.

Git dans un contexte d'entreprise:

Git n'est peut-être pas la solution idéale pour un contexte d'entreprise comme vous l'avez déjà souligné. Répétant certaines de vos préoccupations, je pense que ce sont surtout les suivantes:

• Support encore un peu immature sur Windows (veuillez me corriger si cela a changé récemment) Maintenant, Windows a le client Windows github , tortoisegit , SourceTree d'atlassian
• Manque d'outils GUI matures, pas d'intégration d'outil de vdiff / fusion citoyen de première classe
• Interface incohérente avec un très faible niveau d'abstractions en plus de son fonctionnement interne
• Une courbe d'apprentissage très abrupte pour les utilisateurs svn
• Git est très puissant et facilite la modification de l'historique, très dangereux si vous ne savez pas ce que vous faites (et vous le ferez parfois même si vous pensiez le savoir)
• Aucune option d'assistance commerciale disponible

Je ne veux pas démarrer un git vs hg flamewar ici, vous avez déjà fait le bon pas en passant à un DVCS. Mercurial aborde certains des points ci-dessus et je pense qu'il est donc mieux adapté dans un contexte d'entreprise:

• Toutes les plates-formes qui exécutent python sont prises en charge
• Grands outils d'interface graphique sur toutes les principales plates-formes (win / linux / OS X), intégration d'outils de première classe merge / vdiff
• Interface très cohérente, transition facile pour les utilisateurs svn
• Peut faire la plupart des choses que git peut faire aussi, mais fournit une abstraction plus claire. Les opérations dangereuses sont toujours explicites. Les fonctionnalités avancées sont fournies via des extensions qui doivent être explicitement activées.
• Un support commercial est disponible auprès de selenic.

En bref, lorsque vous utilisez DVCS dans une entreprise, je pense qu'il est important de choisir un outil qui introduit le moins de friction. Pour que la transition soit réussie, il est particulièrement important de prendre en compte les compétences variables entre les développeurs (en ce qui concerne VCS).

Réduire la friction:

Ok, puisque vous semblez vraiment coincé avec la situation, il reste deux options à mon humble avis. Il n'y a pas d'outil pour rendre git moins compliqué; git est compliqué. Soit vous vous confrontez à cela, soit vous travaillez autour de git: -

1. Obtenez un cours d'introduction à git pour toute l'équipe. Cela ne devrait inclure que les bases et quelques exercices (important!).
2. Convertissez le référentiel maître en svn et laissez le "young-stars" git-svn . Cela donne à la plupart des développeurs une interface facile à utiliser et peut compenser le manque de discipline de votre équipe, tandis que les jeunes stars peuvent continuer à utiliser git pour leurs propres dépôts.

Pour être honnête, je pense que vous avez vraiment un problème de personnes plutôt qu'un problème d'outil. Que peut-on faire pour améliorer cette situation?

• Vous devez indiquer clairement que vous pensez que votre processus actuel aboutira à une base de code maintenable.
• Investissez du temps dans l'intégration continue. Comme je l'ai expliqué ci-dessus, quel que soit le type de VCS que vous utilisez, il n'y a jamais de remplacement pour CI. Vous avez déclaré qu'il y a des gens qui poussent de la merde dans le référentiel principal: demandez-leur de réparer leur merde pendant qu'une alerte rouge se déclenche et les blâme pour avoir cassé la construction (ou ne pas répondre à une métrique de qualité ou autre).

Je suis l'ingénieur SCM pour une organisation de développement assez grande, et nous sommes passés à git de svn au cours de la dernière année. Nous l'utilisons de manière centralisée.

Nous utilisons gitosis pour héberger les référentiels. Nous avons divisé nos dépôts svn monolithiques en de nombreux dépôts git plus petits car l'unité de branchement de git est essentiellement le dépôt. (Il existe des moyens de contourner cela, mais ils sont gênants.) Si vous voulez des types de contrôles d'accès par branche, gitolite pourrait être une meilleure approche. Il existe également une version à l'intérieur du pare-feu de GitHub si vous souhaitez dépenser de l'argent. Pour nos besoins, gitosis convient car nous avons des autorisations assez ouvertes sur nos référentiels. (Nous avons des groupes de personnes qui ont un accès en écriture à des groupes de référentiels, et tout le monde a un accès en lecture à tous les référentiels.) Nous utilisons gitweb pour une interface Web.

Quant à certaines de vos préoccupations spécifiques:

• fusion: vous pouvez utiliser un outil de fusion visuelle de votre choix; il y a des instructions à divers endroits sur la façon de le configurer. Le fait que vous puissiez faire la fusion et vérifier sa validité totalement sur votre dépôt local est, à mon avis, un avantage majeur pour git; vous pouvez vérifier la fusion avant de pousser quoi que ce soit.
• IHM: Nous avons quelques personnes qui utilisent TortoiseGit mais je ne le recommande pas vraiment; il semble interagir de manière étrange avec la ligne de commande. Je dois admettre que c'est un domaine qui doit être amélioré. (Cela dit, je ne suis pas fan des interfaces graphiques pour le contrôle de version en général.)
• branches de suivi en petit groupe: si vous utilisez quelque chose qui fournit des ACL plus fines comme gitolite, c'est assez facile de le faire, mais vous pouvez également créer une branche partagée en connectant les référentiels locaux de divers développeurs - un dépôt git peut avoir plusieurs télécommandes.

Nous sommes passés à git parce que nous avons beaucoup de développeurs distants et parce que nous avons eu de nombreux problèmes avec Subversion. Nous expérimentons toujours des flux de travail, mais pour le moment, nous l'utilisons essentiellement de la même manière que nous utilisions Subversion. Une autre chose qui nous a plu, c'est qu'il a ouvert d'autres flux de travail possibles, comme l'utilisation de référentiels de préparation pour la révision du code et le partage de code entre petits groupes. Cela a également encouragé de nombreuses personnes à commencer à suivre leurs scripts personnels et ainsi de suite, car il est si facile de créer un référentiel.

Oui, je sais, Linus ne l'a jamais prévu pour ça.

En fait, Linus soutient que les systèmes centralisés ne peuvent tout simplement pas fonctionner.

Et quel est le problème avec le flux de travail du dictateur et des lieutenants?

Rappelez-vous, git est un système distribué ; n'essayez pas de l'utiliser comme un central.

(actualisé)

La plupart de vos problèmes disparaîtront si vous n'essayez pas d'utiliser git comme s'il s'agissait de "svn on steroids" (car ce n'est pas le cas).

Au lieu d'utiliser un référentiel nu comme serveur central vers lequel tout le monde peut pousser (et potentiellement bousiller), configurez quelques gestionnaires d'intégration qui gèrent les fusions, de sorte qu'eux seuls puissent pousser vers le référentiel nu.

Habituellement, ces personnes devraient être les chefs d'équipe: chaque chef intègre le travail de sa propre équipe et le pousse vers le référentiel béni.

Mieux encore, quelqu'un d'autre (c'est-à-dire un dictateur) tire parti des chefs d'équipe et intègre leurs changements dans le référentiel béni.

Il n'y a rien de mal avec ce flux de travail, mais nous sommes une startup surchargée de travail et avons besoin de nos outils pour se substituer au temps et à l'attention humains; personne n'a la bande passante pour faire des révisions de code, encore moins être un dictateur bienveillant.

Si les intégrateurs n'ont pas le temps de réviser le code, c'est bien, mais vous avez toujours besoin de personnes qui intègrent les fusions de tout le monde.

Faire des pulls git ne prend pas beaucoup de temps.

git pull A
git pull B
git pull C

git ne remplace le temps humain et l' attention; c'est pourquoi il a été écrit en premier lieu.

• Les outils de l'interface graphique ne sont pas matures

Les outils d'interface graphique peuvent très bien gérer les éléments de base.

Les opérations avancées nécessitent une mentalité de codeur / nerdy (par exemple, je suis à l'aise pour travailler à partir de la ligne de commande). Il faut un peu de temps pour comprendre les concepts, mais ce n'est pas si difficile.

• 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

Ce ne sera pas un problème à moins que vous n'ayez de nombreux développeurs incompétents avec un accès complet en écriture au "dépôt central".

Mais si vous configurez votre flux de travail de sorte que seules quelques personnes (intégrateurs) écrivent dans le référentiel "béni", ce ne sera pas un problème.

Git ne permet pas de gâcher les fusions facilement.

Quand il y a des conflits de fusion, git marquera clairement les lignes en conflit afin que vous sachiez quels changements sont les vôtres et lesquels ne le sont pas.

Il est également facile d'effacer le code d'autres personnes avec svn ou tout autre outil (non distribué). En fait, c'est beaucoup plus facile avec ces autres outils parce que vous avez tendance à "vous asseoir sur les changements" pendant une longue période et à un moment donné, les fusions peuvent devenir terriblement difficiles.

Et comme ces outils ne savent pas comment fusionner, vous devez toujours fusionner les choses manuellement. Par exemple, dès que quelqu'un effectue une validation sur un fichier que vous éditez localement, il sera marqué comme un conflit qui doit être résolu manuellement; maintenant c'est un cauchemar de maintenance.

Avec git, la plupart du temps, il n'y aura pas de conflits de fusion car git peut réellement fusionner. Dans le cas où un conflit se produit, git marquera clairement les lignes pour vous afin que vous sachiez exactement quels changements sont les vôtres et quels changements proviennent d'autres personnes.

Si quelqu'un efface les changements d'autres personnes tout en résolvant un conflit de fusion, ce ne sera pas par erreur: ce sera soit parce que c'était nécessaire pour la résolution du conflit, soit parce qu'ils ne savent pas ce qu'ils font.

• 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

Ces problèmes disparaîtront lorsque vous arrêterez d'essayer d'utiliser git comme s'il s'agissait d'un système centralisé.

• 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).

Appel au jugement.

Quel genre de projets avez-vous?

Par exemple: la version xy du projet A dépend-elle exactement de la version wz du projet B de telle sorte qu'à chaque fois vous vérifiez xy du projet A, vous devez également extraire wz du projet B, sinon il ne sera pas construit? Si c'est le cas, je mettrais à la fois le projet A et le projet B dans le même référentiel, car ils sont évidemment deux parties d'un même projet.

La meilleure pratique ici est d' utiliser votre cerveau

• 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.

Je ne sais pas ce que tu veux dire.

Je recommande vivement http://code.google.com/p/gerrit/ pour le travail en entreprise. Il vous donne un contrôle d'accès et un flux de travail intégré basé sur la révision. Il s'authentifie contre n'importe quel système LDAP. Vous pouvez le connecter à Hudson avec http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , vous permettant de créer et de tester les modifications pendant qu'elles sont encore en cours de révision; c'est une configuration vraiment impressionnante.

Si vous décidez d'utiliser gerrit, je vous recommande d'essayer de garder une histoire assez linéaire, pas une histoire ramifiée comme certains des types open source aiment. Gerrit exprime cela comme "autoriser uniquement les modifications à avance rapide". Ensuite, vous pouvez utiliser le branchement et la fusion plus comme vous en avez l'habitude, pour les versions et ainsi de suite.

Je réponds à cette question sur la base de mon expérience en tant que développeur manager dans une grande entreprise de télécommunications, où nous avons adopté Git en 2010

Vous avez ici un ensemble de problèmes assez différents:

• workflows
• outils clients
• contrôle d'accès au serveur et intégration

Flux de travail

Nous avons adopté avec succès un mode de référentiel central: ce que nous avons dans notre projet d'entreprise (un grand portail pour une base de 5 millions d'utilisateurs) est un référentiel central de facto qui produit les builds officiels puis sont repris dans le processus de livraison (qui, dans notre cas, est composé de trois niveaux de test et de deux déploiements). Chaque développeur gère son propre référentiel, et nous travaillons branche par fonctionnalité.

Outils client

Il y a maintenant plusieurs options disponibles, c'est maintenant une zone très fréquentée. De nombreux développeurs utilisent avec succès IntelliJ Idea et Eclipse avec le plugin Git , sans rien d'autre. De plus, la plupart des développeurs Linux utilisent le client CLI git, sans aucun problème. Certains développeurs Mac utilisent avec succès Tower Git . Veuillez noter qu'aucun de ces clients ne peut empêcher l'utilisateur de «gâcher» le référentiel central: un mécanisme de contrôle côté serveur est nécessaire

Contrôle d'accès et intégration du serveur

Si vous voulez éviter que les développeurs ne «gâchent» votre dépôt Git, vous devez vraiment choisir une solution qui:

• expose une interface d'administration Web décente pour effectuer chaque opération
• vous permet d'appliquer les identités des utilisateurs (l'utilisation d'un référentiel Git "nu" est extrêmement facile à valider au nom de quelqu'un d'autre)
• vous offre une sécurité fine (de sorte que, par exemple, vous pouvez empêcher FORCE-PUSH et définir certaines branches en lecture seule pour certains développeurs / groupes)
• s'intègre à votre système d'authentification d'entreprise (c.-à-d. LDAP, Windows ActiveDirectory)
• vous fournit un audit complet (la conformité SOX est parfois très importante pour les grandes entreprises)

Il n'y a pas tellement de solutions côté serveur prêtes à l'emploi qui peuvent vous aider, je vous suggère de consulter l'une d'entre elles:

• Gitorious : il peut fournir une sécurité de niveau d'accès de base, mais il ne dispose pas d'un contrôle des autorisations finement précis, vous devrez donc probablement coder pour gérer des scénarios tels que les autorisations au niveau de la branche. Il manque également d'intégration avec les mécanismes d'authentification d'entreprise existants
• GitHub Enterprise: récemment publié par GitHub, il intègre GitHub dans votre entreprise. Il manque de conformité SOX et de sécurité à grain fin
• Gerrit : il peut fournir une sécurité de niveau d'accès fine et une intégration avec les systèmes d'authentification d'entreprise, mais il manque de conformité SOX et de SSO. De plus, certaines opérations ne peuvent être effectuées que via SSH via CLI
• GitEnterprise : il fournit des autorisations au niveau de la branche, SSO, conformité SOX, administration Web complète. Il a récemment été également intégré à Gerrit, de sorte qu'il vous fournit également une instance complète de Gerrit

J'espère que cela t'aides!

Il semble que votre problème soit que vous n'avez pas décidé ou institué un flux de travail. Git est suffisamment flexible pour l'utiliser comme svn ou tout autre VCS, mais il est si puissant que si vous n'établissez pas de règles que tout le monde doit suivre, vous allez simplement vous retrouver avec un désordre. Je recommanderais le flux de travail dictateur-lieutenant que quelqu'un a mentionné ci-dessus, mais combiné avec le modèle de branchement décrit par Vincent Driessen . Pour plus d'informations, consultez ces screencasts de David Bock et celui-ci de Mark Derricutt .

Sur les outils , les utilisateurs de MacOS-X trouvent GitX (http://gitx.frim.nl/) très simple et efficace. L'inconvénient est qu'il ne prend pas en charge les hooks Git Client (ceux sous $ GIT_ROOT / .git / hooks).

Dans l'ensemble, je choisis fortement un outil qui prend en charge un contrôle d'accès fin sur: - les branches (afin de séparer les branches de publication stables avec une sécurité stricte des branches de sujet qui nécessitent plus d'agilité et de flexibilité) - l'application de l'identité (auteur / auteur ). Ceci est la clé pour SOX - restrictions des commandes git - piste d'audit. C'est CLÉ pour SOX

Ceux que j'ai utilisés avec succès avec ces fonctionnalités sont:

1. Révision du code Gerrit (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), utilise Gerrit 2.1.8 dans les coulisses

PS Ne sous-estimez pas la conformité SOX et CMMI : souvent, votre choix est limité, dicté par les politiques d'entreprise de votre entreprise en matière de sécurité.

J'espère que cela t'aides.

Luca.

Nous sommes récemment passés de svn à git. Comme git-daemon ne fonctionne pas avec msysgit, nous avons opté pour une approche de référentiel central sur un serveur Linux avec gitosis.

Pour éliminer la possibilité de bousiller le maître, nous l'avons simplement supprimé. Au lieu de cela, nous préparons toutes les versions en fusionnant les branches sélectionnées pour les tests et en marquant la fusion. S'il réussit les tests, le commit est étiqueté avec une version et mis en production.

Pour gérer cela, nous avons un rôle rotatif de gestionnaire de publication. Le responsable de la publication est chargé d'examiner chaque branche avant qu'elle ne soit prête pour le test. Ensuite, lorsque le propriétaire du produit décide qu'il est temps de regrouper les branches approuvées pour une nouvelle version de test, le gestionnaire de publication effectue la fusion.

Nous avons également un rôle rotatif de help desk de niveau 2 et au moins pour nous la charge de travail est telle qu'il est possible d'avoir les deux rôles en même temps.

Comme avantage de ne pas avoir de maître, il n'est pas possible d'ajouter du code au projet sans passer par le gestionnaire de publication, nous avons donc découvert directement la quantité de code qui avait été ajoutée silencieusement au projet auparavant.

Le processus de révision commence avec le propriétaire de la succursale qui soumet la différence au tableau de révision et met un post-it vert sur le tableau blanc avec le nom de la succursale (nous avons un flux de travail basé sur Kanban) sous "pour examen", ou s'il fait partie d'un utilisateur terminé histoire, déplacez la carte d'histoire entière sur "pour révision" et mettez le postit dessus. Le gestionnaire de relase est celui qui déplace les cartes et les post-it vers «prêts pour le test», puis le propriétaire du produit peut sélectionner ceux à inclure dans la prochaine version de test.

Lors de la fusion, le gestionnaire de publication s'assure également que la validation de fusion a un message de validation sensible qui peut être utilisé dans le journal des modifications pour le propriétaire du produit.

Lorsqu'une version a été mise en production, la balise est utilisée comme nouvelle base pour les branches et toutes les branches existantes sont fusionnées avec elle. De cette façon, toutes les branches ont un parent commun, ce qui facilite la gestion des fusions.

J'ajouterai aussi un message "avez-vous envisagé".

L'un des avantages de Bazaar est sa flexibilité. C'est là qu'il bat tous les autres systèmes distribués. Vous pouvez utiliser Bazaar en mode centralisé, en mode distribué ou obtenir ceci: les deux (ce qui signifie que les développeurs peuvent choisir le modèle avec lequel ils sont à l'aise ou celui qui convient le mieux à leur groupe de travail). Vous pouvez également déconnecter un référentiel centralisé pendant que vous êtes sur la route et le reconnecter à votre retour.

En plus de cela, une excellente documentation et quelque chose qui rendra votre entreprise heureuse: un support commercial disponible.

• Installez une interface Web décente, comme Github FI
• S'en tenir à un modèle relativement centralisé (au départ) pour que les gens se sentent à l'aise.
• Exécutez une version d'intégration continue pour chaque branche partagée.
• Partagez un bon ensemble d'options de configuration git globales.
• Intégrez git dans votre shell, avec la complétion bash, et une invite avec la branche actuelle.
• Essayez l'intégration Git d'IntelliJ en tant qu'outil de fusion.
• Assurez-vous que vous .gitignore le cas échéant.

En ce qui concerne les points 3 et 4 (autorisations par utilisateur, par section, par branche), jetez un œil à gitolite (traité dans le livre Pro Git: http://progit.org/book/ch4-8.html ).

Politique ou pas, Git est un aussi bon choix de DCVS que n'importe quel autre. Comme tout outil puissant, il vaut la peine de passer un peu de temps à comprendre comment l'outil est conçu pour fonctionner, et, à cette fin, je recommande vivement le livre Pro Git. Quelques heures passées avec cela vous éviteront beaucoup de frustration à long terme.

GUI: Pour le moment, TortoiseGit v1.7.6 devrait convenir à la plupart des opérations quotidiennes. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, etc ... Prend également en charge x64 nativement

Afin d'utiliser efficacement git dans une équipe de développement avec de nombreux développeurs, un système CI qui construit et teste en continu est nécessaire. Jenkins fournit un tel véhicule et je le recommande vivement. L'intégration doit être faite quoi qu'il arrive et c'est beaucoup moins cher de le faire plus tôt et plus souvent.

Plus adapté au développement collaboratif que gitosis ou gitolite, mais l'open-source est Gitorious . C'est une application Ruby on Rails qui gère la gestion des référentiels et la fusion. Cela devrait résoudre bon nombre de vos problèmes.

Git permet de créer des branches privées. Cela encourage les développeurs à s'engager souvent afin de décomposer les modifications en petits commits. Lorsque le développeur est prêt à publier ses modifications, il passe au serveur central. Il peut utiliser des scripts de pré-validation pour vérifier son code si nécessaire.

NXP gère Git et Subversion avec une plate-forme commune (à l'échelle de l'entreprise), intégrant le développement mobile Android aux projets logiciels traditionnels: http://www.youtube.com/watch?v=QX5wn0igv7Q