Pytanie Jak rozwiązywać konflikty seryjne w Git


Czy istnieje dobry sposób wyjaśnienia, jak rozwiązać konflikty scalania w Git?


4134
2017-10-02 11:31


pochodzenie


Poniższy wpis na blogu wydaje się być bardzo dobrym przykładem na to, jak poradzić sobie z konfliktem z Git, który powinien sprawić, że podążysz we właściwym kierunku. Obsługa i unikanie konfliktów w Git - mwilliams
Możesz skonfigurować narzędzie scalania (kdiff3 jebaird.com/2013/07/08/...), a następnie użyj git mergetool. Pracując w dużych zespołach programistów zawsze napotykasz konflikty związane z scalaniem. - Grady G Cooper
Nie zapominaj, że możesz złagodzić większość konfliktów scalających poprzez regularne scalanie kolejnych kanałów! - Ant P
Zobacz także git-tower.com/learn/git/ebook/command-line/tools-services/... - Pacerier
Wydaje się, że jest to szczegółowy samouczek - githubtraining.com/fix-merge-conflict-git-using-sourcetree - Rajavanya Subramaniyan


Odpowiedzi:


Próbować: git mergetool

Otwiera GUI, który prowadzi użytkownika przez każdy konflikt i można wybrać sposób scalania. Czasem wymaga to później ręcznej edycji, ale zwykle wystarcza sama. To znacznie lepsze niż robienie wszystkiego ręcznie z pewnością.

Zgodnie z komentarzem @JoshGlover:

Polecenie niekoniecznie otwiera GUI, chyba że je zainstalujesz. Bieganie git mergetool dla mnie zaowocowało vimdiff używane. Możesz zainstalować jedno z następujących narzędzi, aby go użyć: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Poniżej znajduje się przykładowa procedura do użycia vimdiff do rozwiązywania konfliktów scalania. Oparte na ten link

Krok 1: Uruchom następujące polecenia w terminalu

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

Spowoduje to ustawienie vimdiff jako domyślnego narzędzia scalania.

Krok 2: Uruchom następujące polecenie w terminalu

git mergetool

Krok 3: Zobaczysz ekran vimdiff w następującym formacie

  +----------------------+
  |       |      |       |
  |LOCAL  |BASE  |REMOTE |
  |       |      |       |
  +----------------------+
  |      MERGED          |
  |                      |
  +----------------------+

Te 4 widoki są

LOCAL - jest to plik z bieżącej gałęzi

BASE - wspólny przodek, jak plik wyglądał przed obydwoma zmianami

ZDALNIE - plik, który łączysz ze swoją gałęzią

POŁĄCZONY - wynik połączenia, to jest to, co zostaje zapisane w repozytorium

Możesz nawigować między tymi widokami za pomocą ctrl+w. Możesz bezpośrednio dotrzeć do widoku MERGED za pomocą ctrl+w śledzony przez j.

Więcej informacji o nawigacji vimdiff tutaj i tutaj

Krok 4. Możesz edytować widok MERGED w następujący sposób

Jeśli chcesz uzyskać zmiany z REMOTE

:diffg RE  

Jeśli chcesz uzyskać zmiany z BASE

:diffg BA  

Jeśli chcesz uzyskać zmiany z LOCAL

:diffg LO 

Krok 5. Zapisz, wyjdź, zatwierdz i wyczyść

:wqa zapisz i wyjdź z vi

git commit -m "message"

git clean Usuń dodatkowe pliki (np. * .Orig) utworzone przez narzędzie diff.


2425
2017-10-02 17:50



FYI możesz użyć git mergetool -y aby zapisać kilka naciśnięć klawiszy, jeśli łączysz wiele plików naraz. - davr
Cóż, niekoniecznie otwiera GUI, chyba że go zainstalujesz. Bieganie git mergetool dla mnie zaowocowało vimdiff używane. Możesz zainstalować jedno z następujących narzędzi, aby go użyć: meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse ecmerge p4merge araxis vimdiff emerge. - Josh Glover
Dobry punkt Josh. Na ubuntu Miałem szczęście z meldunkiem, jego trójdzielny wyświetlacz scalania nie jest zły. Na OSX git wybrał fajne domyślne. - Peter Burns
To otworzyło KDiff3. Którego absolutnie nie mam pojęcia, jak go używać. - David Murdoch
Nie rozumiem, dlaczego ta odpowiedź otrzymała tak wiele przebojów, nie jest bardzo pomocna, ponieważ zawiera tylko to jedno polecenie i absolutnie nie ma żadnego wyjaśnienia, jak z niego korzystać. Jak powiedzieli inni, otworzyło to vimdiff i nawet jeśli wiem, jak używać vima (przynajmniej zamień okna lub zamknij je), nie wiem nawet, co każde okno reprezentuje ani jak porównywać, ani akceptować zmian. Miło jest wiedzieć, że istnieje takie polecenie, ale bez wyjaśnienia, jak go używać lub instalować inne narzędzia, to bezużyteczna odpowiedź - Petr


