git-merge — Online w chmurze

PROGRAM:

IMIĘ

git-merge — Połącz ze sobą dwie lub więcej historii rozwoju

STRESZCZENIE

odrzutowiec łączyć [-n] [--stat] [--no-commit] [--squash] [--[no-]edycja]
[-S ] [-X ] [-S[ ]]
[--[no-]rerere-autoupdate] [-m ] [ ...]
odrzutowiec łączyć GŁOWA ...
odrzutowiec łączyć --anulować

OPIS

Zawiera zmiany z nazwanych zatwierdzeń (od czasu, gdy ich historie odbiegły od
bieżącą gałąź) do bieżącej gałęzi. To polecenie jest używane przez odrzutowiec Ciągnąć do
włączać zmiany z innego repozytorium i można ich używać ręcznie do scalania zmian z
jedną gałąź w drugą.

Załóżmy, że istnieje następująca historia, a bieżąca gałąź to „master”:

Temat A---B---C
/
D---E---F---G mistrz

Następnie „git merge topic” odtworzy zmiany wprowadzone w gałęzi tematu od czasu jej rozejścia się
od wzorca (tj. E) aż do bieżącego zatwierdzenia (C) na wierzchu wzorca i zapisz wynik
w nowym zatwierdzeniu wraz z nazwami dwóch zatwierdzeń nadrzędnych i komunikatem dziennika z pliku
użytkownik opisujący zmiany.

Temat A---B---C
/
D---E---F---G---H mistrz

Druga składnia ( GŁOWA ...) jest wspierany ze względów historycznych. Nie używaj
go z wiersza poleceń lub w nowych skryptach. Działa tak samo, jak git merge -m
....

Trzecią składnię („git merge --abort”) można uruchomić dopiero po zakończeniu scalania
konflikty. odrzutowiec łączyć --anulować przerwie proces scalania i spróbuje zrekonstruować plik
stan przed połączeniem. Jeśli jednak na początku scalania wystąpiły niezatwierdzone zmiany (i
zwłaszcza jeśli zmiany te uległy dalszej modyfikacji już po rozpoczęciu fuzji), odrzutowiec łączyć
--anulować w niektórych przypadkach nie będzie możliwe odtworzenie oryginalnych zmian (sprzed połączenia).
W związku z tym:

Ostrzeżenie: Bieganie odrzutowiec łączyć z nietrywialnymi niezatwierdzonymi zmianami jest odradzane: while
to możliwe, może to spowodować, że wpadniesz w stan, z którego trudno będzie się wycofać w przypadku: a
konflikt.

OPCJE

--zobowiązuj się, --nie-zobowiązuj się
Wykonaj scalenie i zatwierdź wynik. Tej opcji można użyć do nadpisania
--bez-zobowiązań.

Za pomocą --no-commit wykonaj scalanie, ale udawaj, że scalanie się nie powiodło i nie zatwierdzaj automatycznie,
aby dać użytkownikowi szansę wcześniejszego sprawdzenia i dalszego dostosowania wyniku scalania
zobowiązanie się.

--edytuj, -e, --no-edytuj
Wywołaj edytor przed dokonaniem pomyślnego scalenia mechanicznego w celu dalszej edycji
automatycznie generowana wiadomość o scaleniu, aby użytkownik mógł wyjaśnić i uzasadnić połączenie. The
Opcja --no-edit może być użyta do zaakceptowania automatycznie wygenerowanej wiadomości (jest to generalnie
zniechęcony). Opcja --edit (lub -e) jest nadal przydatna, jeśli podajesz wersję roboczą
wiadomość z opcją -m z wiersza poleceń i chcesz ją edytować w edytorze.

Starsze skrypty mogą zależeć od historycznego zachowania polegającego na nie zezwalaniu użytkownikowi na edycję
komunikat dziennika scalania. Zobaczą otwarty edytor, gdy uruchomią git merge. Robić
łatwiej dostosować takie skrypty do zaktualizowanego zachowania, zmienną środowiskową
GIT_MERGE_AUTOEDIT można ustawić na nie na ich początku.

