Fusionner, mettre à jour et extraire des branches Git sans utiliser d'extractions

Je travaille sur un projet qui a 2 branches, A et B. Je travaille généralement sur la branche A et je fusionne des éléments de la branche B. Pour la fusion, je fais généralement:

git merge origin/branchB

Cependant, je voudrais également conserver une copie locale de la branche B, car je peux parfois consulter la branche sans d'abord fusionner avec ma branche A. Pour cela, je ferais:

git checkout branchB
git pull
git checkout branchA

Existe-t-il un moyen de faire ce qui précède en une seule commande, et sans avoir à changer de branche d'avant en arrière? Dois-je utiliser git update-refpour cela? Comment?

La réponse courte

Tant que vous effectuez une fusion à avance rapide , vous pouvez simplement utiliser

git fetch <remote> <sourceBranch>:<destinationBranch>

Exemples:

# Merge local branch foo into local branch master,
# without having to checkout master first.
# Here `.` means to use the local repository as the "remote":
git fetch . foo:master

# Merge remote branch origin/foo into local branch foo,
# without having to checkout foo first:
git fetch origin foo:foo

Bien que la réponse d'Amber fonctionne également dans les cas d'avance rapide, l'utilisation git fetchde cette manière est un peu plus sûre que le simple déplacement forcé de la référence de branche, car git fetchcela empêchera automatiquement les avances non rapides accidentelles tant que vous ne les utilisez pas +dans le refspec.

La réponse longue

Vous ne pouvez pas fusionner une branche B dans la branche A sans vérifier d'abord A si cela entraînerait une fusion sans avance rapide. En effet, une copie de travail est nécessaire pour résoudre tout conflit potentiel.

Cependant, dans le cas des fusions à avance rapide, cela est possible , car de telles fusions ne peuvent jamais entraîner de conflits, par définition. Pour ce faire sans vérifier d'abord une branche, vous pouvez utilisergit fetch avec une refspec.

Voici un exemple de mise à jour master(interdiction des modifications non rapides) si vous avez featureextrait une autre branche :

git fetch upstream master:master

Ce cas d'utilisation est si courant que vous voudrez probablement en faire un alias dans votre fichier de configuration git, comme celui-ci:

[alias]
    sync = !sh -c 'git checkout --quiet HEAD; git fetch upstream master:master; git checkout --quiet -'

Ce que cet alias fait est le suivant:

1. git checkout HEAD: ceci met votre copie de travail dans un état de tête détachée. Ceci est utile si vous souhaitez mettre à jour masterpendant que vous l'avez récupéré. Je pense que c'était nécessaire parce que sinon la référence de branche pour masterne bougera pas, mais je ne me souviens pas si c'est vraiment tout de suite.

2. git fetch upstream master:master: cela fait avancer rapidement votre section locale masterau même endroit que upstream/master.

3. git checkout -vérifie votre branche précédemment extraite (c'est ce que -fait dans ce cas).

La syntaxe de git fetchfor (non-) fast-forward merges

Si vous voulez que la fetchcommande échoue si la mise à jour n'est pas en avance rapide, alors vous utilisez simplement une spécification du formulaire

git fetch <remote> <remoteBranch>:<localBranch>

Si vous souhaitez autoriser les mises à jour sans avance rapide, vous ajoutez alors un +au début de la spécification de référence:

git fetch <remote> +<remoteBranch>:<localBranch>

Notez que vous pouvez passer votre dépôt local en tant que paramètre "distant" en utilisant .:

git fetch . <sourceBranch>:<destinationBranch>

La documentation

De la git fetchdocumentation qui explique cette syntaxe (soulignement le mien):

<refspec>

Le format d'un <refspec>paramètre est un plus facultatif +, suivi de la référence source <src>, suivi de deux points :, suivi de la référence destination <dst>.

La référence distante qui correspond <src>est récupérée, et s'il <dst>ne s'agit pas d'une chaîne vide, la référence locale qui la correspond est transmise rapidement à l'aide<src> . Si le plus facultatif+est utilisé, la référence locale est mise à jour même si elle n'entraîne pas une mise à jour rapide.

Voir également

1. Git checkout et fusionner sans toucher à l'arbre de travail

2. Fusion sans changer le répertoire de travail

Non, il n'y en a pas. Une extraction de la branche cible est nécessaire pour vous permettre de résoudre les conflits, entre autres (si Git n'est pas en mesure de les fusionner automatiquement).

Cependant, si la fusion est rapide, vous n'avez pas besoin de vérifier la branche cible, car vous n'avez en fait pas besoin de fusionner - tout ce que vous avez à faire est de mettre à jour la branche pour pointer vers le nouvelle tête ref. Vous pouvez le faire avec git branch -f:

git branch -f branch-b branch-a

Mettra à jour branch-bpour pointer vers le chef de branch-a.

L' -foption signifie --force, ce qui signifie que vous devez être prudent lorsque vous l'utilisez.

Ne l'utilisez que si vous êtes absolument sûr que la fusion sera rapide.