Oto prawdopodobny przypadek użycia, od góry:

Zamierzasz wprowadzić pewne zmiany, ale oops, nie jesteś na bieżąco:

git fetch origin
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

Otrzymujesz aktualną wersję i próbujesz ponownie, ale masz konflikt:

git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

Więc postanawiasz rzucić okiem na zmiany:

git mergetool

Och, och, och, moje zmiany zmieniły pewne rzeczy, ale po to, żeby wykorzystać moje zmiany ... nie ... ich zmiany ...

git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

A potem próbujemy po raz ostatni

git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Ta-da!


1610
2017-08-04 17:04



To było bardzo pomocne, ponieważ miałem mnóstwo błędów scalania z plikami binarnymi (zasoby sztuki) i scalanie tych wydaje się zawsze zawieść, więc muszę je nadpisywać zawsze nowym plikiem, a nie "scalać" - petrocket
Ostrożny! Znaczenie --ours i --theirs jest odwrócone. --ours == pilot. --theirs == local. Widzieć git merge --help - mmell
W moim przypadku, potwierdzam, że -theirs = zdalne repozytorium, --ours = moje własne lokalne repozytorium. Jest przeciwieństwem komentarzy @mmell. - Aryo
@mmell Tylko na bazie, najwyraźniej. Widzieć this question - Navin
Faceci, "nasi" i "ich" odnoszą się do tego, czy się łączycie, czy też nie. Jeśli jesteś łączenie, "nasza" oznacza gałąź, z którą się łączysz, a "ich" jest gałęzią, z którą się łączysz. Kiedy jesteś przerzucanie, "nasze" oznacza zatwierdzenia, na które się opierasz, podczas gdy "ich" odnosi się do zatwierdzeń, które chcesz zmienić.


Narzędzia do scalania rzadko pomagają mi zrozumieć konflikt lub rozdzielczość. Zwykle bardziej skutecznie patrzę na znaczniki konfliktu w edytorze tekstów i korzystam z git log jako suplementu.

Oto kilka wskazówek:

Tip One

Najlepszą rzeczą, jaką znalazłem, jest użycie stylu konfliktu "diff3":

git config merge.conflictstyle diff3

Powoduje to tworzenie takich znaczników konfliktu:

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

Środkowa sekcja jest tym, co wyglądał wspólny przodek. Jest to użyteczne, ponieważ można je porównać z wersją górną i dolną, aby lepiej zrozumieć, co zostało zmienione w każdej gałęzi, co daje lepsze wyobrażenie o tym, jaki był cel każdej zmiany.

Jeśli konflikt jest tylko kilku linijkami, zazwyczaj powoduje to, że konflikt jest bardzo oczywisty. (Wiedza o tym, jak rozwiązać konflikt, jest zupełnie inna - musisz wiedzieć, nad czym pracują inni ludzie. Jeśli jesteś zdezorientowany, prawdopodobnie najlepiej jest po prostu zadzwonić do tej osoby, aby mógł zobaczyć, czego szukasz w.)

Jeśli konflikt się wydłuży, podzielę i wkleję każdą z trzech sekcji w trzy oddzielne pliki, takie jak "moje", "wspólne" i "ich".

Następnie mogę uruchomić następujące polecenia, aby zobaczyć dwie porcje diff, które spowodowały konflikt:

diff common mine
diff common theirs

To nie jest to samo, co użycie narzędzia scalania, ponieważ narzędzie do scalania będzie zawierało także wszystkie nieporównywalne porcje diff. Uważam, że to rozprasza.

Wskazówka druga

Ktoś już o tym wspominał, ale zrozumienie intencji kryjącej się za każdym facetem diff jest bardzo pomocne w zrozumieniu, skąd wziął się konflikt i jak sobie z nim poradzić.

git log --merge -p <name of file>