--ff
Gdy scalanie zostanie rozwiązane jako szybkie przewijanie do przodu, zaktualizuj tylko wskaźnik gałęzi, bez
tworzenie zatwierdzenia scalania. To jest zachowanie domyślne.

--no-off
Utwórz zatwierdzenie scalania, nawet jeśli scalanie zostanie rozwiązane jako szybkie przewijanie do przodu. To jest
domyślne zachowanie podczas scalania tagu z adnotacją (i prawdopodobnie podpisanego).

--ff-tylko
Odmów scalenia i wyjścia ze statusem niezerowym, chyba że obecny HEAD już jest
aktualne lub połączenie może zostać rozwiązane jako szybkie przewijanie do przodu.

--log[= ], --no-log
Oprócz nazw gałęzi wypełnij komunikat dziennika jednowierszowymi opisami from
najbardziej rzeczywiste zatwierdzenia, które są scalane. Zobacz też git-fmt-merge-msg(1).

Z --no-log nie wyświetlaj jednowierszowych opisów z rzeczywistych scalanych zatwierdzeń.

--stat, -n, --no-stat
Pokaż diffstat na końcu scalania. Diffstat jest również kontrolowany przez
opcja konfiguracji merge.stat.

Z -n lub --no-stat nie pokazuj diffstat na końcu scalania.

--squash, --no-squash
Utwórz drzewo robocze i stan indeksu tak, jakby doszło do prawdziwego scalenia (z wyjątkiem pliku
scal informacje), ale tak naprawdę nie dokonuj zatwierdzenia, nie przesuwaj HEAD ani nie nagrywaj
$GIT_DIR/MERGE_HEAD (aby spowodować, że następne polecenie git commit utworzy zatwierdzenie scalania).
Pozwala to na utworzenie pojedynczego zatwierdzenia na górze bieżącej gałęzi, którego efektem jest
to samo, co połączenie kolejnej gałęzi (lub więcej w przypadku ośmiornicy).

Za pomocą opcji --no-squash wykonaj scalenie i zatwierdź wynik. Tej opcji można użyć do
zastąp --squash.

-s , --strategia=
Użyj podanej strategii scalania; można podać więcej niż jeden raz, aby określić je w pliku
kolejności należy je wypróbować. Jeśli nie ma opcji -s, oznacza to wbudowaną listę strategii
używany zamiast (odrzutowiec scalanie-rekurencyjne podczas łączenia pojedynczej głowy, odrzutowiec Połącz-ośmiornica
Inaczej).

-X , --strategia-opcja=
Przekaż opcję specyficzną dla strategii scalania do strategii scalania.

--weryfikuj-podpisy, --no-weryfikuj-podpisy
Sprawdź, czy łączone zatwierdzenia mają dobre i zaufane podpisy GPG i przerwij
połączenie, jeśli tego nie zrobią.

--podsumowanie, --no-podsumowanie
Synonimy dla --stat i --no-stat; są one przestarzałe i zostaną usunięte w
przyszłość.

-q, --cichy
Działaj cicho. Oznacza brak postępu.

-v, --pełne
Bądź gadatliwy.

--postęp, --brak-postępu
Włącz/wyłącz postęp jawnie. Jeśli nie określono żadnego z nich, wyświetlany jest postęp if
błąd standardowy jest podłączony do terminala. Należy pamiętać, że nie wszystkie strategie łączenia mogą
wspierać raportowanie postępów.

-S[ ], --gpg-sign[= ]
GPG-podpisz wynikowe zatwierdzenie scalania. Argument keyid jest opcjonalny i domyślnie wynosi
tożsamość osoby wykonującej; jeśli jest określony, musi być przyklejony do opcji bez spacji.

-M
Ustaw komunikat zatwierdzenia, który będzie używany podczas zatwierdzenia scalającego (jeśli taki został utworzony).

Jeśli podano --log, krótki dziennik łączonych zatwierdzeń zostanie dołączony do pliku
określony komunikat.

Kurs odrzutowiec fmt-merge-msg polecenia można użyć, aby zapewnić dobre ustawienie domyślne dla automatycznego odrzutowiec
łączyć modły. Wiadomość automatyczna może zawierać opis branży.

