Scalanie, aktualizowanie i pobieranie gałęzi Git bez użycia kas

Pracuję nad projektem, który ma 2 gałęzie, A i B. Zazwyczaj pracuję na gałęzi A i łączę rzeczy z gałęzi B. Zazwyczaj robiłbym:

git merge origin/branchB

Chciałbym jednak zachować lokalną kopię oddziału B, ponieważ od czasu do czasu mogę sprawdzić oddział bez uprzedniego połączenia z moim oddziałem A. W tym celu zrobiłbym:

git checkout branchB
git pull
git checkout branchA

Czy istnieje sposób na wykonanie powyższej czynności za pomocą jednego polecenia i bez konieczności przełączania gałęzi tam iz powrotem? Czy powinienem tego używać git update-ref? W jaki sposób?

Krótka odpowiedź

Tak długo, jak wykonujesz szybkie przewijanie do przodu , możesz po prostu użyć

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

Przykłady:

# 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

Podczas gdy odpowiedź Amber będzie działać również w przypadkach szybkiego przewijania do przodu, użycie git fetchw ten sposób jest nieco bezpieczniejsze niż zwykłe przesunięcie odniesienia gałęzi, ponieważ git fetchautomatycznie zapobiegnie przypadkowemu nie przewinięciu do przodu, o ile nie użyjesz go +w refspec.

Długa odpowiedź

Nie można scalić gałęzi B z gałęzią A bez uprzedniego sprawdzenia A, jeśli spowodowałoby to scalenie nie do przodu. Wynika to z faktu, że kopia robocza jest potrzebna do rozwiązania wszelkich potencjalnych konfliktów.

Jest to jednak możliwe w przypadku połączeń szybkiego przewijania , ponieważ połączenia takie z definicji nigdy nie mogą prowadzić do konfliktów. Aby to zrobić bez uprzedniego sprawdzenia gałęzi, możesz użyć git fetchz refspec.

Oto przykład aktualizacji master(nie zezwalającej na zmiany inne niż szybkie przewijanie do przodu), jeśli masz featurewyewidencjonowany inny oddział :

git fetch upstream master:master

Ten przypadek użycia jest tak powszechny, że prawdopodobnie będziesz chciał utworzyć dla niego alias w pliku konfiguracyjnym git, taki jak ten:

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

Ten alias robi to:

1. git checkout HEAD: powoduje to oderwanie kopii roboczej. Jest to przydatne, jeśli chcesz dokonać aktualizacji, mastergdy zdarzyło się, że została wyewidencjonowana. Myślę, że było to konieczne, ponieważ w przeciwnym razie odwołanie do gałęzi masternie ruszy się, ale nie pamiętam, czy to naprawdę od razu z mojej głowy.

2. git fetch upstream master:master: szybko przesyła lokalną wiadomość masterw to samo miejsce, co upstream/master.

3. git checkout -sprawdza twoją poprzednio wyrejestrowaną gałąź (tak dzieje się -w tym przypadku).

Składnia git fetchfor (nie) szybkiego przewijania do przodu

Jeśli chcesz, aby fetchpolecenie zakończyło się niepowodzeniem, jeśli aktualizacja nie obsługuje szybkiego przewijania, wystarczy użyć refspec formularza

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

Jeśli chcesz zezwolić na aktualizacje nie do szybkiego przewijania, dodajesz znak +z przodu refspec:

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

Pamiętaj, że możesz przekazać swoje lokalne repozytorium jako parametr „zdalny”, używając .:

git fetch . <sourceBranch>:<destinationBranch>

Dokumentacja

Z git fetchdokumentacji wyjaśniającej tę składnię (wyróżnienie moje):

<refspec>

Format <refspec>parametru jest opcjonalnym plusem +, po którym następuje odwołanie źródłowe <src>, dwukropek :, a następnie odwołanie do miejsca docelowego <dst>.

Zdalne dopasowanie, które pasuje, <src>jest pobierane, a jeśli <dst>nie jest pustym ciągiem, lokalne odwołanie, które pasuje do niego, jest przewijane do przodu za pomocą<src> . Jeśli+zostanie użytyopcjonalny plus, lokalny numer referencyjny zostanie zaktualizowany, nawet jeśli nie spowoduje to aktualizacji do przodu.

Zobacz też

1. Przejdź do kasy i połącz bez dotykania działającego drzewa

2. Scalanie bez zmiany katalogu roboczego

