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


876

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.


1
Zobacz także tę odpowiedź: stackoverflow.com/questions/928646/… - zmiana przykładu, aby użyć wersji B zamiast A., jest banalna
Robie Basak,

8
Zobacz SO odpowiedź git, aby utworzyć jedną gałąź jak drugą dla wszystkich obecnych możliwych sposobów symulacjigit merge -s their .
VCC,

4
Więc tak naprawdę nie szukasz git merge -s theirs(można to łatwo osiągnąć git merge -s oursi tymczasowej gałęzi), ponieważ - nasz całkowicie ignoruje zmiany połączenia z gałęzi ...
Nicolò Martini

21
@Torek - Czy Git DEVS naprawdę znaleźć to , że ofensywa zapewnić theirsoprócz ours??? Jest to objaw jednego z problemów inżynieryjnych i projektowych wysokiego poziomu w Git: niespójności.
jww

3
@jww Problem nie polega na tym, że „git merge -s ours” jest obraźliwy, ale na sprzeczności z intuicją. Z pytania PO można zobaczyć, że gdyby taka funkcja została dodana, użyłby jej przez pomyłkę, gdy tak naprawdę chciałby to zrobić „git merge -s recursive -X ich”. Często łączy się inną gałąź zastępującą konflikty z wersją w innej gałęzi, ale całkowite zastąpienie bieżącej gałęzi inną gałęzią całkowicie odrzucającą zmiany obecnej jest naprawdę wyjątkiem.
ThomazMoura

Odpowiedzi:


1019

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

6
Zobacz inne odpowiedzi poniżej, aby uzyskać lepsze rozwiązanie (Paul Pladijs) na pierwotne pytanie.
Malcolm,

204
Warto zauważyć, że to nie to samo, co „strategia scalania theirs”. -Xtheirs to opcja strategii zastosowana do strategii rekurencyjnej . Oznacza to, że strategia rekurencyjna nadal scali wszystko, co może, i powróci do logiki „swojej” tylko w przypadku konfliktów. Chociaż w większości przypadków jest to potrzebne, nie jest to to samo, co „po prostu weź wszystko z gałęzi B w takiej postaci, w jakiej jest”. I tak zamiast tego dokonuje prawdziwego scalenia.
Timur

2
Działa również z innymi poleceniami. Właśnie zrobiłem „git cherry-pick sha1 -X ich”. Dzięki!
Max Hohenegger

48
To okropna odpowiedź, ponieważ wygląda poprawnie, ale w rzeczywistości jest zła. „git merge -X ich” nie robi tego, co zrobiłby „git merge -s ich”. Nie zastępuje bieżącej gałęzi treścią scalonej gałęzi. Woli zmiany „ich”, ale tylko w przypadku konfliktu. Dlatego wynikowe zatwierdzenie może różnić się od gałęzi „ich”. Nie to miał na myśli plakat z pytaniami.
Ivan Krivyakov

7
@ user3338098: tak, masz rację. Ponownie przeczytałem pytanie, które również nie jest tak dobre. Niestety podstawową przyczyną zamieszania nie jest odpowiedź, a nawet pytanie. Wybór projektu git polega na nadaniu tej samej nazwy „naszej” strategii scalania oraz opcji „rekurencyjnej” strategii scalania. Zamieszanie w tym przypadku jest praktycznie nieuniknione.
Ivan Krivyakov

218

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.


P: Dlaczego potrzebujesz BranchTEMP? Nie mogłeś po prostu git reset --soft branchA?
cdunn2001

4
@ cdunn2001: Jakoś myślałem o tym samym, ale nie. Zauważ, że git reset --hardzmiany, które zatwierdzają, branchAwskazują.
Tsuyoshi Ito,

5
przepraszam, że zadałem głupie pytanie, ale dlaczego ta metoda jest lepsza od -xtheirs? jakie są zalety / wady
chrispepper1989

9
@ chrispepper1989 -x ich wpływa tylko na konflikty , jeśli kawałek naszego może być zastosowany czysto, przejdzie do wynikowego scalenia. W tym przypadku, jak pokazuje ostatnie polecenie, otrzymujemy scalenie, które jest całkowicie identyczne z odgałęzieniem B, niezależnie od tego, czy wystąpiłyby konflikty, czy nie.
UncleZeiv,

2
@UncleZeiv dziękuję za wyjaśnienie, więc w zasadzie wykonanie „ich” zachowałoby niezakłócone zmiany i pliki wynikające z kodu int, który nie jest identyczny z pobranym kodem.
chrispepper1989

89

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.


7
Naprawdę w ogóle nie rozumiem wyjaśnień Junio ​​Hamano. W jaki git reset --hard originsposób rozwiązanie ich scalenia stylu? Gdybym chciał połączyć BranchB z BranchA (jak w odpowiedzi Alana W. Smitha), jak miałbym to zrobić przy użyciu tej resetmetody?
James McMahon,

3
@James McMahon: Uwaga Junio ​​C. Hamano nie git reset --hardłączy się w stylu „ich”. Oczywiście git reset --hardnie tworzy żadnego zatwierdzenia scalania ani żadnego zatwierdzenia w tej sprawie. Chodzi o to, że nie powinniśmy używać scalania, aby zastąpić cokolwiek w HEAD czymś innym. Jednak niekoniecznie się zgadzam.
Tsuyoshi Ito,

11
Szkoda, że theirszostały usunięte, ponieważ uzasadnienie było niepełne. Nie uwzględnił przypadków, w których kod jest dobry, po prostu to, że upstream jest utrzymywany na innej podstawie filozoficznej, więc w tym sensie jest „zły”, więc zarówno chcemy być na bieżąco z upstreamem, ale jednocześnie zachowują dobre „poprawki” kodu [git i msysgit mają ten „konflikt” z powodu filozofii różnych platform docelowych]
Philip Oakley