--[nie-]ponowna-automatyczna aktualizacja
Zezwól mechanizmowi rerere na aktualizację indeksu w wyniku automatycznego konfliktu
rozwiązanie, jeśli to możliwe.

--anulować
Przerwij bieżący proces rozwiązywania konfliktów i spróbuj odtworzyć stan sprzed połączenia
stan.

Jeśli w momencie rozpoczęcia scalania istniały niezatwierdzone zmiany w drzewie roboczym, odrzutowiec łączyć
--anulować w niektórych przypadkach nie będzie w stanie odtworzyć tych zmian. Dlatego jest
zaleca się, aby zawsze zatwierdzać lub ukrywać zmiany przed uruchomieniem odrzutowiec łączyć.

odrzutowiec łączyć --anulować odpowiada odrzutowiec zresetuj --łączyć gdy występuje MERGE_HEAD.

...
Zobowiązuje się, zwykle innych szefów oddziałów, do połączenia się z naszym oddziałem. Określając więcej niż
jedno zatwierdzenie spowoduje połączenie z więcej niż dwoma rodzicami (pieszczotliwie zwane an
połączenie ośmiornic).

Jeśli z wiersza poleceń nie zostanie podane żadne zatwierdzenie, połącz gałęzie zdalnego śledzenia
bieżąca gałąź jest skonfigurowana do używania jako jej nadrzędna gałąź. Zobacz także konfigurację
rozdział tej strony podręcznika.

Kiedy określono FETCH_HEAD (i nie określono żadnego innego zatwierdzenia), gałęzie zapisane w pliku
plik .git/FETCH_HEAD po poprzednim wywołaniu git fetch w celu scalania jest łączony
obecny oddział.

PRZED POŁĄCZENIEM CZEKI

Przed wprowadzeniem zmian zewnętrznych powinieneś zadbać o dobrą kondycję i zaangażowanie swojej pracy
lokalnie, więc nie zostanie zakłócony w przypadku konfliktów. Zobacz też git-schowek(1). odrzutowiec
Ciągnąć i odrzutowiec łączyć zatrzyma się bez robienia czegokolwiek, gdy lokalne niezatwierdzone zmiany nakładają się
z plikami, które odrzutowiec Ciągnąć/odrzutowiec łączyć może wymagać aktualizacji.

Aby uniknąć rejestrowania niepowiązanych zmian w zatwierdzeniu scalania, odrzutowiec Ciągnąć i odrzutowiec łączyć będzie również
przerwij, jeśli w indeksie zarejestrowano jakiekolwiek zmiany w stosunku do zatwierdzenia HEAD. (Jeden
Wyjątkiem jest sytuacja, gdy zmienione wpisy indeksu znajdują się w stanie, który wynikałby z
już połączyć.)

Jeśli wszystkie nazwane zatwierdzenia są już przodkami HEAD, odrzutowiec łączyć wyjdzie wcześniej z
komunikat „Już aktualne”.

SZYBKO DO PRZODU MERGE

Często bieżący szef oddziału jest przodkiem nazwanego zatwierdzenia. Jest to najczęstsze
przypadek, zwłaszcza gdy zostanie wywołany z odrzutowiec Ciągnąć: śledzisz repozytorium nadrzędne, ty
nie wprowadziłeś żadnych lokalnych zmian, a teraz chcesz zaktualizować do nowszej wersji źródłowej.
W tym przypadku nowe zatwierdzenie nie jest potrzebne do przechowywania połączonej historii; zamiast tego GŁOWA
(wraz z indeksem) jest aktualizowany tak, aby wskazywał nazwane zatwierdzenie, bez tworzenia dodatkowego
scalić zatwierdzenie.

To zachowanie można stłumić za pomocą opcji --no-ff.

TRUE MERGE

Z wyjątkiem szybkiego łączenia w przód (patrz wyżej), łączone gałęzie muszą być powiązane
razem poprzez zatwierdzenie scalania, którego obydwoje są rodzicami.

