contrôle de version pour petite équipe [fermé]

Nous sommes en train d'amorcer une nouvelle équipe de très petite taille (disons 2-5) ma question est: quel type de contrôle de version fonctionne le mieux pour ce type d'équipes, centralisées ou distribuées.

Distribué tout le long, il n'y a vraiment plus de raison de centraliser à mon humble avis, surtout si vous parlez de développement d'équipe.

Un autre vote pour Mercurial, aucun tracas à installer sous Windows et bitbucket.org a des référentiels gratuits (qui peuvent être privés) avec un espace illimité.

Si vous prévoyez de travailler sur un projet open source, git et Github semblent être plus adéquats / populaires. Cependant, si vous ne vous êtes pas aventuré dans les DVCS, je vous recommande de commencer avec Mercurial et ce guide génial .

celui que vous utiliserez tous de manière cohérente

[personnellement, j'aime Mercurial]

La meilleure réponse est probablement "tout ce qui vous convient". Même lorsque je travaille sur des trucs personnels, j'utilise Git. Il semble faire un très bon travail de montée en puissance et de réduction et mon expérience limitée avec Mercurial est à peu près la même.

Je pense que vous devriez choisir ce qui vous convient. Dans une petite équipe, vous n'aurez pas différents arbres de code (comme le noyau Linux), donc un référentiel central est OK. Mais vous pouvez également avoir cette configuration avec VCS distribué. J'irais donc avec la popularité et l'expérience personnelle. Les plus populaires sont SVN, git et Mercurial. Vous devez décider lequel d'entre eux est le mieux utilisé avec votre équipe (expérience, support d'outils dans l'IDE choisi, etc.).

Cela dépend vraiment de savoir si vos développeurs vont développer ou non beaucoup de code hors ligne, mais seulement de choisir entre un référentiel distribué ou centralisé, car c'est la première chose que vous devez décider. Ensuite, si vous décidez qu'une approche centralisée fonctionne mieux que SVN, c'est tout ce dont vous avez besoin. D'un autre côté, si vous optez pour une approche distribuée que pour git, même sur Windows, c'est assez bien puisque maintenant vous avez tortoise git (la même interface qui existe également pour svn). De plus, ne comptez pas autant sur le support IDE car vous pourriez avoir une mauvaise surprise si vous l'utilisez, et vous pourriez trouver que les fichiers qui ne devraient pas être validés sont validés en votre nom par l'IDE.

Demandez à votre équipe si quelqu'un veut s'en occuper. Il est préférable d'avoir un système stable et une personne responsable qu'un bon système quand personne ne s'en soucie et qu'aucun n'est capable de le restaurer à partir d'une sauvegarde.

S'il y a une telle personne - il saura déjà quoi utiliser, alors acceptez simplement sa décision. Sinon - obtenez une solution hébergée. Il serait très stupide d'essayer GIT (l'un des meilleurs) si tous les développeurs n'avaient jamais touché Shell / Linux.

Cela dépend aussi du nombre de personnes "non techniques" qui doivent lire / contribuer. Assurez-vous simplement qu'ils pourraient l'utiliser, et il existe des outils disponibles.

SVN est largement pris en charge dans les outils. L'outillage est la clé; différentes personnes auront des compétences différentes. Certains préféreront la ligne de commande, certains préféreront les outils basés sur IDE, certains préféreront les outils graphiques. À l'heure actuelle, SVN semble être l'outil le plus largement pris en charge.

Autre que Mercurial ou Git.

Je pense que dans les petites entreprises, il y a des arguments pour centraliser certaines choses. (Pensez par exemple à la sauvegarde hors site. Lorsque vous n'avez que 2 personnes travaillant sur un projet et qu'elles logent dans le même bâtiment et qu'il y a un incendie, la décentralisation vers les deux ordinateurs peut ne pas suffire.)

Cependant: avoir une solution partiellement centralisée ne vous limite pas à un système centralisé. Vous pouvez simplement pousser vers un serveur extérieur avec quelque chose comme git ou mercurial.