Czy istnieje „ich” wersja „git merge -s ours”?

Kiedy łączę gałąź tematu „B” z „A” za pomocą git merge, mam pewne konflikty. Wiem, że wszystkie konflikty można rozwiązać za pomocą wersji w „B”.

Jestem tego świadomy git merge -s ours. Ale chcę czegoś takiego git merge -s theirs.

Dlaczego to nie istnieje? Jak mogę osiągnąć ten sam wynik po konflikcie scalania z istniejącymi gitpoleceniami? ( git checkoutkażdy niepołączony plik z B)

AKTUALIZACJA: „Rozwiązanie” polegające na odrzuceniu czegokolwiek z gałęzi A (punkt zatwierdzenia scalania do wersji B drzewa) nie jest tym, czego szukam.

Dodaj -Xopcję do theirs. Na przykład:

git checkout branchA
git merge -X theirs branchB

Wszystko połączy się w pożądany sposób.

Jedyne, co widziałem, powoduje problemy, jeśli pliki zostały usunięte z oddziału B. Pojawiają się jako konflikty, jeśli coś innego niż git usunęło.

Poprawka jest łatwa. Po prostu uruchom git rmz nazwą wszystkich plików, które zostały usunięte:

git rm {DELETED-FILE-NAME}

Następnie -X theirspowinno działać zgodnie z oczekiwaniami.

Oczywiście, faktyczne usunięcie za pomocą git rmpolecenia zapobiegnie wystąpieniu konfliktu.

Uwaga : istnieje również dłuższa opcja formularza.

Aby z niego skorzystać, zamień:

-X theirs

z:

--strategy-option=theirs

Możliwe i przetestowane rozwiązanie do połączenia oddziału B w naszym wyewidencjonowanym oddziale A:

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

Aby go zautomatyzować, możesz owinąć go w skrypt, używając argumentów branchA i branchB.

To rozwiązanie zachowuje pierwszy i drugi element nadrzędny zatwierdzenia scalania, tak jak można się spodziewać git merge -s theirs branchB.

Starsze wersje git pozwoliły na użycie „ich” strategii scalania:

git pull --strategy=theirs remote_branch

Ale od tego czasu zostało to usunięte, jak wyjaśniono w tym komunikacie Junio ​​Hamano (opiekun Git). Jak wspomniano w linku, zamiast tego zrobiłbyś to:

git fetch origin
git reset --hard origin

Uważaj jednak, że jest to coś innego niż faktyczne scalenie. Twoje rozwiązanie jest prawdopodobnie opcją, której naprawdę szukasz.

Nie jest do końca jasne, jaki jest twój pożądany wynik, więc istnieje pewne zamieszanie dotyczące „prawidłowego” sposobu robienia tego w odpowiedziach i komentarzach. Staram się dać przegląd i widzę następujące trzy opcje:

Spróbuj połączyć i użyj B w przypadku konfliktów

To nie jest „ich wersja dla git merge -s ours”, ale „ich wersja dla git merge -X ours” (co jest skrótem od git merge -s recursive -X ours):

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

Tak właśnie robi odpowiedź Alana W. Smitha .

Używaj treści tylko z B.

Tworzy to zatwierdzenie scalania dla obu gałęzi, ale odrzuca wszystkie zmiany branchAi tylko zatrzymuje zawartość branchB.

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

Zauważ, że scalanie zatwierdza pierwszego rodzica, teraz jest to od branchBi tylko drugie pochodzi od branchA. Tak właśnie działa odpowiedź Gandalf458 .

Używaj tylko treści z B i zachowaj prawidłową kolejność nadrzędną

To jest prawdziwa „ich wersja dla git merge -s ours”. Ma taką samą treść jak w poprzedniej opcji (tj. Tylko tę z branchB), ale kolejność rodziców jest prawidłowa, tzn. Pierwszy rodzic pochodzi z, branchAa drugi z branchB.

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

Tak właśnie robi odpowiedź Paula Pladijsa (bez konieczności tymczasowego odgałęzienia).

Odtąd korzystałem z odpowiedzi Paula Pladijsa. Dowiedziałem się, że możesz wykonać „normalne” scalenie, zdarzają się konflikty, więc tak

git checkout --theirs <file>

aby rozwiązać konflikt przy użyciu wersji z drugiego oddziału. Jeśli zrobisz to dla każdego pliku, zachowujesz się tak, jak można się spodziewać