Zatwierdzana jest wersja scalona, ​​uzgadniająca zmiany ze wszystkich łączonych gałęzi, oraz
twoja HEAD, indeks i drzewo robocze zostaną do niego zaktualizowane. Istnieje możliwość wprowadzenia modyfikacji
w drzewie roboczym, o ile się nie pokrywają; aktualizacja je zachowa.

Gdy nie jest oczywiste, jak pogodzić zmiany, dzieje się co następuje:

1. Wskaźnik HEAD pozostaje taki sam.

2. Odniesienie MERGE_HEAD jest ustawione tak, aby wskazywało drugą głowicę gałęzi.

3. Ścieżki, które zostały prawidłowo połączone, są aktualizowane zarówno w pliku indeksu, jak i w drzewie roboczym.

4. W przypadku sprzecznych ścieżek plik indeksu rejestruje maksymalnie trzy wersje: etap 1 przechowuje plik
wersja od wspólnego przodka, etap 2 od HEAD i etap 3 od MERGE_HEAD (ty
można sprawdzić etapy za pomocą git ls-files -u). Pliki drzewa roboczego zawierają plik
wynik programu „scalania”; tj. wyniki łączenia trójstronnego ze znanymi znacznikami konfliktu
<<< === >>>.

5. Nie wprowadza się żadnych innych zmian. W szczególności lokalne modyfikacje, które miałeś przed sobą
rozpoczęte scalanie pozostanie takie samo, a wpisy indeksu dla nich pozostaną takie same, jak były,
tj. dopasowanie HEAD.

Jeśli próbowałeś scalić, co spowodowało złożone konflikty i chcesz zacząć od nowa, możesz
odzyskaj za pomocą git merge --abort.

ŁĄCZENIE TAG

Podczas scalania znacznika z adnotacjami (i ewentualnie podpisanego) Git zawsze tworzy zatwierdzenie scalania
nawet jeśli możliwe jest szybkie scalanie do przodu i przygotowano szablon komunikatu zatwierdzenia
wiadomość tagu. Dodatkowo, jeśli tag jest podpisany, sprawdzenie podpisu jest raportowane jako a
komentarz w szablonie wiadomości. Zobacz też tag git(1).

Kiedy chcesz po prostu zintegrować się z pracą prowadzącą do zatwierdzenia, które akurat ma miejsce
oznaczone, np. synchronizując z wcześniejszym punktem wydania, możesz nie chcieć tworzyć
niepotrzebne zatwierdzenie scalania.

W takim przypadku możesz samodzielnie „rozpakować” tag przed przesłaniem go do git merge lub przekazać
--ff-tylko wtedy, gdy nie masz żadnej pracy samodzielnie. np

git pobierz pochodzenie
git merge v1.2.3^0
git merge --ff-only v1.2.3

JAK KONFLIKTY SĄ PRZEDSTAWIONE

Podczas scalania pliki drzewa roboczego są aktualizowane w celu odzwierciedlenia wyniku scalania.
Wśród zmian wprowadzonych do wersji wspólnego przodka znajdują się te, które nie nakładają się na siebie (tzn.
zmieniłeś obszar pliku, podczas gdy druga strona pozostawiła ten obszar nienaruszony lub odwrotnie)
są dosłownie uwzględniane w wyniku końcowym. Kiedy obie strony dokonały zmian w tym samym
Jednakże Git nie może losowo wybrać jednej strony zamiast drugiej i prosi Cię o rozwiązanie
pozostawiając to, co obie strony zrobiły w tym obszarze.

Domyślnie Git używa tego samego stylu, którego używa program „merge” z RCS
zestaw do przedstawienia tak sprzecznego przystojniaka, jak ten:

Oto linie, które albo nie zmieniły się od wspólnych
przodka lub całkowicie rozwiązane, ponieważ zmieniła się tylko jedna strona.
<<<<<<< Twoje:przykład.txt
Rozwiązywanie konfliktów jest trudne;
chodźmy na zakupy.
=======
Git ułatwia rozwiązywanie konfliktów.
>>>>>>> ich:przykład.txt
A oto kolejna linia, która została całkowicie rozwiązana lub niezmodyfikowana.

Obszar, w którym nastąpiła para sprzecznych zmian, jest oznaczony znacznikami <<<<<<<,
======= i >>>>>>>. Część przed ======= to zazwyczaj twoja strona i ta część
potem jest zazwyczaj po ich stronie.

