Git pull sans checkout ?

Question

J'ai l'habitude d'exécuter git pull et d'autres commandes à partir d'une branche sur laquelle je travaille. Mais j'ai mis en place un serveur de développement sur lequel plusieurs personnes travaillent, donc je ne veux pas avoir à changer de branche quand je le fais. Si je veux mettre à jour une branche existante sur le serveur de développement à partir du dépôt github que nous utilisons tous, quelle est la bonne façon de le faire ? Si je lance la commande 'git pull github branchname', est-ce que cela va simplement tirer la branche dans la branche actuelle ?

Tous les exemples de git que j'ai pu trouver semblent indiquer qu'il faut d'abord lancer 'checkout branchname', puis faire le pull. J'essaie d'éviter cela. Comme je l'ai dit, il s'agit d'une branche existante et je veux juste mettre à jour la dernière version.

Answer 1

Je cherchais la même chose et j'ai finalement trouvé la réponse qui a fonctionné pour moi dans un autre post de stackoverflow : Fusionner, mettre à jour et extraire des branches Git sans utiliser de checkouts

En principe :

git fetch <remote> <srcBranch>:<destBranch>

Exemple :

git fetch origin branchname:branchname

Answer 2

J'ai eu le même problème avec la nécessité de commiter ou de cacher les changements de fonctionnalités en cours, de vérifier maître branche, faire pull pour tout récupérer du distant vers le local master l'espace de travail, puis basculer à nouveau vers une branche de fonctionnalités et effectuer un rebase pour le mettre à jour avec le master.

Pour faire tout cela, garder l'espace de travail sur la branche des fonctionnalités et éviter tous les changements, je fais ceci :

git fetch origin master:master

git rebase master

Et il fait très bien l'affaire.

Answer 3

Si vous souhaitez que le local conseils de branche pour se faire rejointoyer après git fetch Il est donc nécessaire de prendre des mesures supplémentaires.

Plus concrètement, supposons que le dépôt github comporte des branches D , B , C y master (la raison de cet étrange ensemble de noms de branches sera expliquée dans un instant). Vous êtes sur l'hôte devhost et que vous êtes dans un repo où origin est le repo github. Vous faites git fetch qui reprend tous les objets et met à jour origin/D , origin/B , origin/C y origin/master . Jusqu'à présent, tout va bien. Mais maintenant, vous dites que vous voulez que quelque chose se produise, le devhost , à local branches D , B , C et/ou master ?

J'ai ces questions évidentes (pour moi en tout cas) :

1. Pourquoi voulez-vous les conseils de tous branches mises à jour ?
2. Que se passe-t-il si une branche (par ex, B ) a des commits que le repo distant (github) n'a pas ? Doivent-ils être fusionnés, rebasés, ou ... ?
3. Que se passe-t-il si vous êtes sur une branche (par ex, C ) et le répertoire de travail et/ou l'index sont modifiés mais ne sont pas validés ?
4. Que se passe-t-il si de nouvelles branches ont été ajoutées au dépôt distant ( A ) et/ou des branches supprimées ( D ) ?

Si la réponse au point (1) est "parce que devhost n'est pas réellement pour le développement, mais plutôt un miroir local qui garde simplement une copie disponible localement du repo github afin que tous nos développeurs actuels puissent le lire rapidement au lieu de lire lentement sur github", alors vous voulez un "miroir" plutôt qu'un repo "normal". Il ne devrait pas avoir de répertoire de travail, et peut-être qu'il ne devrait pas non plus accepter de push, auquel cas les questions restantes disparaissent.

S'il existe une autre réponse, les points 2 à 4 deviennent problématiques.

Quoi qu'il en soit, voici une façon d'aborder la mise à jour des refs locaux en fonction des refs distants (après avoir exécuté la commande git fetch -p par exemple) :

for ref in $(git for-each-ref refs/remotes/origin/ --format '%(refname)'); do
    local=${ref#refs/remotes/origin/}
    ... code here ...
done

Ce qui va dans le ... code here ... dépend des réponses aux questions (2-4).

Answer 4

Utilisation

git fetch

au lieu de cela. Il met à jour les refs et objets distants dans votre repo, mais laisse les branches locales, HEAD et l'arbre de travail tranquilles.