Kiedy w trakcie dochodzi do kolizji git merge
, otwieram narzędzie scalające o nazwie Meld . Otwiera trzy pliki LOKALNE, BAZOWE i ZDALNE. Jak przeczytałem LOCAL to moja lokalna gałąź, BASE jest wspólnym przodkiem, a REMOTE to gałąź, która ma zostać scalona.
Teraz na moje pytanie: która wersja pliku zostanie ostatecznie wykorzystana? Czy to ZDALNE? Jeśli tak, czy mogę go edytować tak, jak chcę, niezależnie od tego, co jest na przykład w gałęzi BASE?
merge.conflictstyle
ustawioną opcję konfiguracjidiff3
zamiast domyślnejmerge
.HEAD
,<<<<<
i=====
znaki, to znaczy, że nie ma konfliktu w ogóle. W tym przypadku środkowe okno nie będzie puste, pokaże wynik scalenia, ale nie będzie „czerwonej” części<<<<<<
,======
ani>>>>>>
markerów w panelu środkowym (tj podstawowej wersji) albo; a czasami środkowe okienko będzie puste, jak zgłosił aGr. Może ta różnica wynika z różnych ustawień. Kiedy uruchomić narzędzie meldunku, będą istniały następujące pliki, zakładając, że nazwa pliku w repozytorium jestX.java
:X.java
,X.java.orig
,X.java.BACKUP.#
,X.java.BASE.#
,X.java.LOCAL.#
,X.java.REMOTE.#
, gdzie#
jest jakaś liczba. Nazywanie wyniku scalania wersją BASE jest mylące; MERGED byłoby lepsze.Meld ma ukrytą funkcję 3-drożnego scalania aktywowaną przez przekazanie czwartego parametru:
Prawe i lewe okienka są otwierane w trybie tylko do odczytu, więc nie można przypadkowo scalić w niewłaściwy sposób. Środkowy panel pokazuje wynik scalania. W przypadku konfliktów pokazuje wersję podstawową, dzięki czemu można zobaczyć wszystkie ważne elementy: oryginalny tekst w środku i sprzeczne modyfikacje po obu stronach. Wreszcie, po naciśnięciu przycisku „Zapisz”, zapisywany jest plik $ MERGED - dokładnie tak, jak oczekuje git.
Plik ~ / .gitconfig, którego używam, zawiera następujące ustawienia:
otwiera to połączenie z 3 kartami, pierwszą i drugą kartą zawierającą proste różnice, które próbuję scalić, a trzecia karta, otwarta domyślnie, pokazuje widok scalania 3-kierunkowego.
Powodem, dla którego ta funkcja jest ukryta, jest to, że nie jest jeszcze wystarczająco dopracowana. Jest to bardzo przydatne, tak jak jest teraz, ale Kai Willadsen, autor połączenia, wskazał na kilka zmarszczek, które wymagają wygładzenia. Na przykład nie ma GUI do uruchomienia trybu 3-drożnego scalania, składnia wiersza poleceń jest nieco tajemnicza i tak dalej. Jeśli mówisz w Pythonie i masz trochę czasu - wiesz, co robić.
Edycja: W nowszych wersjach Meld synx nieco się zmienił. To było w komentarzach, ale należy do odpowiedzi.
Polecenie meld używa teraz opcji --output, więc ostatnia linia z powyższego fragmentu powinna wyglądać następująco:
źródło
--output
dla wyniku $ MERGED. Odkryłem to, patrząc na skrypcie uruchomić Meld dostarczonym z mojej wersji git: github.com/git/git/blob/master/mergetools/meld--output option
. Zobacz tę linię w skrypcie uruchamiania:"$merge_tool_path" --output "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
cmd = meld $LOCAL $BASE $REMOTE --auto-merge --output $MERGED
. Tak więc, otwiera to 3 zakładki (stary dobry sposób), automatycznie łączy niekolidujące scalenia w środku, gdzie pośrodku jest $ MERGED, i zostanie użyte jako wyjście rozwiązywania konfliktów.--output=<file>
albo-o <file>
patrzmeld --help
W grę wchodzą 4 pliki:
$LOCAL
Plik w gałęzi, w której dokonujesz scalenia; po wyświetleniu nietknięte przez proces scalania$REMOTE
Plik w gałęzi, z której dokonujesz scalenia; po wyświetleniu nietknięte przez proces scalania$BASE
Wspólny przodek $ LOCAL i $ REMOTE, tj. punkt, w którym dwie gałęzie zaczęły przekierowywać rozpatrywany plik; po wyświetleniu nietknięte przez proces scalania$MERGED
Częściowo scalony plik z konfliktami; jest to jedyny plik, którego dotyczył proces scalania i właściwie nigdy nie został wyświetlony w formaciemeld
$MERGED
Plik jest taki, który zawiera<<<<<<
,>>>>>>
,=====
(i, być może,||||||
) (markery że konflikty wytyczają). To jest plik, który edytujesz ręcznie w celu naprawienia konfliktów.Ręczna edycja konfliktów i wizualna edycja konfliktów odbywa się na różnych plikach i przedstawia różne informacje.
Podczas korzystania z mergetool (zakładając
meld
), pliki, które widzą w nim to:$LOCAL
,$BASE
,$REMOTE
. Zwróć uwagę, że nie widzisz$MERGED
pliku, chociaż jest on przekazywany jako ukryty parametrmeld
do zapisania tam wyniku edycji.Innymi słowy, w programie
meld
edytujesz plik w środku,$BASE
plik i ręcznie wybierasz wszystkie zmiany od lewej lub prawej strony . Jest to czysty plik, którego nie dotyczył proces scalania. Jedyna usterka polega na tym, że podczas zapisywania nie zapisujesz do$BASE
pliku, ale w czwartym ukrytym parametrzemeld
, czyli$MERGED
pliku (którego nawet nie widzisz).$BASE
Plik ma nie zawierać żadnych konfliktów lub częściowe sukcesy scala ponieważ nie jest to$MERGED
plik .W edycji wizualnej, podczas prezentacji
$BASE
pliku (zamiast$MERGED
pliku) wgit
zasadzie odrzuca wszystkie próby scalenia (te próby są widoczne, jeśli chcesz, w pliku $ MERGED) i pozwala na całkowite scalenie od podstaw .Najważniejsze jest to, że podczas ręcznego i wizualnego łączenia konfliktów nie patrzysz na te same pliki, ale wynik końcowy jest zapisywany w tym samym pliku (to jest
$MERGED
plik).Instrukcja korekta konfliktów odbywa się na
$MERGED
ponieważgit
ma nie lada zaprezentować trzy pliki, więc to zgniecie informacje z trzech plików ($LOCAL
,$BASE
,$REMOTE
) w tym$MERGED
pliku.Ale narzędzia wizualne mają środków , aby pokazać trzy pliki: oni pokazać
$LOCAL
,$BASE
,$REMOTE
pliki. Jesteś zbierając od zmian$LOCAL
i$REMOTE
plików i przynoszą ci do$BASE
pliku, całkowicie re-building a nawet nadpisanie nieudanej próbie połączenia, które jest$MERGED
plik.źródło
$LOCAL
,$REMOTE
,$BASE
a wyjście początkowo równym$BASE
, ale która jest inna niż$MERGED
w tym, że nie ma próbę git do łączenia plików i znaczniki konfliktu i tak dalej. W rzeczywistości byłby to sposób użycia tych narzędzi, który jest najbardziej podobny do podejścia 3-panelowego LOCAL / REMOTE / BASE + OUTPUT, które nie jest połączone. Czwarte okienko pozwala tylko oddzielić podstawę od wyjścia.Rozwiązanie Cosmina działa, ale plik $ BASE jest aktualizowany - a nie $ MERGED . Spowoduje to zaktualizowanie pliku $ MERGED :
Połączenie:
v1.8.4
źródło
cmd = meld --auto-merge --output $MERGED $LOCAL $BASE $REMOTE
--diff $BASE $LOCAL --diff $BASE $REMOTE
na końcu? dla mnie na 1.8.4, to działa dobrze (o ile widzę):cmd = meld --auto-merge --output $MERGED $LOCAL $BASE $REMOTE
Dzięki Meld 1.7 rozwiązanie Tomka Bury'ego już nie działa.
Te ustawienia domyślne nie spełniają mnie:
Zamiast tego dla Meld> = 1,7 proponuję jedno z dwóch innych rozwiązań.
Pierwsze rozwiązanie :
Drugie rozwiązanie :
.gitconfig
Skopiuj i wklej to do swojego
.gitconfig
pliku, aby uzyskać rozwiązania opisane powyżej:Skopiuj i wklej to do
.gitconfig.local
pliku, aby ustawić meld17 lub meld16 tylko dla tego komputera, jeśli używasz pliku .gitconfig na wielu komputerach:źródło
cmd = meld $LOCAL $BASE $REMOTE --auto-merge
, środkowym okienkiem będzie $ BASE, a nie $ MERGE, który jest faktycznie używany jako wynik rozwiązywania konfliktów.Okazało się, że żaden z wyświetlonych plików domyślnych nie został zapisany. Meld pokazywał
$LOCAL
,$REMOTE
a$BASE
domyślnie. Żeby to zadziałało,$MERGED
zamiast tego musiałem zrobić meld show$BASE
. Umieszczając to w moim,~/.gitconfig
naprawiłem to dla mnie:Używam Arch, z:
źródło
Z jakiegoś powodu najnowsze wersje meldowania nie wyświetlają linii znaczników dodanych dla konfliktów (<<<<<<<, =======, >>>>>>>). Jeśli chcesz zobaczyć te linie, powinieneś zainstalować meld v 1.3.3 lub starszą.
źródło
Proszę zapoznać się z odpowiedzią Saada, aby uzyskać prawidłową odpowiedź.
Dzięki meldowaniu 1.8.1 na Ubuntu otrzymałem
i dodanie --output przed $ MERGED naprawiło to za mnie:
źródło