Les collaborateurs d'un référentiel Github privé devraient-ils chacun débourser le dépôt?

Je travaille sur un projet en ce moment, et nous avons le code source dans un référentiel privé sur Github, avec chacun de nous en tant que collaborateur.

Ce que nous ne savons pas exactement, c'est comment séparer chacun de nos travaux.

Je pense que nous devons faire:

Chacun de nous doit bifurquer le référentiel
Lorsque nous sommes prêts à pousser notre code, nous soumettons ensuite une demande d'extraction au référentiel du chef de projet, qui peut en même temps l'utiliser comme une opportunité pour faire une revue de code

En ce qui concerne les référentiels privés, est-ce pour cela que la fourche est censée être utilisée, ou suis-je en train de trop compliquer la situation?

— JMK
source

Oui. Faites-le comme vous l'avez suggéré ici, créez uniquement une équipe et faites du référentiel de l'équipe le référentiel "maître". Tout le monde fait des relations publiques, y compris le chef de projet.

— RubberDuck

Le clonage du dépôt sur la machine locale du développeur est déjà une sorte de bifurcation. Si chaque développeur bifurque le dépôt sur GitHub, cela ne sert qu'à publier son état de travail actuel.

Cela peut être approprié lorsqu'il existe un référentiel maître central et que de nombreux contributeurs ne bénéficient pas d'un accès direct à ce référentiel. Cela fonctionne très bien pour les projets open source où tout le monde peut contribuer et émettre une demande d'extraction qui est ensuite examinée et fusionnée par un groupe de responsables principaux. L'utilisation de plusieurs référentiels applique un flux de travail basé sur les demandes d'extraction.

Dans une petite équipe de confiance, ce n'est pas nécessaire. Pour éviter que différentes personnes ne se gênent mutuellement, une stratégie telle que Git Flow peut être suivie: Chaque petite fonctionnalité est implémentée sur une branche de fonctionnalité distincte. Une fois la fonction terminée, elle est fusionnée dans la branche principale. La plupart des équipes associent cela à une demande d'extraction ou à une révision de code par convention, mais sont suffisamment fiables pour ignorer cela, le cas échéant. Alors que des référentiels séparés conduiraient un développeur à publier leur état actuel sur leurs référentiels bifurqués mais visibles par l'équipe, dans un seul référentiel commun, ils pousseraient leurs modifications vers une branche de fonctionnalités distincte. Faire tout le développement sur master / trunk est fortement déconseillé dans la plupart des workflows.

La différence finit par concerner uniquement la gestion des accès, et pas tant le flux de travail implémenté. Vous pouvez effectuer des workflows basés sur les demandes d'extraction avec l'une ou l'autre configuration. Du point de vue brut de Git, il n'y a pas beaucoup de différence entre une fourchette et une branche - l'une ou l'autre approche partage essentiellement l'historique du projet et permet d'ajouter des commits sans affecter les autres branches / fourches. Compte tenu de cela, il serait beaucoup mieux de partager un seul dépôt lorsque vous êtes dans un groupe de confiance fermé.

— amon
source

Juste pour faire rapidement écho à ce que dit @amon, j'ai travaillé dans une organisation où chaque développeur était obligé de créer un référentiel principal, ce qui, selon nous, n'était qu'une étape supplémentaire inutile et maladroite. Je n'ai jamais compris pourquoi c'était nécessaire, mais notre équipe des opérations ne voulait pas en discuter. Le processus était le suivant: commit -> push -> pull request -> wait -> wait some more -> essayez d'attirer l'attention de l'équipe des ops sur IRC -> allez voir les ops et demandez-leur de regarder la pull request -> attendre -> code intégré -> répéter.

— DaveyDaveDave

Je décourage vraiment ce workflow. J'ai rencontré de très mauvais conflits de fusion avec deux développeurs poussant directement vers le référentiel canonique. Sans oublier, il est toujours préférable que quelqu'un d'autre examine votre code. Il est beaucoup plus facile de soumettre des demandes de tirage si vous avez chacun une fourchette, et il existe un seul référentiel de projet canonique. Yeah Yeah. Je sais, ce n'est pas "distribué". Peu importe. Le modèle de fourche et PR fonctionne mieux selon mon expérience.

— RubberDuck

@RubberDuck c'est un bon point, je soupçonne que mon cas était rare en ce sens que les personnes responsables des demandes de tir n'étaient pas en mesure de réviser le code, ce qui le rendait inutile. Je suggérerais que d'autres outils dédiés pour la révision de code, comme gerrit, soient plus efficaces, mais je comprends votre point de vue que le forking peut (devrait) fonctionner de manière similaire.

— DaveyDaveDave

Le problème est de savoir qui détermine le moment où la fonctionnalité est prête à passer en mode maître? Je trouve également difficile de travailler avec des succursales; Des centaines de succursales sur un même dépôt et la plupart d'entre elles ne sont pas fusionnées ou à moitié terminées, pourquoi devraient-elles exister du tout si elles ne sont même pas prêtes à être fusionnées? La gestion des accès concerne à 100% le flux de travail, cette réponse n'est qu'à moitié bonne.

— Rudolf Olah

Cela fonctionnerait, ou vous pourriez utiliser une méthode de branchement où chaque contrib a ses propres branches, qui, lorsque l'équipe est d'accord, sont fusionnées avec master.

— Margeaux Spring
source

Merci, je vais aller avec l'autre réponse comme a plus de détails, mais oui je suis d'accord :)

— JMK