Domyślny format nie pokazuje treści oryginału w obszarze powodującym konflikt. Ty
nie mogę powiedzieć, ile linijek zostało usuniętych i zastąpionych uwagą Barbie z twojej strony. The
jedyne, co możesz powiedzieć, to to, że twoja strona chce powiedzieć, że jest to trudne i że wolisz odejść
zakupy, podczas gdy druga strona chce twierdzić, że jest to łatwe.

Można użyć alternatywnego stylu, ustawiając konfigurację „merge.confusedStyle”.
zmienną na „diff3”. W stylu „diff3” powyższy konflikt może wyglądać następująco:

Oto linie, które albo nie zmieniły się od wspólnych
przodka lub całkowicie rozwiązane, ponieważ zmieniła się tylko jedna strona.
<<<<<<< Twoje:przykład.txt
Rozwiązywanie konfliktów jest trudne;
chodźmy na zakupy.
|||||||
Rozwiązywanie konfliktów jest trudne.
=======
Git ułatwia rozwiązywanie konfliktów.
>>>>>>> ich:przykład.txt
A oto kolejna linia, która została całkowicie rozwiązana lub niezmodyfikowana.

Oprócz znaczników <<<<<<<, ======= i >>>>>>> używa jeszcze innego ||||||| znacznik
po którym następuje tekst oryginalny. Można powiedzieć, że oryginał po prostu stwierdził fakt,
a twoja strona po prostu poddała się temu stwierdzeniu i poddała się, podczas gdy druga strona próbowała
mieć bardziej pozytywne nastawienie. Czasami można wymyślić lepszą rozdzielczość
obejrzenie oryginału.

JAK DO ROZWIĄZAĆ KONFLIKTY

Po zobaczeniu konfliktu możesz zrobić dwie rzeczy:

· Zdecyduj się nie łączyć. Jedyne, czego potrzebujesz, to zresetowanie pliku indeksu do formatu
HEAD zobowiązał się do odwrócenia 2. i oczyszczenia zmian w drzewie roboczym dokonanych w 2. i 3.; git
merge --abort można do tego użyć.

· Rozwiązuj konflikty. Git zaznaczy konflikty w drzewie roboczym. Edytuj pliki
do kształtu i odrzutowiec Dodaj je do indeksu. Używać odrzutowiec popełnić przypieczętować umowę.

Konflikt można rozwiązać za pomocą kilku narzędzi:

· Użyj narzędzia mergetool. git mergetool, aby uruchomić graficzne narzędzie mergetool, które będzie dla Ciebie odpowiednie
poprzez fuzję.

· Spójrz na różnice. git diff pokaże trójstronną różnicę, podkreślając zmiany z
zarówno wersje HEAD, jak i MERGE_HEAD.

· Przyjrzyj się różnicom w każdej gałęzi. git log --merge -p najpierw pokaże różnice
dla wersji HEAD, a następnie wersji MERGE_HEAD.

· Spójrz na oryginały. git show :1:filename pokazuje wspólnego przodka, git show
:2:filename pokazuje wersję HEAD, a git show :3:filename pokazuje wersję MERGE_HEAD
wersja.

PRZYKŁADY

· Połącz poprawki i ulepszenia gałęzi z bieżącą gałęzią, tworząc ośmiornicę
łączyć:

$ git merge naprawia ulepszenia

· Połącz przestarzałą gałąź z obecną gałęzią, korzystając z naszej strategii łączenia:

$ git merge -s nasz jest przestarzały

· Połącz gałąź maint z bieżącą gałęzią, ale nie dokonuj nowego zatwierdzenia
automatycznie:

$ git merge --no-commit maint

Można tego użyć, jeśli chcesz lub chcesz uwzględnić dalsze zmiany w scalaniu
napisz własną wiadomość o zatwierdzeniu scalania.

Powinieneś powstrzymać się od nadużywania tej opcji w celu przemycenia istotnych zmian w procesie scalania
popełniać. Drobne poprawki, takie jak zmiana nazwy wydania/wersji, byłyby dopuszczalne.