Nie, nie ma. Wyewidencjonowanie gałęzi docelowej jest konieczne, aby między innymi rozwiązać konflikty (jeśli Git nie jest w stanie automatycznie ich scalić).

Jeśli jednak scalanie byłoby szybkie, nie trzeba sprawdzać gałęzi docelowej, ponieważ tak naprawdę nie trzeba niczego scalać - wystarczy zaktualizować gałąź, aby wskazywała nowa głowa ref. Możesz to zrobić za pomocą git branch -f:

git branch -f branch-b branch-a

Zaktualizuje się, branch-baby wskazywać na głowę branch-a.

-fOpcja oznacza --force, co oznacza, że trzeba być ostrożnym podczas korzystania z niego.

Nie używaj go, chyba że masz absolutną pewność, że scalenie zostanie przewinięte do przodu.

Jak powiedział Amber, szybkie połączenia do przodu to jedyny przypadek, w którym można to zrobić. Każde inne scalenie prawdopodobnie musi przejść przez całą trójstronną fuzję, stosowanie poprawek, rozwiązywanie konfliktów - a to oznacza, że ​​muszą istnieć pliki.

Tak się składa, że ​​mam skrypt, którego używam właśnie do tego: wykonuję scalanie do przodu bez dotykania drzewa roboczego (chyba że łączysz się w HEAD). Jest trochę długi, ponieważ jest co najmniej trochę solidny - sprawdza, czy scalenie będzie szybkie do przodu, a następnie wykonuje go bez sprawdzania gałęzi, ale daje takie same wyniki, jak gdybyś miał - widzisz diff --statpodsumowanie zmian, a wpis w reflogu jest dokładnie jak szybkie scalanie do przodu, zamiast „resetowania”, które otrzymujesz, jeśli używasz branch -f. Jeśli to nazwę git-merge-ffi upuść go w katalogu bin, można nazwać to jako polecenie 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 Jeśli ktoś zauważy jakiekolwiek problemy z tym skryptem, proszę o komentarz! To była praca polegająca na pisaniu i zapominaniu, ale chętnie ją poprawię.

Możesz to zrobić tylko wtedy, gdy scalenie jest przewijaniem do przodu. Jeśli nie, to git musi pobrać pliki, aby je scalić!

Aby to zrobić tylko w przypadku szybkiego przewijania do przodu :

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

gdzie <commit>jest pobrany commit, ten, do którego chcesz szybko przewinąć do przodu. Zasadniczo jest to jak użycie git branch -fdo przeniesienia gałęzi, z tym wyjątkiem, że rejestruje go również w dzienniku reflogu, tak jakby to było scalenie.

Proszę, proszę, proszę , nie rób tego za coś, co nie jest do przodu, czy to po prostu być zresetowanie oddziału na drugi popełnić. (Aby sprawdzić, sprawdź, czy git merge-base <branch> <commit>daje SHA1 oddziału).

W twoim przypadku możesz użyć

git fetch origin branchB:branchB

co robi, co chcesz (zakładając, że scalanie jest szybkie przewijanie do przodu). Jeśli gałąź nie może zostać zaktualizowana, ponieważ wymaga scalenia nie do szybkiego przewijania, oznacza to, że komunikat nie powiedzie się bezpiecznie.

Ta forma pobierania ma również kilka bardziej przydatnych opcji:

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

Pamiętaj, że <remote> może to być lokalne repozytorium i <sourceBranch>może być gałąź śledzenia. Możesz więc zaktualizować lokalny oddział, nawet jeśli nie jest wyewidencjonowany, bez dostępu do sieci .

Obecnie mój dostęp do serwera nadrzędnego odbywa się za pośrednictwem wolnej sieci VPN, więc okresowo łączę się, git fetchaby zaktualizować wszystkie piloty, a następnie rozłączam się. Jeśli, powiedzmy, zdalny mistrz zmienił się, mogę to zrobić

git fetch . remotes/origin/master:master

aby bezpiecznie zaktualizować mojego lokalnego mistrza, nawet jeśli obecnie mam jakiś inny oddział. Nie wymaga dostępu do sieci.

Innym, co prawda dość brutalnym sposobem jest po prostu odtworzenie oddziału:

git fetch remote
git branch -f localbranch remote/remotebranch

Wyrzuca to lokalną nieaktualną gałąź i odtwarza ją o tej samej nazwie, więc używaj jej ostrożnie ...

