flux de travail de l'équipe github - à la fourche ou non?

Nous sommes une petite équipe de développeurs Web qui utilisent actuellement Subversion, mais nous allons bientôt passer à Github.

J'examine différents types de workflows github, et nous ne savons pas si le concept de forking dans github pour chaque développeur est une si bonne idée pour nous.

Si nous utilisons des fourches, je comprends que chaque développeur aura ses propres référentiels privés à distance et locaux. Je crains que cela ne rende les changements de modifications difficiles et trop complexes. De plus, ma plus grande préoccupation est que cela forcera chaque développeur à avoir 2 télécommandes: origin (qui est la fourchette distante) et une en amont (qui est utilisée pour "synchroniser" les changements depuis le référentiel principal). Je ne sais pas si c'est un moyen si simple de faire les choses.

Ceci est similaire au flux de travail expliqué ici: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

Si nous n'utilisons pas de fourches, nous pouvons probablement nous en tirer en utilisant un référentiel central créant une branche pour chaque tâche sur laquelle nous travaillons, et les fusionnant dans la branche de développement sur le même référentiel. Cela signifie que nous ne serons pas en mesure de restreindre la fusion des branches et qu'il pourrait être un peu compliqué d'avoir de nombreuses branches sur le référentiel central.

Des suggestions d'équipes qui ont essayé les deux workflows?

Je pense que votre peur de bifurquer vient de la fusion moins que stellaire de SVN - parce que ce n'est pas la fourche qui cause le problème - c'est la fusion.

Plongez - vous trouverez que c'est vraiment génial! Vous n'avez pas besoin de sur-fork (pas de fork pour chaque changement dans chaque fichier), mais vous pouvez forker pour les fonctionnalités, et fusionner à nouveau.

Considérez GitHub comme plusieurs versions qui méritent d'être améliorées sur de nombreux concepts fondamentaux du contrôle de code source.

Le concept de branche "stable" et de fourche "développement actif" couvre également bon nombre de ces problèmes si vous hésitez à vous lancer. : P

Nous avons essayé les deux, avec des développeurs très à l'aise dans svn. Et si vous êtes un groupe de développeurs travaillant déjà ensemble et se faisant mutuellement confiance avec des droits de validation, vous trouverez probablement plus facile de simplement garder un seul dépôt central chez git et de vous ajouter tous en tant que collaborateurs que ce dépôt.

Nous faisons encore parfois des fourches privées, mais c'est généralement pour des changements exotiques ou des tests en personne qui ne sont généralement pas intéressés par les autres, mais que nous souhaitons stocker à distance de toute façon.

Je commencerais par un seul dépôt central et travaillerais avec git pendant un certain temps. Peut-être que la fourchette privée se développera sur vous, peut-être pas. N'importe quel.

Dans git, une fourchette n'est vraiment qu'une autre branche. Avec le workflow fork-for-each-developer, vous imposez effectivement que chaque développeur dispose d'une branche publique (distante) pour suivre ses changements de développement. Cela est utile pour pouvoir collaborer directement (peer-to-peer) entre développeurs. Vous devrez fusionner les modifications de chaque développeur dans le référentiel central dans tous les cas, donc je ne pense pas qu'il y ait beaucoup de frais supplémentaires ajoutés par cela.

Pour une petite équipe de 2-3 développeurs, il est normal d'utiliser la branche sur le référentiel pour gérer les correctifs et les fonctionnalités. Le problème est lorsque vous avez plus de développeurs que cela et plus de fonctionnalités et de correctifs en cours de développement.

Dans ce cas, votre référentiel principal dans Github aura des centaines de succursales; certains seront vieux et oubliés et non fusionnés.

Vous aurez également des problèmes de collaboration lorsque quelqu'un pousse de force sur une branche partagée qui est sur le référentiel. Cela signifie que personne ne peut collaborer correctement sur cette branche, car une poussée forcée est une réécriture de l'histoire.

Le fait de bifurquer un dépôt facilite le suivi des branches en cours de travail et de celles qui sont bonnes à utiliser. Il garde le repo principal plus propre.

Cependant, votre infrastructure de test peut dépendre de l'utilisation du référentiel principal, il peut donc être plus difficile de tester les modifications dans votre référentiel forké, sauf si vous avez poussé la branche vers l'amont. Il peut être difficile de déterminer quand les branchements et les fourches sont les meilleurs, mais en général, lorsque l'équipe compte plus de 4 personnes et qu'il existe de nombreuses corrections et fonctionnalités, la fourche est la meilleure option.