MERGE STRATEGIE

Mechanizm scalania (komendy git merge i git pull) pozwala backendowi łączyć strategie
do wyboru z opcją -s. Niektóre strategie mogą również przyjmować własne opcje, które mogą być
przeszedł dając -X argumenty do git merge i/lub git pull.

rozwiązać
To może rozwiązać tylko dwie głowy (tj. bieżącą gałąź i inną gałąź, którą wyciągnąłeś
from) przy użyciu algorytmu scalania trójdrożnego. Próbuje dokładnie wykryć łączenie krzyżowe
niejasności i jest ogólnie uważany za bezpieczny i szybki.

rekurencyjne
To może rozwiązać tylko dwie głowy przy użyciu algorytmu łączenia 3-kierunkowego. Kiedy jest więcej niż
jednego wspólnego przodka, którego można użyć do 3-kierunkowego scalania, tworzy połączone drzewo
wspólnych przodków i wykorzystuje to jako drzewo odniesienia dla 3-kierunkowego scalania. To ma
zgłoszono, że powoduje mniej konfliktów scalania bez powodowania błędnych połączeń w testach
wykonane na rzeczywistych zatwierdzeniach scalania zaczerpniętych z historii rozwoju jądra Linuksa 2.6.
Dodatkowo może to wykrywać i obsługiwać scalanie obejmujące zmiany nazw. To jest ustawienie domyślne
strategia scalania podczas ciągnięcia lub łączenia jednej gałęzi.

Kurs rekurencyjne strategia może przyjąć następujące opcje:

niedźwiedź
Ta opcja wymusza automatyczne, czyste rozwiązywanie sprzecznych porcji przez faworyzowanie ludzkiej,
wersja. Zmiany z innego drzewa, które nie są sprzeczne z naszą stroną, są
odzwierciedlenie w wyniku scalania. W przypadku pliku binarnego pobierana jest cała zawartość
z naszej strony.

Nie należy tego mylić z niedźwiedź strategia scalania, na którą nawet nie wygląda
co w ogóle zawiera inne drzewo. Odrzuca wszystko, co zrobiło inne drzewo,
deklarowania ludzkiej, historia zawiera wszystko, co się w niej wydarzyło.

ich
To jest przeciwieństwo niedźwiedź.

cierpliwość
Dzięki tej opcji scalanie-rekurencyjne spędza trochę więcej czasu, aby uniknąć pomyłek
które czasami występują z powodu nieistotnych pasujących linii (np. nawiasy klamrowe z different
Funkcje). Użyj tego, gdy gałęzie, które mają zostać połączone, znacznie się rozeszły. Zobacz też
git-diff(1) – cierpliwość.

diff-algorithm=[cierpliwość|minimalny|histogram|myers]
mówi scalanie-rekurencyjne użyć innego algorytmu porównywania, co może pomóc w uniknięciu
błędne scalanie, które występuje z powodu nieistotnych pasujących linii (takich jak nawiasy klamrowe z
odrębne funkcje). Zobacz też git-diff(1) --diff-algorytm.

ignorować-zmianę-spacji, ignorować-całą-spację, ignorować-spację-w-eol
Traktuje wiersze ze wskazanym typem zmiany białych znaków jako niezmienione dla programu
ze względu na trójstronną fuzję. Zmiany białych znaków zmieszane z innymi zmianami linii
nie są ignorowane. Zobacz też git-diff(1) -b, -w i --ignore-space-at-eol.

· Gdyby ich wersja wprowadza tylko zmiany białych znaków w linii, ludzkiej, wersja
używany;

· Gdyby ludzkiej, wersja wprowadza zmiany białych znaków, ale ich wersja zawiera a
znaczna zmiana, ich używana jest wersja;

· W przeciwnym razie fuzja przebiega w zwykły sposób.

renormalizować
Uruchamia to wirtualne wyewidencjonowanie i zaewidencjonowanie wszystkich trzech etapów pliku kiedy
rozwiązywanie trójstronnego łączenia. Ta opcja jest przeznaczona do łączenia oddziałów
z różnymi czystymi filtrami lub regułami normalizacji końca linii. Zobacz „Łączenie
gałęzie z różnymi atrybutami meldowania/kasowania” w gitatrybuty(5) dla
detale.