To pokazuje wszystkie zatwierdzenia, które dotknęły tego pliku pomiędzy wspólnym przodkiem a dwoma głowami, które łączysz. (Więc nie zawiera zatwierdzeń, które istnieją już w obu gałęziach przed scaleniem.) Pomaga to zignorować porcje różnic, które wyraźnie nie są czynnikiem w bieżącym konflikcie.

Wskazówka trzecia

Zweryfikuj zmiany za pomocą automatycznych narzędzi.

Jeśli masz zautomatyzowane testy, uruchom je. Jeśli masz szarpie, uruchom to. Jeśli jest to projekt możliwy do zbudowania, skompiluj go przed zatwierdzeniem itp. We wszystkich przypadkach musisz wykonać trochę testów, aby upewnić się, że zmiany niczego nie zepsują. (Heck, nawet połączenie bez konfliktów może złamać działający kod.)

Wskazówka czwarta

Planować naprzód; komunikować się ze współpracownikami.

Planowanie z wyprzedzeniem i bycie świadomym tego, nad czym pracują inni, może pomóc w zapobieganiu konfliktom związanym z łączeniem się i / lub pomocy w ich wcześniejszym rozwiązaniu - podczas gdy szczegóły są jeszcze świeże.

Na przykład, jeśli wiesz, że ty i inna osoba pracujesz nad różnymi refaktoryzacjami, które będą miały wpływ na ten sam zestaw plików, powinieneś porozmawiać ze sobą z wyprzedzeniem i lepiej zrozumieć, jakiego rodzaju zmiany każdy z was jest zrobienie. Możesz zaoszczędzić sporo czasu i wysiłku, jeśli będziesz przeprowadzać planowane zmiany, a nie równolegle.

W przypadku dużych refaktoryzacji, które przecinają duży obszar kodu, należy zdecydowanie rozważyć możliwość pracy seryjnej: wszyscy przestają pracować nad tym obszarem kodu, podczas gdy jedna osoba wykonuje pełny proces refaktoryzacji.

Jeśli nie możesz pracować w seriach (być może z powodu presji czasu), wówczas poinformowanie o spodziewanych konfliktach podczas scalania pomoże przynajmniej szybciej rozwiązać problemy, gdy szczegóły będą jeszcze świeże. Na przykład, jeśli współpracownik wykonuje przełomową serię zobowiązań w ciągu jednego tygodnia, możesz wybrać scalenie / wzmocnienie w oddziale tej współpracownicy raz lub dwa razy dziennie w ciągu tego tygodnia. W ten sposób, jeśli znajdziesz konflikty scalania / rebase, możesz rozwiązać je szybciej, niż jeśli poczekasz kilka tygodni, aby scalić wszystko razem w jedną dużą bryłę.

Wskazówka piąta

Jeśli nie masz pewności co do scalenia, nie zmuszaj go.

Scalanie może wydawać się przytłaczające, szczególnie gdy istnieje wiele konfliktowych plików, a znaczniki konfliktu obejmują setki linii. Często podczas szacowania projektów oprogramowania nie uwzględniamy wystarczającej ilości czasu na elementy nadrzędne, takie jak obsługa gnarly merge, więc wydaje się, że to prawdziwy przeciągnięcie, aby spędzić kilka godzin analizując każdy konflikt.

Na dłuższą metę planowanie z wyprzedzeniem i świadomość tego, nad czym pracują inni, to najlepsze narzędzia do przewidywania konfliktów łączących i przygotowania się do ich prawidłowego rozwiązania w krótszym czasie.


685
2017-09-28 21:08



Opcja diff3 to doskonała funkcja do łączenia. Jedyny GUI, na który natrafiłem, pokazuje, że to Perforce p4merge, które można zainstalować i używać oddzielnie od innych narzędzi Perforce (których nie używałem, ale słyszałem skargi). - alxndr
To najlepszy samouczek, który znalazłem w Internecie na temat "jak rozwiązać konflikty seryjne"! - Venkat Sudheer Reddy Aedama
Ta odpowiedź zasługuje na głosy; nie te dwa, które są zalane głosami; - DJphy
Po próbie rebase, która spowodowała konflikt scalania: $ git log --merge -p build.xml output: fatal: --merge without MERGE_HEAD? - Ed Randall
co jeśli mam zmiany na jednym pliku z gałęzi 1 i usunięcie tego pliku w gałęzi 2. Jak mogę rozwiązać ten konflikt scalania? Czy istnieje sposób używania git, gdzie mogę je scalić, zachowując zmiany jednej gałęzi? - Honey


  1. Określ, które pliki są w konflikcie (Git powinien ci to powiedzieć).

  2. Otwórz każdy plik i sprawdź różnice; Git je demaskuje. Mam nadzieję, że będzie oczywiste, którą wersję każdego bloku zachować. Być może będziesz musiał przedyskutować to z innymi deweloperami, którzy popełnili kod.

  3. Po rozwiązaniu konfliktu w pliku git add the_file.

  4. Po rozwiązaniu wszystko konflikty, zrób git rebase --continue czy jakakolwiek komenda Powiedział Git, kiedy skończyłeś.