git merge <branch> -s theirs

W każdym razie wysiłek jest większy niż w przypadku strategii łączenia! (Zostało to przetestowane w wersji git 1.8.0)

Rozwiązałem problem za pomocą

git checkout -m old
git checkout -b new B
git merge -s ours old

Kiedy łączę gałąź tematu „B” z „A” za pomocą git merge, mam pewne konflikty. Wiem> wszystkie konflikty można rozwiązać za pomocą wersji w „B”.

Jestem świadomy połączenia git - naszego. Ale chcę czegoś takiego jak git merge> -s ich.

Zakładam, że utworzyłeś gałąź master i teraz chcesz z powrotem połączyć się w master, zastępując wszystkie stare rzeczy w master. Właśnie to chciałem zrobić, kiedy natknąłem się na ten post.

Rób dokładnie to, co chcesz, z wyjątkiem pierwszego połączenia jednej gałęzi z drugą. Właśnie to zrobiłem i działało świetnie.

git checkout Branch
git merge master -s ours

Następnie sprawdź master i scal w nim swój oddział (teraz pójdzie gładko):

git checkout master
git merge Branch

Jeśli jesteś w oddziale A:

git merge -s recursive -X theirs B

Testowane na wersji git 1.7.8

Aby naprawdę poprawnie wykonać scalenie, które pobiera tylko dane wejściowe z gałęzi, którą scalasz, możesz to zrobić

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

W żadnym znanym mi scenariuszu nie będzie konfliktów, nie musisz tworzyć dodatkowych rozgałęzień, a to działa jak normalne zatwierdzenie scalania.

Nie działa to jednak dobrze z submodułami.

Dlaczego to nie istnieje?

Chociaż wspominam w „ poleceniu git, aby uczynić jedną gałąź podobną do drugiej ”, jak symulować git merge -s theirs, zauważcie , że Git 2.15 (IV kwartał 2017) jest teraz jaśniejszy:

Dokumentacja „ -X<option>” dla połączeń została wprowadzona w błąd, sugerując, że „ -s theirs” istnieje, co nie jest prawdą.

Zobacz zatwierdzenie c25d98b (25 września 2017 r.) Autor: Junio ​​C Hamano ( gitster) .
^{(Połączone przez Junio ​​C Hamano - gitster- w commit 4da3e23 , 28 września 2017)}

strategie scalania: unikaj sugerowania, że ​​„ -s theirs” istnieje

Opis -Xoursopcji scalania zawiera nawias, który mówi czytelnikom, że jest bardzo różny od -s ours, co jest poprawne, ale opis -Xtheirspo nim niedbale mówi „to jest przeciwieństwo ours”, dając fałszywe wrażenie, że czytelnicy również potrzebują Ostrzegam, że jest bardzo różny od -s theirs, który w rzeczywistości nawet nie istnieje.

-Xtheirsjest opcją strategiczną stosowaną do strategii rekurencyjnej. Oznacza to, że strategia rekurencyjna będzie nadal łączyć wszystko, co może, i powróci do theirslogiki tylko w przypadku konfliktu.

Ta debata na temat znaczenia lub braku theirsstrategii scalania została niedawno przywołana w tym wątku z września 2017 r .
Uznaje starsze (2008) wątki

Krótko mówiąc, poprzednią dyskusję można streścić w „nie chcemy” -s theirs, ponieważ zachęca to do niewłaściwego przepływu pracy ”.

Wspomina o aliasie:

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

Jarosław Halczenko próbuje raz jeszcze opowiedzieć się za tą strategią, ale Junio ​​C. Hamano dodaje :

Powodem, dla którego nasz i ich nie są symetryczne, jest to, że jesteście sobą, a nie nimi --- kontrola i własność naszej historii i ich historii nie jest symetryczna.

Gdy zdecydujesz, że ich historia jest główną linią, wolisz traktować swoją linię rozwoju jako gałąź boczną i dokonać scalenia w tym kierunku, tj. Pierwszy rodzic wynikowego scalenia jest zatwierdzeniem ich historii, a drugi rodzic jest ostatnim złym w twojej historii. Więc użyjesz „ checkout their-history && merge -s ours your-history”, aby zachować rozsądek dla pierwszego rodzicielstwa.