nie-renormalizuj
Wyłącza opcję ponownej normalizacji. To zastępuje merge.renormalize
zmienna konfiguracyjna.

próg zmiany nazwy =
Kontroluje próg podobieństwa używany do wykrywania zmiany nazwy. Zobacz też git-diffSkładowanie
-M.

poddrzewo[= ]
Ta opcja jest bardziej zaawansowaną formą poddrzewo strategia, gdzie strategia czyni
zgadnij, jak dwa drzewa muszą zostać przesunięte, aby pasowały do ​​siebie podczas łączenia.
Zamiast tego określona ścieżka jest poprzedzona (lub usunięta od początku), aby utworzyć
pasujące do siebie kształty dwóch drzew.

ośmiornica
To rozwiązuje sprawy z więcej niż dwiema głowami, ale odmawia wykonania złożonego scalania
wymaga ręcznego rozwiązania. Jest przeznaczony przede wszystkim do łączenia gałęzi tematycznej
głowy razem. Jest to domyślna strategia scalania przy pobieraniu lub scalaniu więcej niż
jeden oddział.

niedźwiedź
To rozwiązuje dowolną liczbę orłów, ale wynikowe drzewo scalania jest zawsze takie
bieżącego szefa oddziału, skutecznie ignorując wszystkie zmiany ze wszystkich innych oddziałów.
Ma służyć do zastąpienia starej historii rozwoju gałęzi bocznych. Notatka
że różni się to od opcji -Xours do rekurencyjne strategia fuzji.

poddrzewo
Jest to zmodyfikowana strategia rekurencyjna. Podczas łączenia drzew A i B, jeśli B odpowiada
poddrzewo A, B jest najpierw dostosowywane tak, aby pasowało do struktury drzewa A zamiast
odczytywanie drzew na tym samym poziomie. Ta regulacja jest również wykonywana dla wspólnego
drzewo przodków.

Dzięki strategiom wykorzystującym 3-kierunkowe scalanie (w tym domyślne, rekurencyjne), jeśli zmiana
zostanie dokonana na obu gałęziach, ale później cofnięta na jednej z gałęzi, ta zmiana nastąpi
obecny w połączonym wyniku; niektórzy uważają to zachowanie za mylące. Dzieje się tak, ponieważ
tylko głowice i podstawa scalania są brane pod uwagę podczas przeprowadzania scalania, a nie
indywidualne zobowiązania. Algorytm scalania uważa więc cofniętą zmianę za nie
zmienić w ogóle i zamiast tego zastępuje zmienioną wersję.

KONFIGURACJA

łączenie.konfliktStyle
Określ styl, w jakim sprzeczne porcje są zapisywane w plikach drzewa roboczego
łączyć. Wartość domyślna to „scal”, co pokazuje znacznik konfliktu <<<<<<<, zmiany wprowadzone przez
z jednej strony, znacznik =======, zmiany wprowadzone przez drugą stronę, a następnie znacznik >>>>>>>.
Alternatywny styl „diff3” dodaje ||||||| znacznik i oryginalny tekst przed
======= znacznik.

merge.defaultToUpstream
Jeżeli scalanie zostanie wywołane bez żadnego argumentu zatwierdzenia, należy scalić skonfigurowane gałęzie nadrzędne
dla bieżącej gałęzi, używając ich ostatnich zaobserwowanych wartości przechowywanych w ich
oddziały zdalnie śledzące. Wartości gałęzi. .scal tę nazwę
oddziały na pilocie nazwane według oddziału. .remote są konsultowane i
następnie są mapowane zdalnie. .fetch do odpowiedniego zdalnego śledzenia
gałęzie, a końcówki tych gałęzi śledzących są łączone.