Comme l'a dit Amber, les fusions rapides sont le seul cas dans lequel vous pourriez imaginer faire cela. Toute autre fusion doit théoriquement passer par la fusion à trois, appliquer des correctifs, résoudre les conflits - et cela signifie qu'il doit y avoir des fichiers.

Il se trouve que j'ai un script que j'utilise exactement pour cela: faire des fusions d'avance rapide sans toucher à l'arbre de travail (sauf si vous fusionnez dans HEAD). Il est un peu long, car il est au moins un peu robuste - il vérifie que la fusion serait une avance rapide, puis l'exécute sans vérifier la branche, mais produisant les mêmes résultats que si vous l'aviez - vous voyez le diff --statrésumé des modifications, et l'entrée dans le reflog est exactement comme une fusion d'avance rapide, au lieu de la «réinitialisation» que vous obtenez si vous utilisez branch -f. Si vous nommez git-merge-ffet déposez - le dans votre répertoire bin, vous pouvez l' appeler comme une commande git: git merge-ff.

#!/bin/bash

_usage() {
    echo "Usage: git merge-ff <branch> <committish-to-merge>" 1>&2
    exit 1
}

_merge_ff() {
    branch="$1"
    commit="$2"

    branch_orig_hash="$(git show-ref -s --verify refs/heads/$branch 2> /dev/null)"
    if [ $? -ne 0 ]; then
        echo "Error: unknown branch $branch" 1>&2
        _usage
    fi

    commit_orig_hash="$(git rev-parse --verify $commit 2> /dev/null)"
    if [ $? -ne 0 ]; then
        echo "Error: unknown revision $commit" 1>&2
        _usage
    fi

    if [ "$(git symbolic-ref HEAD)" = "refs/heads/$branch" ]; then
        git merge $quiet --ff-only "$commit"
    else
        if [ "$(git merge-base $branch_orig_hash $commit_orig_hash)" != "$branch_orig_hash" ]; then
            echo "Error: merging $commit into $branch would not be a fast-forward" 1>&2
            exit 1
        fi
        echo "Updating ${branch_orig_hash:0:7}..${commit_orig_hash:0:7}"
        if git update-ref -m "merge $commit: Fast forward" "refs/heads/$branch" "$commit_orig_hash" "$branch_orig_hash"; then
            if [ -z $quiet ]; then
                echo "Fast forward"
                git diff --stat "$branch@{1}" "$branch"
            fi
        else
            echo "Error: fast forward using update-ref failed" 1>&2
        fi
    fi
}

while getopts "q" opt; do
    case $opt in
        q ) quiet="-q";;
        * ) ;;
    esac
done
shift $((OPTIND-1))

case $# in
    2 ) _merge_ff "$1" "$2";;
    * ) _usage
esac

PS Si quelqu'un voit des problèmes avec ce script, veuillez commenter! C'était un travail d'écriture et d'oubli, mais je serais heureux de l'améliorer.

Vous ne pouvez le faire que si la fusion est une avance rapide. Si ce n'est pas le cas, alors git doit faire extraire les fichiers pour pouvoir les fusionner!

Pour le faire pour une avance rapide uniquement :

git fetch <branch that would be pulled for branchB>
git update-ref -m "merge <commit>: Fast forward" refs/heads/<branch> <commit>

où <commit>est le commit récupéré, celui vers lequel vous souhaitez effectuer une avance rapide. C'est essentiellement comme utiliser git branch -fpour déplacer la branche, sauf qu'elle l'enregistre également dans le reflog comme si vous aviez réellement fait la fusion.

S'il vous plaît, s'il vous plaît, s'il vous plaît ne faites pas cela pour quelque chose qui n'est pas une avance rapide, ou vous allez simplement réinitialiser votre branche à l'autre commit. (Pour vérifier, voyez si git merge-base <branch> <commit>donne le SHA1 de la branche.)

Dans votre cas, vous pouvez utiliser

git fetch origin branchB:branchB

qui fait ce que vous voulez (en supposant que la fusion soit rapide). Si la branche ne peut pas être mise à jour car elle nécessite une fusion sans avance rapide, cela échoue en toute sécurité avec un message.

Cette forme de récupération propose également des options plus utiles:

git fetch <remote> <sourceBranch>:<destinationBranch>

Notez qu'il <remote> peut s'agir d'un référentiel local et <sourceBranch>peut être une branche de suivi. Vous pouvez donc mettre à jour une branche locale, même si elle n'est pas extraite, sans accéder au réseau .

Actuellement, mon accès au serveur en amont se fait via un VPN lent, donc je me connecte périodiquement, git fetchpour mettre à jour toutes les télécommandes, puis me déconnecter. Si, par exemple, le maître distant a changé, je peux le faire

git fetch . remotes/origin/master:master

pour mettre à jour mon maître local en toute sécurité, même si j'ai actuellement une autre succursale vérifiée. Aucun accès réseau requis.

Une autre façon, certes assez brute, est de simplement recréer la branche:

git fetch remote
git branch -f localbranch remote/remotebranch

Cela supprime la branche locale obsolète et en recrée une avec le même nom, alors utilisez-la avec précaution ...