321
2017-10-02 12:41



@ Justin Pomyśl o Git jako o śledzeniu zadowolony zamiast śledzenia plików. Wtedy łatwo zauważyć, że treści zostały zaktualizowane nie jest w repozytorium i trzeba go dodać. Ten sposób myślenia wyjaśnia również, dlaczego Git nie śledzi pustych folderów: mimo że są to pliki techniczne, nie ma żadnych treści do śledzenia. - Gareth
zawartość jest tam, konflikt występuje, ponieważ istnieje 2 wersja treści. Dlatego "git add" nie brzmi poprawnie. I nie działa (git add, git commit), jeśli chcesz zatwierdzić tylko jeden plik po rozwiązaniu konfliktu ("fatal: nie można zrobić częściowego zatwierdzenia podczas scalania.") - Dainius
Tak, technicznie, to odpowiada na pytanie, które jest zadawane, ale nie jest użyteczną odpowiedzią, moim zdaniem, przepraszam. Co to jest punkt tworzenia jednej gałęzi tak samo jak innej? Oczywiście połączenie będzie mieć konflikty .. - Thufir
Thulfir: kto powiedział coś o stworzeniu jednej gałęzi takiej samej jak druga? Istnieją różne scenariusze, w których musisz się połączyć, bez "tworzenia jednej gałęzi tak jak drugiej". Jednym z nich jest, gdy skończysz z gałęzi rozwoju i chcesz włączyć swoje zmiany do gałęzi głównej; po tym można usunąć gałąź rozwojową. Innym jest, gdy chcesz ponownie utworzyć gałąź rozwojową, aby ułatwić ostateczne scalenie w master. - Teemu Leisti
@ JustinGrant git add umieszcza pliki w indeksie; to robi nie dodaj cokolwiek do repozytorium. git commit dodaje rzeczy do repozytorium. To użycie ma sens w przypadku scalania - scalanie automatycznie wprowadza wszystkie zmiany, które mogą być automatycznie scalane; Twoim obowiązkiem jest scalenie pozostałych zmian i dodanie ich do indeksu po zakończeniu. - Mark E. Haase


Sprawdź odpowiedzi w pytaniu Stack Overflow Przerwanie scalenia w Git, szczególnie Odpowiedź Charlesa Baileya który pokazuje, jak wyświetlić różne wersje pliku z problemami, na przykład

# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp

97
2017-10-03 15:15



Sprawdź także opcję "-m", aby "git checkout -m" - pozwala wyodrębnić różne muchy z powrotem do obszaru roboczego - qneill
To mnie uratowało. Przeglądanie każdego pliku osobno pozwoliło mi zapamiętać, co robiłem w każdym oddziale. Wtedy mógłbym podjąć decyzję wyboru. - Rohmer


Konflikty scalania występują, gdy zmiany są wprowadzane do pliku w tym samym czasie. Oto jak go rozwiązać.

git CLI

Oto proste czynności, które należy wykonać po przejściu w stan konfliktu:

  1. Zwróć uwagę na listę konfliktów plików za pomocą: git status (pod Unmerged paths Sekcja).
  2. Rozwiąż konflikty oddzielnie dla każdego pliku, stosując jedno z następujących podejść:

    • Użyj GUI do rozwiązania konfliktów: git mergetool (najprostszy sposób).

    • Aby zaakceptować wersję zdalną / inną, użyj: git checkout --theirs path/file. Spowoduje to odrzucenie wszelkich zmian lokalnych dokonanych dla tego pliku.

    • Aby zaakceptować lokalną / naszą wersję, użyj: git checkout --ours path/file

      Trzeba jednak uważać, ponieważ zdalne zmiany, które powodują konflikty, zostały wykonane z jakiegoś powodu.

      Związane z: Jakie jest dokładne znaczenie "naszych" i "ich" w git?

    • Edytuj ręcznie skonfliktowane pliki i poszukaj między nimi bloku kodu <<<<</>>>>> następnie wybierz wersję z góry lub z dołu =====. Widzieć: W jaki sposób przedstawiono konflikty.

    • Konflikty ścieżek i nazw plików można rozwiązać przez git add/git rm.

  3. Na koniec przejrzyj pliki gotowe do zatwierdzenia przy użyciu: git status.

    Jeśli nadal masz jakieś pliki w Unmerged paths, a ty rozwiązałeś konflikt ręcznie, potem Git wiedział, że rozwiązałeś go przez: git add path/file.

  4. Jeśli wszystkie konflikty zostały pomyślnie rozwiązane, zatwierdz zmiany przez: git commit -a i jak zwykle naciskaj na zdalne sterowanie.