scalić.ff
Domyślnie Git nie tworzy dodatkowego zatwierdzenia scalającego podczas scalania zatwierdzenia, które jest a
potomek bieżącego zatwierdzenia. Zamiast tego jest wierzchołek bieżącej gałęzi
przewijane do przodu. Gdy ustawiona jest na false, ta zmienna mówi Gitowi, aby utworzył dodatkowe scalanie
w takim przypadku zatwierdzić (co jest równoznaczne z podaniem opcji --no-ff z wiersza poleceń).
Gdy jest ustawione na only, dozwolone są tylko takie szybkie połączenia do przodu (co jest równoznaczne z podaniem
--ff-only opcja z wiersza poleceń).

merge.branchdesc
Oprócz nazw gałęzi wypełnij komunikat dziennika tekstem opisu gałęzi
z nimi związane. Domyślnie jest to fałsz.

scalaj.log
Oprócz nazw gałęzi wypełnij komunikat dziennika maksymalnie określonymi nazwami
liczba jednoliniowych opisów z rzeczywistych zatwierdzeń, które są łączone.
Domyślnie ustawiona jest wartość false, a true jest synonimem liczby 20.

merge.renameLimit
Liczba plików, które należy wziąć pod uwagę podczas wykrywania zmiany nazwy podczas scalania; Jeśli
nie określono, domyślnie przyjmuje wartość diff.renameLimit.

scal.renormalizuj
Powiedz Gitowi, że zmieniła się reprezentacja kanoniczna plików w repozytorium
time (np. wcześniej zatwierdza pliki tekstowe z nagraniami z końcówkami linii CRLF, ale najnowsze
użyj końcówek linii LF). W takim repozytorium Git może konwertować dane zapisane w
zobowiązuje się do postaci kanonicznej przed wykonaniem scalania, aby zmniejszyć niepotrzebne konflikty.
Aby uzyskać więcej informacji, zobacz sekcję „Łączenie oddziałów z różnymi meldunkami/kasami
atrybuty” w gitatrybuty(5).

scalaj.stat
Czy drukować różnicę między ORIG_HEAD a wynikiem scalania na końcu
łączyć. Domyślnie prawda.

narzędzie scalania
Kontroluje, które narzędzie scalania jest używane git-mergetool(1). Poniższa lista pokazuje prawidłowe
wbudowane wartości. Każda inna wartość jest traktowana jako niestandardowe narzędzie scalania i wymaga, aby a
odpowiednie narzędzie do łączenia. Zdefiniowano zmienną .cmd.

· araks

· pne

· pne3

· porównanie kodów

· Deltawalker

· różnicować

· rozproszony

· wyłaniać się

· wyłonić się

· gvimdiff

· gvimdiff2

· gvimdiff3

· kdiff3

· połączenie

· otwórz różnicę

· p4merge

· tkdiff

· żółw

· vimdiff

· vimdiff2

· vimdiff3

· winmerge

· xxdiff

scalanie.gadatliwości
Kontroluje ilość danych wyjściowych pokazywanych przez strategię scalania rekurencyjnego. Wyjścia poziomu 0
nic poza końcowym komunikatem o błędzie w przypadku wykrycia konfliktów. Tylko wyjścia poziomu 1
konflikty, 2 konflikty wyjściowe i zmiany plików. Debugowanie wyjść na poziomie 5 i wyższym
Informacja. Wartość domyślna to poziom 2. Można go zastąpić przez GIT_MERGE_VERBOSITY
zmienna środowiskowa.

łączyć. .nazwa
Definiuje czytelną dla człowieka nazwę niestandardowego sterownika scalania niskiego poziomu. Widzieć
gitatrybuty(5) szczegóły.

łączyć. .kierowca
Definiuje polecenie implementujące niestandardowy sterownik scalania niskiego poziomu. Widzieć
gitatrybuty(5) szczegóły.

łączyć. .rekursywny
Nazywa niskopoziomowy sterownik scalania, który ma być używany podczas wewnętrznego scalania pomiędzy
wspólnych przodków. Widzieć gitatrybuty(5) szczegóły.

oddział. .mergeOpcje
Ustawia domyślne opcje łączenia w oddział . Składnia i obsługiwane opcje
są takie same jak te z odrzutowiec łączyć, ale wartości opcji zawierające białe znaki
nie są obecnie obsługiwane.

Użyj git-merge online, korzystając z usług onworks.net