Flux de travail recommandé par Git

Question

J'utilise git depuis plusieurs mois dans un projet développé uniquement par moi-même. J'ai un référentiel local et je le pousse régulièrement sur github à des fins de sauvegarde.

Je veux ajouter un autre développeur à ce projet, mais je vais avoir la responsabilité d'intégrer l'ensemble du projet.

Quel est le flux de travail recommandé?

Avons-nous besoin d'un référentiel privé et public pour chaque développeur?

Si le référentiel github est le référentiel principal, est-ce que l'autre développeur doit cloner ce référentiel ou le référentiel dans mon ordinateur?

Devrait-il avoir le droit de pousser dans mon dépôt ou devrais-je retirer de son référentiel?

Answer 1

Git est orienté vers en tirant, plutôt que de pousser. Idéalement, l'autre développeur clonerait à partir de votre public repo sur Github; puis, quand il a fini avec ses changements, vous pouvez soit tirer d'un repo qu'il met à votre disposition, soit intégrer ses changements avec les correctifs qu'il vous envoie par e-mail. Quoi qu'il en soit, vous devez tirer les modifications dans le privé repo sur votre ordinateur, corriger les erreurs qui résultent de la fusion, puis pousser ses modifications à votre rapport public (celui sur Github).

Bien sûr, il n'y a rien de mal à lui donner l'accès commit à votre repo Github, soit.

Answer 2

Il peut créer sa propre branche de votre dépôt github, et quand il sent qu'il est prêt à s'intégrer, il peut vous envoyer des requêtes pull (où vous avez son URL publique repos comme une télécommande) ou il peut vous envoyer des jeux git format-patch .

Typiquement sur ce type de flux de travail, il incombe en grande partie à lui de s'assurer que ses patchs s'appliquent proprement à votre maître public.

Answer 3

Un conseil ... assurez-vous que vous savez clairement quelles opérations git réécrireont l'historique. Réinitialiser les pointeurs de branche, rebasing, ajouter des commits, etc. réécrira l'histoire qui est correct mais seulement pour les branches privées. Pour les branches que vous partagez (en poussant ou en tirant), vous devriez éviter de réécrire l'histoire.

Voici un article sur Packaging software using Git qui est une bonne lecture. Il est destiné aux personnes effectuant une intégration à grande échelle (comme la construction de distributions Linux) mais les principes sont généralement applicables.