2010-10-29 22 views
4

Figurez-vous, j'ai plusieurs branches: maître, a, b, c ...Git: Comment fusionner branche locale avec automatiquement le suivi à distance sans aller chercher

Maintenant, je suis dans la branche principale et « git pull ». Ceci récupère toutes les modifications du serveur distant dans les branches origin/master, origin/a, origin/b ... et fusionne la branche CURRENT (master) avec origin/master. Mais alors je veux passer à une branche et encore fusionner ces changements à distance de la branche suivie à distance, SANS récupérer les changements à nouveau (comme ils sont déjà dans l'origine/une branche).

Existe-t-il un moyen plus simple de ne pas spécifier exactement la piste de la branche I à distance (c'est-à-dire automatiquement)?

+0

Je suis assez certain que l'OP veut éviter d'avoir à nommer explicitement la branche distante, comme c'est possible avec 'git pull' - git sait quelle branche rechercher et fusionner. Autrement dit, 'git merge origin/a' n'est pas une réponse. – Cascabel

Répondre

1

Je ne crois pas qu'il existe une commande intégrée pour cela. Cependant, vous pouvez faire quelque chose comme ceci:

#!/bin/bash 
head=$(git symbolic-ref HEAD) || exit 
head=${head#refs/heads/} 
merge=$(git config --get branch.$head.merge) || { echo "no tracking branch"; exit 1; } 
remote=$(git config --get branch.$head.remote) || remote=origin 
git merge $remote/${merge#refs/heads/} 

# alternatively, as in Aristotle's answer: 
# head=$(git symbolic-ref HEAD) || exit 
# upstream=$(git for-each-ref --format='%(upstream:short)' "$head" 
# [ -z "$upstream" ] && { echo "no tracking branch"; exit 1; } 
# git merge $upstream 

Je pense que je l'ai couvert mes bases assez bien - il sort avec le statut d'échec si dans l'état HEAD détaché, ou si la branche actuelle ne dispose pas d'une branche de suivi . Il est par défaut à l'origine, comme le font les commandes normales de transfert git. (Quelque chose de bizarre se produira si vous essayez de l'utiliser sur une branche qui suit quelque chose d'autre qu'une branche sur la télécommande, c'est-à-dire pas de la forme refs/heads/*, mais cela semble peu probable.) En fait, vous économisez beaucoup de temps, mais voilà!

Si vous voulez l'utiliser, il suffit de le stocker quelque part et un alias, ou nommez-le git-something et placez-le dans votre PATH.

+0

Merci. Je vais vérifier – Zebooka

+1

@Zebooka: Pour ce que ça vaut, cette fonctionnalité vient d'être ajoutée. [Commit 93e535a] (http://git.kernel.org/?p=git/git.git;a=commit;h=93e535a5b78c9861eca3e9371d1c3e5173c0ab02) vous permet de définir une option de configuration 'merge.defaultupstream' qui provoquera' git merge '(sans arguments) pour fusionner avec la branche de suivi à distance appropriée - tout comme un' git pull 'sans le fetch. Ma conjecture serait que cela pourrait faire en v1.7.5. – Cascabel

1

Je pense que vous pouvez simplement vérifier votre branche locale et fusionner à partir de votre copie locale de la branche origin/a.

Quelque chose comme:

git checkout a 
git merge origin/a 
+0

Je suis assez sûr que ce n'est pas une réponse du tout - voir mon commentaire sur la question. Je ne veux pas rétrograder, car je peux me tromper. – Cascabel

+0

Eh bien pour moi, il semble qu'il ne veut tout simplement pas atteindre le serveur à nouveau. Il déclare "SANS récupérer les changements (car ils sont déjà en origine/une branche)". Donc, la partie qu'il ne veut pas faire est d'aller chercher. Même si j'ai peut-être mal compris. Il vaut mieux laisser l'OP décider ou donner plus de détails. :) –

0

git pull est rien de plus que git fetch + git merge. Avec le paramètre --rebase vous pouvez également avoir rebasage et non de fusion vous pouvez donc simplement passer à l'autre branche et fusion/rebasage:

git checkout a 
git merge origin/a 

ou:

git checkout a 
git rebase a 

Comme il ne fait rien d'autre part, j'ai même cessé d'utiliser tirer du tout. Je juste git fetch régulièrement ainsi je peux suivre les changements dans d'autres dépôts facilement et alors git merge/rebase chaque fois que je suis prêt.

+0

Je suis assez sûr que ce n'est pas une réponse du tout - voir mon commentaire sur la question. Je ne veux pas rétrograder, car je peux me tromper. – Cascabel

+0

Oui, c'est une non-réponse. Ce n'est pas clair comment cela s'applique à la situation du PO et l'introduction à la réponse parle de --rebase, bot n'explique pas vraiment les exemples suivants. Réponse mal écrite. –

0

Cela vérifiera toutes les branches de suivi à son tour, et fusionner leurs filiales distantes correspondantes:

git for-each-ref --format='%(refname:short) %(upstream:short)' \ 
| while read branch upstream ; do 
    [ -z "$upstream" ] && continue 
    git checkout "$branch" 
    git merge "$upstream" || git reset --hard 
done 

Si une fusion a des conflits, il est rembobiné avec git reset et vous devrez le faire manuellement.

Non testé.

Vous pouvez également transmettre un ou plusieurs modèles à git for-each-ref pour le restreindre à une certaine branche ou à un certain ensemble d'entre eux.

+0

Ceci est dangereux. Si 'git merge' refuse d'essayer de fusionner, parce que l'arbre de travail a des modifications,' reset --hard' détruira ces modifications. 'reset --merge' serait plus sûr, mais pas tout à fait sûr. (Et je sais que vous avez une caisse là-bas, mais avec des modifications locales, il aurait soit échoué ou laissé en place lors du changement de branche - de toute façon, il ya encore des modifications locales.) – Cascabel

+0

Dangereux, mais semble être un indice faire une mise à jour automatique de la branche actuelle. Merci – Zebooka