Comment utiliser git avec plusieurs référentiels distants
git peut être configuré pour pousser et tirer de plusieurs emplacements à la fois, vous permettant de stocker votre code sur deux plates-formes différentes tout en ne conservant qu'une seule copie locale. Voici comment le configurer.
Télécommandes, expliquées
La «télécommande» d'une succursale est une URL à partir de laquelle votre git repo récupère les modifications. Votre local git le dépôt est entièrement le vôtre – il n'est pas affecté par le code des autres personnes jusqu'à ce qu'elles poussent leurs validations vers la télécommande. J'espère que vous utilisez tous la même télécommande et que tout se synchronise, mais la télécommande n'est qu'un point de terminaison. Vous pouvez cloner ce point de terminaison et basculer vers une nouvelle télécommande sans trop de problème.
Chaque fois que vous clonez un nouveau référentiel, la télécommande par défaut est définie comme «origine». Vous pouvez trouver les télécommandes pour tout git repo en exécutant:
git remote -v
Cela affichera probablement l'URL de votre référentiel principal sur GitHub ou tout autre service que vous utilisez. Si vous avez plusieurs télécommandes, elles s'afficheront également ici.
Mais juste parce que origin est la télécommande par défaut, cela ne signifie pas que vous êtes limité à un. Pourquoi voudriez-vous deux télécommandes? Eh bien, un bon cas d'utilisation est CodeCommit d'AWS. C'est un hébergé git et possède de nombreuses intégrations avec leur plate-forme de calcul EC2, permettant des déploiements de code automatisés sur vos serveurs, directement à partir du contrôle de code source.
Cependant, CodeCommit est assez maladroit par rapport à plus concentré git des fournisseurs tels que GitHub, GitLab et BitBucket, et n'a pas les mêmes intégrations CI / CD qui rendent ces fournisseurs excellents. Donc, vous êtes confronté à un dilemme: utilisez CodeCommit par défaut git ou créez vous-même votre pipeline de déploiement de code automatisé.
Cependant, avec plusieurs télécommandes, vous pouvez facilement pousser le code vers un deuxième référentiel. Chaque fois que vous souhaitez mettre à jour vos serveurs, vous pouvez pousser les modifications de votre contrôle de source principal vers CodeCommit pour démarrer le pipeline de déploiement.
Configuration de plusieurs télécommandes
En utilisant git cette façon est en fait assez simple. Vous ajoutez des télécommandes de la même manière que vous pousseriez un dossier existant, sauf qu'au lieu d'ajouter la télécommande «d'origine», vous lui donnez un nom différent.
git remote add
Ensuite, lorsque vous souhaitez pousser vers la deuxième télécommande, ajoutez le nom de la télécommande et la branche à votre commande push:
git push second master
Ou, changez la télécommande par défaut en utilisant --set-upstream:
git push --set-upstream second master
Il s'agit de la configuration la plus simple, cependant, elle vous oblige soit à passer le nom de la télécommande comme argument, soit à changer de télécommande à chaque fois.
Vraiment, si vous utilisez une configuration à deux télécommandes, vous voudrez probablement une meilleure façon de gérer la transmission du code vers votre deuxième télécommande. La meilleure façon de gérer cela dans git consiste à créer une autre branche pour le code poussé vers le second en amont, comme les déploiements vers AWS CodeCommit.
Vous pouvez créer une branche avec checkout -b:
git checkout -b deployment
Ensuite, ajoutez la télécommande de déploiement:
git remote add deployment
et récupérer la branche principale:
git fetch deployment master
Ensuite, vous pouvez définir l'amont pour la branche actuelle en exécutant:
git branch --set-upstream-to=deployment/master
Vous pouvez répéter ce processus pour n'importe quel nombre de branches, ce qui en fait une excellente méthode pour garder une trace de plusieurs télécommandes. N'oubliez pas, cependant, qu'il ne s'agit que d'une configuration locale. Par conséquent, si vous transférez cette branche vers votre référentiel principal, les autres n'auront pas leurs copies de la branche de déploiement configurées pour utiliser automatiquement la deuxième télécommande.
Ce serait idéal si la deuxième branche n'est que dans un sens, ce qui signifie que vous ne faites que pousser du code, pas tirer du nouveau code, sinon vous risquez de rencontrer des conflits inattendus. Autre que ça, git fonctionne parfaitement avec plusieurs télécommandes.