I w tym momencie użycie „ -s ours” nie jest już obejściem problemu z powodu braku „ -s theirs”.
Jest to właściwa część pożądanej semantyki, tzn. Z punktu widzenia ocalałej kanonicznej linii historii chcesz zachować to, co ona zrobiła, niwecząc to, co zrobiła druga linia historii .

Junio ​​dodaje, jak komentuje Mike Beaton :

git merge -s ours <their-ref>skutecznie mówi „zatwierdzanie znaków dokonane <their-ref>w ich oddziale jako zobowiązanie do trwałego zignorowania”;
i to ma znaczenie, ponieważ jeśli następnie scalisz z późniejszych stanów ich gałęzi, ich późniejsze zmiany zostaną wprowadzone bez zignorowanych zmian .

Zobacz szeroko cytowaną odpowiedź Junio ​​Hamano : jeśli zamierzasz odrzucić popełnione treści, po prostu odrzuć zatwierdzenia lub przynajmniej trzymaj je poza główną historią. Po co przeszkadzać wszystkim w przyszłości, czytając komunikaty zatwierdzeń z zatwierdzeń, które nie mają nic do zaoferowania?

Ale czasami są wymagania administracyjne, a może z innego powodu. W sytuacjach, w których naprawdę musisz rejestrować zatwierdzenia, które nic nie wnoszą, potrzebujesz:

(edytuj: wow, czy udało mi się wcześniej to zrobić źle. Ten działa.)

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

Ten używa drzewa poleceń git, ale skraca ogólny przepływ pracy.

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

Spowoduje to scalenie Twojego newBranch w istniejącym BaseBranch

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

Myślę, że tak naprawdę chcesz:

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

To wydaje się niezdarne, ale powinno działać. Jedyne, co naprawdę nie podoba mi się w tym rozwiązaniu, to to, że historia gita będzie myląca ... Ale przynajmniej historia zostanie całkowicie zachowana i nie będziesz musiał robić nic specjalnego dla usuniętych plików.

Odpowiednik (który utrzymuje porządek nadrzędny) „git merge -s ich oddział B”

Przed scaleniem:

!!! Upewnij się, że jesteś w czystości !!!

Wykonaj scalenie:

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

Co zrobiliśmy ? Stworzyliśmy nowy zatwierdzenie, którego dwoje rodziców, nasi i ich, a siecią zatwierdzeń jest oddział B - ich

Po scaleniu:

Dokładniej:

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

Odpowiedzi udzielił Paul Pladijs. Właśnie wziąłem jego polecenia i dla wygody utworzyłem alias git.

Edytuj swój .gitconfig i dodaj następujące elementy:

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

Następnie możesz „git merge -s theirs A”, uruchamiając:

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

Niedawno musiałem to zrobić dla dwóch osobnych repozytoriów, które mają wspólną historię. Zacząłem od:

• Org/repository1 master
• Org/repository2 master

Chciałem, aby wszystkie zmiany repository2 masterzostały zastosowane repository1 master, akceptując wszystkie zmiany, które wprowadziłoby repozytorium2. Mówiąc git, powinna to być strategia zwana -s theirsALE nie istnieje. Bądź ostrożny, ponieważ -X theirsjest tak nazwany, jakbyś tego chciał, ale to NIE jest to samo (nawet tak mówi na stronie podręcznika).

Sposób, w jaki to rozwiązałem, to udanie się repository2i utworzenie nowego oddziału repo1-merge. W tym oddziale prowadziłem git pull git@gitlab.com:Org/repository1 -s oursi wszystko w porządku, bez żadnych problemów. Następnie pcham go do pilota.

Potem wracam do repository1i tworzę nowy oddział repo2-merge. W tej gałęzi działam, git pull git@gitlab.com:Org/repository2 repo1-mergeco zakończy się problemami.

Na koniec musisz albo wysłać żądanie scalenia, repository1aby uczynić go nowym wzorcem, albo po prostu zachować jako gałąź.

Prostym i intuicyjnym (moim zdaniem) dwuetapowym sposobem na zrobienie tego jest

git checkout branchB .
git commit -m "Picked up the content from branchB"

śledzony przez

git merge -s ours branchB

(co oznacza dwie gałęzie jako połączone)

Jedyną wadą jest to, że nie usuwa plików, które zostały usunięte w oddziale B z bieżącego oddziału. Prosta różnica między dwiema gałęziami pokaże później, czy istnieją takie pliki.

Podejście to wyjaśnia również później z dziennika zmian, co zostało zrobione - i co było zamierzone.