Un projet peut-il avoir plusieurs origines ?

Question

Un projet peut-il avoir deux (ou plus) "origines" dans Git ?

Je voudrais pousser un seul projet vers les deux github y un Heroku serveur.

Plus précisément, cette erreur apparaît lors de l'ajout du dépôt github :

$ git remote add origin https://github.com/Company_Name/repository_name.git
fatal: remote origin already exists.

Answer 1

Vous pouvez avoir autant de télécommandes comme vous le souhaitez, mais vous ne pouvez avoir qu'une seule télécommande nommée "origine". La télécommande appelée "origin" n'a rien de spécial, si ce n'est qu'elle est la télécommande par défaut créée par Git lorsque vous clonez un dépôt existant. Vous pouvez configurer une deuxième télécommande, pousser vers/depuis cette télécommande, et configurer certaines branches pour suivre les branches de cette télécommande au lieu de l'origine.

Essayez d'ajouter une télécommande appelée "github" à la place :

$ git remote add github https://github.com/Company_Name/repository_name.git

# push master to github
$ git push github master

# Push my-branch to github and set it to track github/my-branch
$ git push -u github my-branch

# Make some existing branch track github instead of origin
$ git branch --set-upstream other-branch github/other-branch

Answer 2

A noter qu'il est possible de faire en sorte que l'origine soit poussée à plus plus d'un serveur de dépôt git à la fois.

On peut y parvenir en utilisant la commande suivante pour ajouter une autre URL à la télécommande d'origine.

git remote set-url --add origin ssh://git@bitbucket.org/user/myproject.git

Answer 3

Voici un exemple de projet avec plusieurs remotes, GitHub et GitLab :

1. Ajouter un repo distant pour GitHub

   $ git remote add github https://github.com/Company_Name/repository_name.git

2. Ajouter un repo distant pour GitLab

   $ git remote add gitlab https://gitlab.com/Company_Name/repository_name.git

3. Vous avez maintenant plusieurs télécommandes dans le projet. Vérifiez avec git remote -v

   $ git remote -v
   github https://github.com/Company_Name/repository_name.git (fetch)
   github https://github.com/Company_Name/repository_name.git (push)
   gitlab https://gitlab.com/Company_Name/repository_name.git (fetch)
   gitlab https://gitlab.com/Company_Name/repository_name.git (push)

4. Comment pousser vers plusieurs dépôts ?

   $ git push github && git push gitlab

Answer 4

git remote set-url --add --push origin git@github.com:user/my-project.git
git remote set-url --add --push origin git@bitbucket.org:user/my-project.git

Maintenant vous avez 2 origines.

Answer 5

A dépôt local peut être lié à plusieurs référentiels distants .

Cependant, un seul de ces liens peut être appelé origin . Le reste des liens doit avoir différents noms .

Par conséquent, afin de répondre correctement à cette question, nous devons comprendre ce qu'est l'origine.

Laissez-moi vous expliquer avec un exemple.

Supposons que vous ayez un remote repository appelé amazing-project et ensuite vous clonez ce dépôt distant sur votre machine locale afin d'avoir un local repository . Vous auriez alors quelque chose comme ce que vous pouvez voir dans le diagramme ci-dessous :

Parce que vous avez cloné le référentiel. Le référentiel distant et le référentiel local sont lié à .

Si vous exécutez la commande git remote -v il listera tous les référentiels distants qui sont liés à votre référentiel local. Vous y verrez que pour pousser ou récupérer du code depuis votre dépôt distant, vous utiliserez la commande nom court "origine".

Cela peut prêter à confusion, car dans GitHub (ou sur le serveur distant), le projet s'appelle "amazing-project". Alors pourquoi semble-t-il qu'il y ait deux noms pour le référentiel distant ?

Eh bien, l'un des noms que nous avons pour notre référentiel est le nom qu'il a sur GitHub ou sur un serveur distant quelque part. Cela peut être pensé comme un nom du projet . Et dans notre cas, il s'agit d'un "amazing-project".

L'autre nom que nous avons pour notre référentiel est le nom court qu'il a dans notre référentiel local qui est lié à l'URL du référentiel. C'est le nom court que nous allons utiliser chaque fois que nous voulons pousser ou récupérer du code depuis ce dépôt distant. Et ce nom court agit en quelque sorte comme un alias pour l'url, c'est un moyen pour nous d'éviter d'avoir à utiliser cette longue url entière afin de pousser ou de récupérer du code. Et dans notre exemple ci-dessus, il s'appelle origin .

Alors, qu'est-ce que origin ?

En fait, l'origine est le par défaut nom court que Git utilise pour un référentiel distant lorsque vous clonez ce référentiel distant. Donc c'est juste le par défaut .

Dans de nombreux cas, vous aurez des liens vers plusieurs dépôts à distance dans votre dépôt local et chacun d'entre eux aura un nom court différent.

Dernière question : pourquoi ne pas utiliser le même nom ?

Je vais répondre à cette question par un autre exemple. Supposons que nous ayons un ami qui bifurque vers notre dépôt distant afin qu'il puisse nous aider sur notre projet. Et supposons que nous voulions être en mesure de récupérer le code de son dépôt distant. Nous pouvons utiliser la commande git remote add <shortname> <url> afin d'ajouter un lien vers leur référentiel distant dans notre référentiel local.

Dans l'image ci-dessus, vous pouvez voir que j'ai utilisé le nom court friend pour faire référence au référentiel distant de mon ami. Vous pouvez également voir que les deux dépôts distants ont le même nom de projet. amazing-project et cela nous donne une raison pour laquelle les noms des dépôts distants dans le serveur distant et les noms courts dans nos dépôts locaux ne devraient pas être les mêmes !

Il existe un outil très utile vidéo