1
Brakuje również przypadku, w którym utknąłem w tej chwili, kiedy dzielę gałąź z kimś innym i oboje zdarzyło się jednocześnie wypychać zmiany (w różnych plikach). Chcę więc usunąć wszystkie stare wersje, które mam lokalnie, i zamiast tego użyć jego nowszych. On chce zrobić to samo dla plików, które zaktualizowałem. Nie ma nic do „zresetowania”. Rozwiązanie kasowania każdego pojedynczego pliku nie jest praktyczne, gdy jest to ~ 20 plików.
szeitlin

2
Naprawdę nie rozumiem filozofii. Po prostu użyłem, theirsponieważ przypadkowo zmieniłem niektóre pliki w dwóch oddzielnych gałęziach i chciałem odrzucić zmiany jednego bez konieczności ręcznego wykonywania tego dla każdego pliku.
sudo,

65

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).


git checkout branchA; git merge -s ours --no-commit branchB; git read-tree -um @ branchB; git commit
Czystsza

@jthill: Chociaż twoja wersja jest bardziej zwięzła, używa także komendy niskiego poziomu ("hydraulika") read-tree, do której przeciętny użytkownik git może nie być przyzwyczajony (przynajmniej ja nie ;-)). Rozwiązania zawarte w odpowiedzi używają tylko poleceń wysokiego poziomu („porcelany”), które większość użytkowników gita powinna wiedzieć. Wolę je, ale mimo wszystko dziękuję za twoją wersję!
siegi

Czy potrafisz wyjaśnić od drugiego do ostatniego kroku (gałąź kasy A)? Wygląda na to, że nie powinno tam być.
Patrick,

@Patrick, ten krok jest wymagany. Jeśli go pominiesz, dostaniesz to samo zatwierdzenie, ale nie miałbyś gałęzi wskazującej na to zatwierdzenie. Gdy tylko przejdziesz do innego zatwierdzenia / gałęzi, zatwierdzenie wykonane za pomocą ostatniego polecenia ( …commit --amend…) zostanie „utracone”.
Planuję

62

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)


1
byłoby świetnie, gdyby można było pobrać listę plików. Na przykład, git ls-files --modified | xargs git addchciałem to zrobić dla dodanego po obu stronach scalenia: /
andho

Właściwie git zwraca dodane pliki po obu stronach, git ls-files --modifiedwięc myślę, że jest to również realne rozwiązanie.
andho

1
Dziękujemy za dodanie tego również. Częściej nie jest to potrzebne w systemie plik po pliku. Ponadto status git pokazuje „Unmerged Paths” na samym dole. Aby uzyskać listę nierozwiązanych ścieżek, używam tego aliasu:git config --global alias.unresolved '!git status --short|egrep "^([DAU])\1"'
Melvyn

jakie jest znaczenie -Xi jaka jest różnica między -Xi -s? nie mogę znaleźć żadnego dokumentu.
Lei Yang,

21

Rozwiązałem problem za pomocą

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

gałąź „B” ze „starej” gałęzi
elmarco

13

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

1
Dzięki. To powinna być zaakceptowana odpowiedź, zdecydowanie najprostsza i najbardziej poprawna. Jeśli twoja gałąź jest opóźniona / jest w konflikcie z master, to jej zadaniem jest scalenie i sprawienie, aby wszystko działało przed scaleniem wszystkiego z master.
StackHola

Działa niesamowicie, dziękuję.
Kodie Grantham

12

Jeśli jesteś w oddziale A:

git merge -s recursive -X theirs B

Testowane na wersji git 1.7.8


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.


Co tutaj robi -R?
P. Myer Nore

W ten sposób tracisz historię plików „przeniesionych i zmienionych”. Czy mam rację?
elysch

1
Wartość -R jest - odwrotna, zaktualizowałem odpowiedź, aby była bardziej samodokumentująca.
Elijah Lynn

Nie wydaje się to działać, jeśli pliki, które próbujesz scalić, zostaną usunięte w gałęzi przychodzącej.
rozwiązywanieJ17

7

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 .


1
Jest to przydatna odpowiedź, ale nie wspomina o jednym kluczowym punkcie, który właśnie zrozumiałem z odpowiedzi Junio ​​C. Hamano: git merge -s ours <their-ref>skutecznie mówi „znak commits złożony do <their-ref> w swojej gałęzi 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 wprowadzania ignorowanych zmian.
MikeBeaton

1
@MikeBeaton Dziękuję. W odpowiedzi umieściłem twój komentarz dla większej widoczności.
VonC

5

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

3

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>

0

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

Sugeruję dodanie git commit --amendna końcu twojego przykładu, w przeciwnym razie użytkownicy mogą zobaczyć zatwierdzenie scalania git logi założyć, że operacja została zakończona.
Michael R

0

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.


0

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

Przed scaleniem:wprowadź opis zdjęcia tutaj

!!! 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:wprowadź opis zdjęcia tutaj

Dokładniej:

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

0

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

-1

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łąź.


-2

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.


może to być poprawne w przypadku pierwotnego pytania, jednak PO zaktualizowało pytanie w 2008 r. w taki sposób, że ta odpowiedź jest nieprawidłowa.
user3338098,

1
@ user3338098 Tak, taka szkoda, że opuścił tytuł mylący i tylko poklepał nie tak widoczny aktualizacji na koniec ciała zapytania .... bo to odpowiedzi nie odpowiedzieć poprawnie na tytułowe pytanie.
RomainValeri

Całkowicie zgadzam się z @RomainValeri
AppleCiderGuy
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.