Comment utiliser un repo Git cloné comme "maître" et rester synchronisé avec un repo Git distant sur un site client?

Question

J'ai une version locale de Stash en cours d'exécution et tous les développeurs locaux y ont accès. J'ai un peu de difficulté à comprendre comment l'utiliser pour travailler avec le projet d'un client.

Je dois être capable de cloner le repo git de mon client (le pousser dans Stash) comme repo de référence. Tout le travail de dev de tous mes devs locaux sera fait contre ce repo de référence. Je veux faire tous les commits contre ce repo de référence, et une fois que tous les changements ont passé QA, alors seulement pousser le code final au client. À toutes fins utiles, le client ne recevra pas tous les engagements quotidiens, seulement le produit final. Ce que je cherche à faire, et je ne sais pas si c'est faisable, est de cloner le dépôt du client localement, et en faire une nouvelle origine pour tous les développeurs locaux. Une fois que tout le travail est terminé, je veux seulement pousser le commit final jusqu'au client (pas tous les commits intermédiaires). Pour rendre les choses un peu plus complexes, au lieu d'utiliser mon repo cloné local comme origine pour les développeurs, je veux pousser mon repo cloné dans mon serveur Stash local et avoir cette origine.

Il est facile de déplacer le repo du client dans Stash (je peux simplement me connecter, cloner le repo et le placer dans Stash). Ce que je ne sais pas comment faire, c'est comment le synchroniser avec le client. c'est-à-dire: si le client apporte des changements, je veux y apporter ces changements. Est-ce qu'il doit toujours rester un processus en deux parties (par exemple: tirer les changements, rebaser et pousser)? Est-ce que je dois le faire dans deux voies de travail différentes (c.-à-d. Une pour mon travail de développement réel, et une autre pour faire le tirage/rebase/pousser)? Y a-t-il un moyen automatisé de faire quelque chose comme ça?

Answer 1

Eric, Vous devez modifier votre approche de l'utilisation de Git de la façon dont il est destiné à être utilisé: tout le monde travaille avec son propre git ET la télécommande. Ne compliquez pas le processus en ajoutant ces restrictions QA et la responsabilité d'un développeur avec la responsabilité ultime de pousser les choses à distance, car cela ne fera que ralentir les choses. Apprenez-en davantage sur le marquage et la création de branches git, et familiarisez-vous avec le contrôle qualité. De cette façon, les builds peuvent être estampillés prêts pour le contrôle de qualité, les développeurs peuvent travailler sur des branches qui n'auront pas d'impact sur la tête - et surtout, vous ne serez pas le goulot d'étranglement supervisant le push to remote.

Une très bonne lecture sur le sujet est http://pragprog.com/book/tsgit/pragmatic-version-control-using-git