Meilleures pratiques de collaboration avec les codeurs en utilisant Git

Question

J'ai quelques difficultés à comprendre les principes de travail en équipe de Git. Envisagez une équipe de deux programmeurs: A et B. Ils travaillent sur un Project. De plus, il y a un serveur distant avec un repo dessus. A et B collaborent à distance. Il y a déjà du code dans le repo. J'ai une faveur à vous demander de l'aide sur l'organisation de leur flux de travail étape par étape sur Git.
1. Ont-ils créer leurs propres succursales locales?
2. Comment pourraient-ils télécharger du code de travail sur un serveur de production? rsync?

Toute aide sera appréciée.

Answer 1

Les programmeurs n'ont pas besoin de créer leur propre branche pour fonctionner. Dans le cas le plus simple, les programmeurs s'engageront dans la branche "master" de leur propre référentiel, puis git push ceux qui sont validés dans le référentiel amont.

Pour déployer sur un serveur de production, une façon de le faire est d'utiliser git clone sur le serveur de production pour obtenir un référentiel local. Ensuite, pour mettre à jour le serveur de production, connectez-vous et git pull. Toutes les modifications qui ont été validées dans le référentiel principal seront appliquées.

Les développeurs peuvent éventuellement créer leurs propres branches pour leur propre usage (dans leur référentiel local uniquement), ou des branches pour le partage avec d'autres (en poussant les branches vers le référentiel partagé).

Answer 2

1. Chaque développeur aura son propre clone du référentiel. Ils peuvent créer des branches pour le travail de sujet comme et quand ils le veulent. Leur clone personnel est leur propre territoire, ils peuvent faire ce qu'ils veulent. Chaque développeur doit avoir son propre référentiel public distant, sur lequel il peut pousser/tirer vers/depuis. Typiquement, si vous voulez libérer du code, il y aura une personne qui décidera finalement de ce qui va entrer dans la version et de ce qui sera supprimé. Le référentiel distant de cette personne doit avoir une branche représentant les versions stables. Say A est le gestionnaire de publication qui veut incorporer le travail de B dans la version. Alors A attendra que B pousse son travail à son propre repo distant. Alors A attirera le travail de B vers son clone local, essaiera les choses, fusionnera, commettra, et poussera à son propre repo public pour la libération.

En (2) Je l'ai décrit seulement l'un des nombreux flux de travail différents qui sont disponibles pour une utilisation avec un SCM distribué comme git. Il y en a beaucoup d'autres. Ce page from Pro-Git est particulièrement agréable à décrire certains autres.