Zobacz też: Rozwiązywanie konfliktu seryjnego z wiersza poleceń na GitHub

DiffMerge

Z powodzeniem wykorzystałem DiffMerge który może wizualnie porównywać i łączyć pliki w systemach Windows, macOS i Linux / Unix.

Graficznie pokazuje zmiany między 3 plikami i umożliwia automatyczne scalanie (gdy jest to bezpieczne) oraz pełną kontrolę nad edytowaniem wynikowego pliku.

DiffMerge

Źródło obrazu: DiffMerge (Zrzut ekranu Linux)

Po prostu pobierz i uruchom w repo jako:

git mergetool -t diffmerge .

System operacyjny Mac

Na MacOS możesz zainstalować przez:

brew install caskroom/cask/brew-cask
brew cask install diffmerge

I prawdopodobnie (jeśli nie jest dostarczony) potrzebujesz następnej, prostej owijki umieszczonej w Twojej PATH (np. /usr/bin):

#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "$@"

Następnie możesz użyć następujących skrótów klawiaturowych:

  • -Alt-W górę/Na dół aby przejść do poprzednich / następnych zmian.
  • -Alt-Lewo/Dobrze zaakceptować zmianę z lewej lub prawej strony

Alternatywnie możesz użyć opendiff (część Xcode Tools), który pozwala scalić dwa pliki lub katalogi, tworząc trzeci plik lub katalog.


88
2017-08-05 14:29





Jeśli często robisz małe zatwierdzenia, zacznij od sprawdzenia komentarzy zatwierdzenia git log --merge. Następnie git diff pokaże ci konflikty.

W przypadku konfliktów obejmujących więcej niż kilka linii, łatwiej jest zobaczyć, co dzieje się w zewnętrznym narzędziu GUI. Lubię opendiff - Git obsługuje również vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, pojawiają się po wyjęciu z pudełka i możesz zainstalować inne: git config merge.tool "your.tool" ustawi wybrane narzędzie, a następnie git mergetool po nieudanym scaleniu pokażą ci różnice w kontekście.

Za każdym razem, gdy edytujesz plik, aby rozwiązać konflikt, git add filename zaktualizuje indeks, a twoja wersja nie będzie go już wyświetlać. Kiedy wszystkie konflikty są obsługiwane, a ich pliki zostały git add-ed, git commit uzupełni twoje połączenie.


73
2017-10-02 16:11



Używanie "git add" to tutaj prawdziwa sztuczka. Możesz nawet nie chcieć popełnić (być może chcesz ukryć), ale musisz zrobić "git add", aby dokończyć scalanie. Myślę, że mergetool robi dla ciebie dodatek (chociaż nie ma go w podręczniku), ale jeśli wykonasz scalenie ręcznie, musisz użyć "git add", aby go ukończyć (nawet jeśli nie chcesz tego zatwierdzać). - nobar


Widzieć Jak prezentowane są konflikty lub, w Git, git merge dokumentacja, aby zrozumieć, jakie są znaczniki konfliktów scalających.

Ponadto Jak rozwiązywać konflikty sekcja wyjaśnia, jak rozwiązać konflikty:

Po zobaczeniu konfliktu możesz zrobić dwie rzeczy:

  • Zdecyduj się nie łączyć. Jedyne, czego potrzebujesz, to zresetować plik indeksu do pliku HEAD zobowiązać się do odwrócenia 2. i oczyszczenia zmian w drzewach roboczych dokonanych przez 2. i 3 .; git merge --abort można do tego użyć.

  • Rozwiąż konflikty. Git zaznaczy konflikty w drzewie roboczym. Edytuj pliki w kształcie i git add je do indeksu. Posługiwać się git commit aby zamknąć umowę.

