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 fetch
w ten sposób jest nieco bezpieczniejsze niż zwykłe przesunięcie odniesienia gałęzi, ponieważ git fetch
automatycznie 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 fetch
z refspec.
Oto przykład aktualizacji master
(nie zezwalającej na zmiany inne niż szybkie przewijanie do przodu), jeśli masz feature
wyewidencjonowany 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:
git checkout HEAD
: powoduje to oderwanie kopii roboczej. Jest to przydatne, jeśli chcesz dokonać aktualizacji, master
gdy zdarzyło się, że została wyewidencjonowana. Myślę, że było to konieczne, ponieważ w przeciwnym razie odwołanie do gałęzi master
nie ruszy się, ale nie pamiętam, czy to naprawdę od razu z mojej głowy.
git fetch upstream master:master
: szybko przesyła lokalną wiadomość master
w to samo miejsce, co upstream/master
.
git checkout -
sprawdza twoją poprzednio wyrejestrowaną gałąź (tak dzieje się -
w tym przypadku).
Składnia git fetch
for (nie) szybkiego przewijania do przodu
Jeśli chcesz, aby fetch
polecenie 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 fetch
dokumentacji 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ż
Przejdź do kasy i połącz bez dotykania działającego drzewa
Scalanie bez zmiany katalogu roboczego