Vous pouvez cloner le référentiel et faire la fusion dans le nouveau référentiel. Sur le même système de fichiers, cela liera en dur plutôt que de copier la plupart des données. Terminez en tirant les résultats dans le référentiel d'origine.

Entrez git-forward-merge :

Sans avoir à extraire la destination, git-forward-merge <source> <destination>fusionne la source dans la branche de destination.

https://github.com/schuyler1d/git-forward-merge

Fonctionne uniquement pour les fusions automatiques, s'il y a des conflits, vous devez utiliser la fusion régulière.

Dans de nombreux cas (comme la fusion), vous pouvez simplement utiliser la branche distante sans avoir à mettre à jour la branche de suivi locale. L'ajout d'un message dans le reflog sonne comme une surpuissance et l'empêchera d'être plus rapide. Pour faciliter la récupération, ajoutez ce qui suit dans votre configuration git

[core]
    logallrefupdates=true

Tapez ensuite

git reflog show mybranch

pour voir l'historique récent de votre succursale

J'ai écrit une fonction shell pour un cas d'utilisation similaire que je rencontre quotidiennement sur des projets. Il s'agit essentiellement d'un raccourci pour garder les succursales locales à jour avec une branche commune comme développer avant d'ouvrir un PR, etc.

Publier ceci même si vous ne voulez pas l'utiliser checkout, au cas où d'autres ne dérangeraient pas cette contrainte.

glmh("git pull and merge here") sera automatiquement checkout branchB, pullle plus récent, re checkout branchAet merge branchB.

Ne répond pas à la nécessité de conserver une copie locale de branchA, mais pourrait facilement être modifié pour ce faire en ajoutant une étape avant d'extraire branchB. Quelque chose comme...

git branch ${branchA}-no-branchB ${branchA}

Pour les fusions rapides simples, ceci passe à l'invite de message de validation.

Pour les fusions non rapides, cela place votre branche dans l'état de résolution de conflit (vous devrez probablement intervenir).

Pour configurer, ajouter à .bashrcou .zshrc, etc.:

glmh() {
    branchB=$1
    [ $# -eq 0 ] && { branchB="develop" }
    branchA="$(git branch | grep '*' | sed 's/* //g')"
    git checkout ${branchB} && git pull
    git checkout ${branchA} && git merge ${branchB} 
}

Usage:

# No argument given, will assume "develop"
> glmh

# Pass an argument to pull and merge a specific branch
> glmh your-other-branch

Remarque: ce n'est pas assez robuste pour transférer les arguments au-delà du nom de la branche versgit merge

Une autre façon de le faire efficacement est:

git fetch
git branch -d branchB
git branch -t branchB origin/branchB

Comme il s'agit d'un minuscule -d, il ne le supprimera que si les données existent toujours quelque part. C'est similaire à la réponse de @ kkoehne, sauf qu'elle ne force pas. À cause de -tcela, il réinstalle la télécommande.

J'avais un besoin légèrement différent de celui d'OP, qui était de créer une nouvelle branche de fonctionnalité develop(ou master), après avoir fusionné une demande d'extraction. Cela peut être accompli dans une ligne sans force, mais cela ne met pas à jour la developbranche locale . Il s'agit simplement de vérifier une nouvelle branche et de la baser sur origin/develop:

git checkout -b new-feature origin/develop

juste pour tirer le maître sans vérifier le maître que j'utilise

git fetch origin master:master

Il est absolument possible de faire n'importe quelle fusion, même les fusions non rapides, sans git checkout. La worktreeréponse de @grego est un bon indice. Pour développer cela:

cd local_repo
git worktree add _master_wt master
cd _master_wt
git pull origin master:master
git merge --no-ff -m "merging workbranch" my_work_branch
cd ..
git worktree remove _master_wt

Vous avez maintenant fusionné la branche de travail locale avec la masterbranche locale sans changer de caisse.

Si vous souhaitez conserver le même arbre que l'une des branches que vous souhaitez fusionner (c'est-à-dire pas une véritable "fusion"), vous pouvez le faire comme ceci.

# Check if you can fast-forward
if git merge-base --is-ancestor a b; then
    git update-ref refs/heads/a refs/heads/b
    exit
fi

# Else, create a "merge" commit
commit="$(git commit-tree -p a -p b -m "merge b into a" "$(git show -s --pretty=format:%T b)")"
# And update the branch to point to that commit
git update-ref refs/heads/a "$commit"

git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]

Vous pouvez essayer git worktreed'avoir deux branches ouvertes côte à côte, cela semble être ce que vous voulez, mais très différent de certaines des autres réponses que j'ai vues ici.

De cette façon, vous pouvez avoir deux branches distinctes dans le même référentiel git, vous n'avez donc qu'à récupérer une fois pour obtenir des mises à jour dans les deux arborescences de travail (plutôt que d'avoir à git cloner deux fois et git tirer sur chacune)

Worktree créera un nouveau répertoire de travail pour votre code où vous pouvez faire extraire une branche différente simultanément au lieu de permuter les branches en place.

Lorsque vous souhaitez l'enlever, vous pouvez nettoyer avec

git worktree remove [-f] <worktree>