Gérer plusieurs personnes travaillant sur un projet avec GIT

Je suis très nouveau sur GIT / GitHub (aussi récent qu'hier). Je voudrais savoir quelle est la meilleure façon de gérer plusieurs personnes travaillant sur le même projet avec Github. Actuellement, je gère un projet avec quatre développeurs.

1. Comment puis-je gérer le flux de travail et m'assurer que tout est synchronisé?

   (Remarque: tous les développeurs auront un compte universel.)

2. Chaque développeur doit-il être sur une branche différente?

3. Pourrai-je gérer 2 personnes travaillant sur le même fichier?

Veuillez poster une réponse détaillée, je ne suis pas un lecteur timide. Je dois bien comprendre cela.

Si tous les développeurs ont un accès commit au référentiel, vous ne devriez pas avoir à faire quoi que ce soit de spécial. Ils retireront les modifications du référentiel, apporteront leurs propres modifications, s'engageront localement, puis repousseront dans le référentiel public lorsqu'ils auront quelque chose qui fonctionne.

Si d'un autre côté, vous avez un (ou quelques) développeur (s) responsable (s) de la validation du dépôt, et les autres fournissent des correctifs à ceux-ci. Demandez à chacun d'entre eux de cloner le référentiel dans leurs propres comptes et de leur envoyer des pull-request lorsqu'ils ont un changement qu'ils souhaitent dans le référentiel principal.

Il est également possible de créer des clones spécifiques pour travailler sur des fonctionnalités spécifiques si vous le souhaitez. Utiliser le même flux de travail avec des pull-request pour obtenir des modifications dans le référentiel principal lorsque la fonctionnalité est terminée.

Si par «Tous les développeurs auront un compte universel», vous voulez dire que tous les développeurs partageront un compte GitHub et apparaîtront comme le même committer dans le dépôt, c'est une mauvaise idée. Créez des comptes séparés et configurez-les en tant que collaborateurs si vous voulez qu'ils aient tous un accès de validation.

Quant à vos questions spécifiques:

2. Non, utilisez des branches pour les fonctionnalités, les correctifs, etc. qui prendront plus d'un commit. Plusieurs développeurs peuvent travailler sur la même branche.

3. Oui, git gère très bien les conflits, donc il n'y a aucun problème à ce que les gens travaillent sur le même fichier. Aucun problème sauf, la résolution des conflits peut ne pas toujours être triviale s'il y a des changements fondamentaux dans un fichier qui a été édité par plusieurs membres. Ce n'est cependant rien qui ne peut être surmonté en parlant ensemble. Le contrôle de version ne remplace pas la communication.

Bonne chance!

Nous travaillons avec 2 développeurs et nous utilisons ce workflow:

• Sur Github, nous avons une branche master et une branche dev
• La branche principale est identique à la production ou contient du code prêt pour le déploiement
• La branche dev est en avance sur master et contient tout le nouveau code en cours d'élaboration
• Localement, nous travaillons tous les deux sur la branche dev et poussons vers github quand quelque chose est prêt
• L'autre dev récupère tous les nouveaux changements de la branche dev avant de pousser son nouveau code
• Quand la branche dev est bonne, on fusionne avec la branche master
• Localement, nous avons plusieurs branches de fonctionnalités, des branches, etc.

Je ne vois que des réponses textuelles ici, alors j'ai pensé publier une photo d'un joli gitflow pour commencer. Une image décrit plus de mille mots:

• Ce flux fonctionne également bien avec le déploiement continu.
• Votre branche principale contient du code en cours d'exécution sur votre serveur de production.
• Votre branche de développement contient du code qui s'exécute actuellement sur un serveur de test / test.

Je travaille avec 3 autres développeurs, et nous avons beaucoup de mal avec cela. Les développeurs poussent parfois des validations en production qui ne sont pas encore prêtes pour les heures de grande écoute, car elles impliquent d'autres validations dans leurs modifications, puis poussent en production. Les branches de version semblent fonctionner correctement pour nous. Donc, si la version 1.0 est la version stable actuelle, nous créerons une branche pour le développement v1.1. Les développeurs feront des changements dans cette branche. Notre serveur de test vérifie cette branche et extrait les modifications selon les besoins. Lorsque toutes les fonctionnalités de la v1.1 seront prêtes et que les tests seront terminés, nous fusionnerons la v1.1 avec master et push. Avec les branches, l'équipe de développeurs A peut travailler sur la version 1.1 et l'équipe de développeurs B peut travailler sur la version 1.2. Les deux équipes peuvent travailler sans se toucher. Si l'équipe A développe quelque chose que B peut utiliser,

Nous utilisons également une branche de correctifs qui est utilisée pour des changements immédiats.

Voici un lien vers une image de ce à quoi cela ressemble. http://nvie.com/img/[email protected]