Référentiels d'organisation Github, problèmes, développeurs multiples et fork - Meilleures pratiques de workflow

Un titre bizarre, oui, mais j'ai un peu de terrain à couvrir je pense.

Nous avons un compte d'organisation sur github avec des référentiels privés. Nous voulons utiliser les fonctionnalités natives issues / pull-requests de github (les requêtes pull sont essentiellement exactement ce que nous voulons en ce qui concerne les révisions de code et les discussions sur les fonctionnalités). Nous avons trouvé le hub d' outils de defunkt qui a une petite fonctionnalité intéressante de pouvoir convertir un problème existant en une demande d'extraction, et d'y associer automatiquement votre branche actuelle.

Je me demande s'il est préférable que chaque développeur de l'organisation bifurque le référentiel de l'organisation pour faire son travail de fonctionnalité / correction de bugs / etc. Cela semble être un flux de travail assez solide (comme c'est essentiellement ce que font tous les projets open source sur github), mais nous voulons être sûrs que nous pouvons suivre les problèmes et extraire les demandes d'une seule source, le référentiel de l'organisation.

J'ai donc quelques questions:

1. Une approche fork-per-developer est-elle appropriée dans ce cas? Il semble que cela pourrait être un peu exagéré. Je ne suis pas sûr que nous ayons besoin d'un fork pour chaque développeur, à moins que nous ne présentions des développeurs qui n'ont pas d'accès push direct et qui ont besoin de revoir tout leur code. Dans ce cas, nous voudrions instaurer une politique comme celle-ci, pour ces développeurs uniquement. Alors, quel est le meilleur? Tous les développeurs dans un référentiel unique, ou un fork pour tout le monde?
2. Quelqu'un a-t-il de l'expérience avec l'outil concentrateur, en particulier la fonction de demande de tirage? Si nous faisons un fork par développeur (ou même pour les développeurs moins privilégiés), la fonction de demande de pull du hub fonctionnera-t-elle sur les requêtes de pull du référentiel maître en amont (le référentiel de l'organisation?) Ou a-t-elle un comportement différent?

EDIT
J'ai fait quelques tests avec des problèmes, des fourchettes et des demandes de tirage et j'ai trouvé cela. Si vous créez un problème sur le référentiel de votre organisation, puis forkez le référentiel de votre organisation vers votre propre compte github, apportez quelques modifications, fusionnez dans la branche principale de votre fork. Lorsque vous essayez d'exécuter hub -i <issue #>vous obtenez une erreur, User is not authorized to modify the issue. Donc, apparemment, ce flux de travail ne fonctionnera pas.

Une approche fork-per-developer est-elle appropriée dans ce cas? Il semble que cela pourrait être un peu exagéré. Je ne suis pas sûr que nous ayons besoin d'un fork pour chaque développeur, à moins que nous ne présentions des développeurs qui n'ont pas d'accès push direct et qui ont besoin de revoir tout leur code. Dans ce cas, nous voudrions instaurer une politique comme celle-ci, pour ces développeurs uniquement. Alors, quel est le meilleur? Tous les développeurs dans un référentiel unique, ou un fork pour tout le monde?

Cela dépend de l'échelle de votre équipe, je suppose. J'avais l'habitude de travailler dans une petite équipe où nous n'avions qu'un seul dépôt et les fonctionnalités avaient leurs propres branches au sein de ce dépôt. Cela a très bien fonctionné pour nous.

Cependant, je contribue maintenant régulièrement à un plus grand projet open source où quelques dizaines de personnes ont accès au référentiel central. Nous faisons toujours tous les développements majeurs dans les dépôts personnels et soumettons des PR pour les fonctionnalités afin que le code puisse être revu, bien que les corrections de bugs puissent être poussées directement. Le dépôt principal ne contient que des branches master et release, le gardant libre de tout encombrement. Les branches de fonctionnalités sont dans des référentiels personnels, de sorte qu'elles peuvent toujours être vues par d'autres (la création de relations publiques précoces pour elles alertera les autres membres de l'équipe que le travail sur une fonctionnalité est en cours). Je peux recommander ce flux de travail pour tout projet avec plus d'une poignée de développeurs; le seul inconvénient est de devoir travailler avec plusieurs télécommandes.

L'approche fork-per-developer est une très bonne approche si vous appréciez les revues de code et la qualité du code. La bonne chose à propos de l'utilisation des demandes de tirage est qu'elles transfèrent la responsabilité du responsable au développeur.

Le développeur souhaite introduire son code dans la branche principale et demande son inclusion.

C'est un contexte très différent de l'ancien modèle où les gens s'engagent, et plus tard le critique a dû leur dire "oh, cette chose que vous avez faite il y a quelques semaines n'était pas si bonne, corrigez-la maintenant."

Nous utilisons ce modèle dans notre entreprise. Les requêtes Pull ont rendu les requêtes de code viables, encouragent la discussion sur le code d'autres personnes et ont généralement aidé à la qualité du code, même avec les développeurs qui étaient les premiers contre le nouvel outil. Je pense que cela a également incité les gens à prendre les critiques de code plus au sérieux, car le réviseur doit fusionner activement le code dans la branche principale, au lieu de simplement dire `` ok '' ou `` pas ok '' après que le code a déjà été validé.

Je ne ferais pas toute la fourche et la ramification pour tout. C'est un bon modèle pour les gemmes open source sur github, mais votre modèle fait partie d'une organisation qui aurait normalement un niveau de confiance plus élevé à propos des changements.

Un point majeur du contrôle des sources est que vous pouvez voir, annuler, inverser, etc. les changements. Faire un grand nombre de fourches et de branches dans votre situation est exagéré à mon humble avis.

Je réserverais des succursales pour des choses comme: les mises à niveau de version, le changement de l'un des éléments technologiques, le travail sur un sous-module pendant 3 mois qui n'a pas grand-chose en commun avec la base principale.

Je pourrais ne pas bifurquer du tout au sein d'une organisation. Ce mode semble plus adapté aux projets open source qui sont de nature différente de ceux en interne.

Je voudrais vous concentrer sur les tests et les revues de code. Les gens écrivent-ils des tests? Sont-ils bons? Les révisions de code sont-elles effectuées?