Możesz przezwyciężyć konflikt za pomocą wielu narzędzi:

  • Użyj mergetool. git mergetool aby uruchomić graficzny mergetool, który przeprowadzi cię przez scalanie.

  • Spójrz na różnice. git diff wyświetli trójdrożną różnicę, podkreślając zmiany z obu HEAD i MERGE_HEAD wersje.

  • Spójrz na różnice z każdej gałęzi. git log --merge -p <path> pokaże najpierw diffs dla HEAD wersja, a następnie MERGE_HEAD wersja.

  • Spójrz na oryginały. git show :1:filename pokazuje wspólnego przodka, git show :2:filename pokazuje HEAD wersja, i git show :3:filename pokazuje MERGE_HEAD wersja.

Możesz także przeczytać o markerach konfliktu korespondencji seryjnej i sposobie ich rozwiązywania w Pro Git Sekcja Książki Podstawowe konflikty scalania.


43
2017-07-14 18:34





Dla Emacs użytkownicy, którzy chcą częściowo rozwiązać konflikty scalania:

git diff --name-status --diff-filter=U

pokazuje wszystkie pliki, które wymagają rozwiązania konfliktu.

Otwórz każdy z tych plików jeden po drugim lub wszystkie naraz:

emacs $(git diff --name-only --diff-filter=U)

Podczas odwiedzania bufora wymagającego edycji w Emacs, wpisz

ALT+x vc-resolve-conflicts

Otworzy to trzy bufory (moje, ich i bufor wyjściowy). Nawiguj, naciskając "n" (następny region), "p" (region prevision). Naciśnij "a" i "b", aby skopiować kopalnie lub ich region do bufora wyjściowego. I / lub bezpośrednio edytować bufor wyjściowy.

Po zakończeniu: naciśnij "q". Emacs zapyta, czy chcesz zapisać ten bufor: tak. Po zakończeniu bufora zaznacz go jako rozwiązany, uruchamiając z trybu:

git add FILENAME

Po zakończeniu ze wszystkimi typami buforów

git commit

zakończyć scalanie.


36
2018-02-22 23:04





Wykonaj następujące kroki, aby naprawić konflikty scalania w Git:

  1. Sprawdź status Git: status gita

  2. Uzyskaj zestaw poprawek: git fetch (sprawdź poprawną poprawkę z twojego zatwierdzenia Git)

  3. Zamówienie lokalnego oddziału (temp1 w moim przykładzie tutaj): git checkout -b temp1

  4. Wyciągnij ostatnią zawartość z mastera: git pull - master pochodzenia koni

  5. Uruchom polecenie mergetool i sprawdź konflikty i napraw je ... i sprawdź zmiany w oddziale zdalnym w bieżącym oddziale: git mergetool

  6. Sprawdź status ponownie:   status gita

  7. Usuń niechciane pliki utworzone lokalnie przez mergetool, zwykle mergetool tworzy dodatkowy plik z rozszerzeniem * .orig. Usuń ten plik, ponieważ jest to tylko duplikat i napraw lokalnie zmiany i dodaj poprawną wersję plików. git dodaj #your_changed_correct_files

  8. Sprawdź status ponownie: status gita

  9. Zatwierdź zmiany do tego samego identyfikatora commit (unikasz nowego oddzielnego zestawu poprawek): git commit --amend

  10. Prześlij do gałęzi głównej: git push (do repozytorium Git)


28
2018-04-16 07:02





Po prostu, jeśli wiesz, że zmiany w jednym z repozytoriów nie są ważne i chcesz rozwiązać wszystkie zmiany na rzecz drugiego, użyj:

git checkout . --ours

rozwiązać zmiany na korzyść twoje repozytorium, lub

git checkout . --theirs

rozwiązywać zmiany na korzyść inne lub główne repozytorium.

Albo będziesz musiał użyć narzędzia do scalania GUI, aby przeglądać pliki jeden po drugim, powiedzmy, że narzędzie do scalania jest p4mergelub napisz imię, które już masz zainstalowane

git mergetool -t p4merge

i po skończeniu pliku będziesz musiał zapisać i zamknąć, aby następny otworzył się.


27
2018-01-26 17:42



git checkout. --ich  rozwiązał mój problem dzięki - Ramesh Chand
jeśli wolisz rozwiązywać konflikty ręcznie, spróbuj otworzyć folder w Kodzie Visual Studio, oznacza to, że pliki zawierają konflikty, a kolory powodują konflikt linii wewnątrz każdego z nich - Mohamed Selim