Możesz sklonować repozytorium i wykonać scalenie w nowym repozytorium. W tym samym systemie plików będzie to dowiązanie twarde zamiast kopiowania większości danych. Zakończ, przeciągając wyniki do oryginalnego repozytorium.

Wprowadź polecenie git-forward-merge :

Bez konieczności kasowania miejsca docelowego git-forward-merge <source> <destination>scala źródło w gałęzi docelowej.

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

Działa tylko w przypadku automatycznych połączeń, jeśli występują konflikty, należy użyć zwykłego scalania.

W wielu przypadkach (takich jak scalanie) możesz po prostu użyć zdalnego oddziału bez konieczności aktualizacji lokalnego oddziału śledzenia. Dodanie wiadomości do reflogu brzmi jak przesada i przestanie być szybsze. Aby ułatwić odzyskiwanie, dodaj następujące elementy do konfiguracji git

[core]
    logallrefupdates=true

Następnie wpisz

git reflog show mybranch

aby zobaczyć najnowszą historię swojego oddziału

Napisałem funkcję powłoki dla podobnego przypadku użycia, z którym spotykam się codziennie w projektach. Jest to w zasadzie skrót do aktualizowania lokalnych oddziałów za pomocą wspólnego oddziału, takiego jak rozwijanie przed otwarciem PR itp.

Publikowanie tego, nawet jeśli nie chcesz go używać checkout, na wypadek, gdyby inni nie mieli nic przeciwko temu ograniczeniu.

glmh(„git pull and merge here”) automatycznie checkout branchB, pullnajnowsze, ponownie checkout branchAi merge branchB.

Nie rozwiązuje potrzeby przechowywania lokalnej kopii oddziału A, ale można ją łatwo zmodyfikować, dodając krok przed sprawdzeniem oddziału B. Coś jak...

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

W przypadku prostych operacji szybkiego przewijania następuje przejście do monitu komunikatu zatwierdzenia.

W przypadku połączeń bez szybkiego przewijania powoduje to, że oddział znajduje się w stanie rozwiązywania konfliktu (prawdopodobnie konieczna jest interwencja).

Aby skonfigurować, dodać do .bashrclub .zshrcitp .:

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} 
}

Stosowanie:

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

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

Uwaga: Nie jest to wystarczająco odporne na przekazywanie argumentów poza nazwą oddziału dogit merge

Innym sposobem na skuteczne wykonanie tego jest:

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

Ponieważ jest to mała litera -d, usunie ją tylko, jeśli dane gdzieś nadal będą istnieć. Jest podobny do odpowiedzi @ kkoehne, tyle że nie wymusza. Z tego powodu -tponownie skonfiguruje pilota.

Miałem nieco inną potrzebę niż OP, która polegała na utworzeniu nowej gałęzi funkcji poza develop(lub master) po scaleniu żądania ściągnięcia. Można tego dokonać w jednej linijce bez użycia siły, ale nie aktualizuje ona lokalnego developoddziału. To tylko kwestia sprawdzenia nowego oddziału i oparcia go na origin/develop:

git checkout -b new-feature origin/develop

po prostu wyciągnąć mistrza bez sprawdzania mistrza, którego używam

git fetch origin master:master

Absolutnie możliwe jest wykonanie dowolnego scalenia, a nawet nie szybkich połączeń do przodu git checkout. worktreeOdpowiedź przez @grego to dobra wskazówka. Aby rozwinąć tę kwestię:

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

Teraz połączyłeś lokalny oddział pracy z lokalnym masteroddziałem bez zmiany kasy.

Jeśli chcesz zachować to samo drzewo co gałąź, którą chcesz scalić (tzn. Nie jest to prawdziwe „scalenie”), możesz to zrobić w ten sposób.

# 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>]

Możesz spróbować git worktreeotworzyć dwie gałęzie obok siebie, to może brzmieć tak, jakbyś tego chciał, ale bardzo różni się od niektórych innych odpowiedzi, które tu widziałem.

W ten sposób możesz mieć dwie osobne gałęzie śledzące w tym samym repozytorium git, więc musisz pobrać tylko raz, aby uzyskać aktualizacje w obu drzewach roboczych (zamiast klonować dwa razy i ciągnąć każde z nich)

Worktree utworzy nowy katalog roboczy dla twojego kodu, w którym możesz jednocześnie wyewidencjonować inną gałąź zamiast zamiany gałęzi na miejsce.

Kiedy chcesz go usunąć, możesz to wyczyścić

git worktree remove [-f] <worktree>