34 Pytanie: Jak rozwiązać konflikty scalające w Git

pytanie utworzone w Wed, May 15, 2019 12:00 AM

Jak rozwiązać konflikty scalające w Git?

    
4443
  1. Poniższy wpis na blogu wydaje się być bardzo dobrym przykładem na to, jak radzić sobie z konfliktem scalania z Gitem, który powinien sprawić, że pójdziesz we właściwym kierunku. Obsługa i unikanie konfliktów w Git
    2008-10-02 11: 40: 03Z
  2. Możesz skonfigurować narzędzie do scalania (kdiff3 jebaird.com/2013/07/08/… ), a następnie użyj git mergetool. Gdy pracujesz w dużych zespołach programistów, zawsze napotykasz konflikty scalające.
    2015-04-18 05: 37: 12Z
  3. Nie zapominaj, że możesz łagodzić większość konfliktów łączenia poprzez regularne łączenie w dół!
    2015-07-27 09: 50: 33Z
  4. 2015-10-20 11: 19: 55Z
  5. Fascynujące pytanie: Zapytany w 2008 roku, 100% otwarty zakończył się bez żadnej wskazówki na temat tego, o co tak naprawdę chodzi (czy chodzi o GUI? o polecenia git? o semantykę? na temat pchania /ciągnięcia lub po prostu ogólnych konfliktów?) - całkowicie bez odpowiedzi. 30 odpowiedzi, z których wszystkie (o ile szybki podgląd) pokazuje mniej więcej o różnych narzędziach diff3 i scalających, żaden nie został zaakceptowany. Odpowiedź najlepiej głosowana wspomina o poleceniu, które nawet nie działa z domyślną instalacją git. Udało mi się trafić na stronę startową SE dla mnie dzisiaj, 2017, z 1,3 mln wyświetleń i tysiącami głosów w obie strony. Fascynujące.
    2017-07-11 16: 48: 34Z
30 odpowiedzi                              30                         

Spróbuj: git mergetool

Otwiera interfejs GUI, który przeprowadzi Cię przez każdy konflikt i wybierzesz sposób scalenia. Czasami wymaga to trochę ręcznej edycji, ale zazwyczaj wystarcza sama. Jest to o wiele lepsze niż na pewno wykonanie całej rzeczy ręcznie.

Jak w komentarzu @JoshGlover:

Polecenie niekoniecznie otwiera GUI, chyba że go zainstalujesz. Uruchamianie git mergetool dla mnie spowodowało użycie vimdiff. Zamiast tego możesz zainstalować jedno z następujących narzędzi: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Poniżej znajduje się przykładowa procedura użycia vimdiff do rozwiązywania konfliktów scalania. Na podstawie tego linku

Krok 1 : uruchom następujące polecenia w swoim 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 - to plik z bieżącej gałęzi

     

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

     

REMOTE - plik, który włączasz do swojej gałęzi

     

MERGED - wynik scalania, to jest to, co zostaje zapisane w repo

Możesz przeglądać te widoki za pomocą ctrl + w . Możesz bezpośrednio dotrzeć do widoku MERGED za pomocą ctrl + w , a następnie 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ź, zatwierdź i posprzątaj

:wqa zapisz i wyjdź z vi

git commit -m "message"

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

    
2662
2019-06-23 15: 50: 52Z
  1. FYI możesz użyć git mergetool -y, aby zapisać kilka naciśnięć klawiszy, jeśli łączysz wiele plików naraz.
    2010-06-17 23: 32: 50Z
  2. Cóż, niekoniecznie otwiera GUI, chyba że go zainstalujesz. Uruchamianie git mergetool dla mnie spowodowało użycie vimdiff. Zamiast tego możesz zainstalować jedno z następujących narzędzi: meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse ecmerge p4merge araxis vimdiff emerge.
    2011-05-11 14: 00: 49Z
  3. Dobry punkt Josh. Na ubuntu miałem najlepsze szczęście z połączeniem, jego trójdrożny ekran scalania nie jest zły. Na OSX git wybrał ładne domyślne.
    2011-05-24 05: 08: 08Z
  4. To otworzyło KDiff3. Którego absolutnie nie mam pojęcia, jak używać.
    2011-06-10 18: 46: 25Z
  5. Możesz także użyć Beyond Compare 3 (git mergetool -t bc3).
    2012-08-30 14: 59: 24Z

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

Zamierzasz pobrać kilka zmian, 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.

Więc jesteś na bieżąco i spróbuj 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 zdecydujesz się spojrzeć na zmiany:

 
git mergetool

Oh my, oh my, upstream zmienił pewne rzeczy, ale po prostu użył moich zmian ... no ... ich zmian ...

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

A potem spró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!

    
1643
2019-06-10 08: 10: 35Z
  1. To było bardzo pomocne, ponieważ miałem wiele błędów scalania z plikami binarnymi (zasobami sztuki) i scalanie ich zawsze wydaje się nie udać, więc muszę go zastąpić nowy plik zawsze i nie „scal”
    2011-06-08 17: 39: 40Z
  2. Uważaj! Znaczenie --ours i - theirs jest odwrócone. --ours == pilot. --theirs == local. Zobacz git merge --help
    2013-03-04 22: 56: 21Z
  3. W moim przypadku potwierdzam, że --theirs = zdalne repozytorium, --ours = moje własne lokalne repozytorium. Jest przeciwieństwem komentarzy @mmell.
    2013-06-22 12: 59: 08Z
  4. @ mmell Tylko na podstawie, najwyraźniej. Zobacz this question
    2013-11-10 06: 19: 14Z
  5. Faceci, „nasz” i „ich” odnoszą się do tego, czy łączysz się, czy rebasingujesz. Jeśli łączenie , a następnie „nasza” oznacza gałąź, z którą się łączymy, a „ich” to gałąź, w której się łączymy. Kiedy rebasing , wtedy „nasza” oznacza zobowiązania, na które się opierasz, podczas gdy „ich” odnosi się do zatwierdzeń, które chcesz ponownie podstawić.
    2014-05-26 04: 27: 22Z

Znalazłem połączenierzadko pomagają mi zrozumieć konflikt lub rozdzielczość. Zazwyczaj odnoszę większe sukcesy, patrząc na znaczniki konfliktów w edytorze tekstu i korzystając z dziennika git jako uzupełnienia.

Oto kilka wskazówek:

Wskazówka pierwsza

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

git config merge.conflictstyle diff3

Powoduje to powstanie znaczników konfliktu w następujący sposób:

 
<<<<<<<
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 część jest taka, jak wyglądał wspólny przodek. Jest to przydatne, ponieważ można porównać je z wersją górną i dolną, aby lepiej zrozumieć, co zostało zmienione w każdej gałęzi, co daje lepszy pomysł na to, jaki był cel każdej zmiany.

Jeśli konflikt jest tylko kilka linijek, powoduje to, że konflikt jest bardzo oczywisty. (Wiedza o tym, jak naprawić konflikt jest bardzo różna; musisz być świadomy tego, nad czym pracują inni. Jeśli jesteś zdezorientowany, prawdopodobnie najlepiej zadzwonić do tej osoby do swojego pokoju, aby mogli zobaczyć, co szukasz at.)

Jeśli konflikt trwa dłużej, wycinam i wklejam każdą z trzech sekcji w trzy osobne pliki, takie jak „mój”, „wspólny” i „ich”.

Następnie mogę uruchomić następujące polecenia, aby zobaczyć dwa porcje różnic, które spowodowały konflikt:

 
diff common mine
diff common theirs

To nie jest to samo, co użycie narzędzia do scalania, ponieważ narzędzie scalające będzie zawierać także wszystkie niezgodne porcje różnic. Uważam, że to rozprasza.

Wskazówka druga

Ktoś już o tym wspomniał, ale zrozumienie intencji za każdym kawałkiem diff jest ogólnie bardzo pomocne w zrozumieniu, skąd się wziął konflikt i jak sobie z tym poradzić.

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

Pokazuje wszystkie zatwierdzenia, które dotknęły tego pliku pomiędzy wspólnym przodkiem i dwiema głowami, które scalasz. (Więc nie zawiera zatwierdzeń, które już istnieją w obu gałęziach przed połączeniem.) Pomaga to ignorować 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 testy automatyczne, uruchom je. Jeśli masz lint , uruchom to. Jeśli jest to projekt do zbudowania, zbuduj go przed zatwierdzeniem itd. We wszystkich przypadkach musisz zrobić trochę testów, aby upewnić się, że zmiany niczego nie złamały. (Heck, nawet połączenie bez konfliktów może złamać działający kod.)

Wskazówka czwarta

Planuj z wyprzedzeniem; komunikować się ze współpracownikami.

Planowanie z wyprzedzeniem i bycie świadomym tego, nad czym pracują inni, może pomóc w zapobieganiu konfliktom scalania i /lub pomóc rozwiązać je wcześniej - podczas gdy szczegóły są wciąż świeże.

Na przykład, jeśli wiesz, że zarówno ty, jak i inna osoba pracujesz nad różnymi metodami refaktoryzacji, które wpływają na ten sam zestaw plików, powinieneś rozmawiać ze sobą z wyprzedzeniem i lepiej zrozumieć, jakie typy zmian każdy z ciebie robi. Możesz zaoszczędzić sporo czasu i wysiłku, jeśli przeprowadzisz zaplanowane zmiany seryjnie, a nie równolegle.

W przypadku poważnych refaktoryzacji, które przecinają duży obszar kodu, powinieneś zdecydowanie rozważyć podjęcie pracy seryjnej: każdy przestaje pracować na tym obszarze kodu, podczas gdy jedna osoba wykonuje pełną refaktoryzację.

Jeśli nie możesz pracować seryjnie (może z powodu presji czasu), to komunikowanie się co do spodziewanych konfliktów scalania przynajmniej pomaga rozwiązać problemy wcześniej, podczas gdy szczegóły są wciąż świeże. Na przykład, jeśli współpracownik dokonuje serii zakłóceń w ciągu jednego tygodnia, możesz zdecydować się na połączenie /odnowienie na tych oddziałach pracowników 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ż gdybyś czekał kilka tygodni, aby połączyć wszystko razem w jedną dużą bryłę.

Wskazówka piąta

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

Scalanie może być przytłaczające, zwłaszcza gdy istnieje wiele sprzecznych plików, a znaczniki konfliktów pokrywają setki linii. Często podczas szacowania projektów programowych nie uwzględniamy wystarczającej ilości czasu na elementy narzutowe, takie jak obsługa gnarly merge, więc wydaje się prawdziwym przeciągnięciem spędzać kilka godzin na analizowaniu każdego konfliktu.

Na dłuższą metę planowanie z wyprzedzeniem i świadomość tego, nad czym pracują inni, są najlepszymi narzędziami do przewidywania konfliktów łączenia i przygotowania się do ich poprawnego rozwiązania w krótszym czasie.

    
710
2014-07-23 17: 32: 54Z
  1. Opcja diff3 to świetna funkcja do łączenia. Jedyny GUI, z którym się zetknąłem, pokazuje, że jest to Perforce p4merge, który można zainstalować i używać oddzielnie od innych narzędzi Perforce (wktórego nie użyłem, ale słyszałem skargi).
    2014-05-01 22: 15: 41Z
  2. Po próbie bazowania, która doprowadziła do konfliktu scalania: $git log --merge -p wyjście build.xml: fatal: --merge bez MERGE_HEAD?
    2016-06-17 09: 15: 07Z
  3. co jeśli mam zmiany w jednym pliku z branch1 i usunięcie tego pliku w branch2. Jak mogę rozwiązać ten konflikt scalania? Czy jest jakiś sposób użycia git, w którym mogę je scalić, zachowując zmiany jednej gałęzi?
    2017-01-21 14: 48: 16Z
  4. git config merge.conflictstyle diff3 - dziękuję, sir. To jest niesamowite i uwolniło mnie od prób znalezienia (i zapłacenia $$) dobrego 3-stronnego interfejsu GUI. IMO jest to lepsze, ponieważ pokazuje wspólnego przodka, jak również lokalnego /zdalnego, i pokazuje linie dziennika ostatniego zatwierdzenia, których (AFAIK) nie ma w interfejsie GUI. Zatwierdzenia zdecydowanie pomagają zidentyfikować kod, który należy do jakiej gałęzi.
    2017-04-04 16: 00: 53Z
  5. Odkryłem, że czasami diff3 conflictstyle powoduje powstanie ogromnych porcji różnic, które są w dużej mierze identyczne, podczas gdy domyślne będą dawały mniejsze, łatwiejsze do zarządzania porcje. Niestety, nie mam odtwarzacza, którego mogę użyć do zgłoszenia błędu. Ale jeśli napotkasz ten problem, możesz tymczasowo wyłączyć tę opcję.
    2017-07-02 03: 31: 12Z
  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 rozgranicza ich. Mam nadzieję, że będzie oczywiste, która wersja każdego bloku ma zostać zachowana. Być może będziesz musiał przedyskutować to z innymi programistami, którzy wprowadzili kod.

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

  4. Po rozwiązaniu wszystkich konfliktów wykonaj git rebase --continue lub dowolne polecenie Git powiedział, że zrobisz to po zakończeniu.

333
2014-08-07 17: 48: 46Z
  1. @ Justin Pomyśl o Gicie jako o śledzeniu treści zamiast śledzenia plików. Wtedy łatwo zauważyć, że zaktualizowana zawartość nie jest w repozytorium i musi zostać dodana. Ten sposób myślenia wyjaśnia również, dlaczego Git nie śledzi pustych folderów: chociaż są technicznie plikami, nie ma żadnych treści do śledzenia.
    2010-10-12 09: 17: 27Z
  2. zawartość jest, konflikt występuje, ponieważ istnieją 2 wersje treści. Dlatego „git add” nie brzmi poprawnie. I nie działa (git add, git commit), jeśli chcesz zatwierdzić tylko to, że jeden plik po konflikcie został rozwiązany („fatal: nie można wykonać częściowego zatwierdzenia podczas scalania.”)
    2011-09-14 09: 19: 10Z
  3. Tak, technicznie, to odpowiada na pytanie, które zostało zadane, ale nie jest, moim zdaniem, użyteczną odpowiedzią, przepraszam. Jaki jest punkt uczynienia jednej gałęzi taką samą jak inna? Oczywiście połączenie będzie miało konflikty.
    2012-08-09 05: 56: 27Z
  4. Thulfir: kto powiedział cokolwiek o uczynieniu jednej gałęzi taką samą jak inna? Istnieją różne scenariusze, w których należy połączyć, bez „uczynienia jednej gałęzi taką samą jak inna”. Jednym z nich jest ukończenie gałęzi rozwoju i włączenie jej zmian do gałęzi głównej; po tym można usunąć gałąź rozwojową. Innym jest sytuacja, w której chcesz przebudować gałąź rozwojową, aby ułatwić ostateczne scalenie w master.
    2012-09-21 08: 50: 19Z
  5. @ JustinGrant git add etapuje pliki w indeksie; nie dodaje niczego do repozytorium. git commitdodaje rzeczy do repozytorium. Takie użycie ma sens w przypadku scalania - scalanie automatycznie wykonuje wszystkie zmiany, które można automatycznie scalić; Twoim obowiązkiem jest scalenie pozostałych zmian i dodanie ich do indeksu po zakończeniu.
    2012-10-17 15: 13: 05Z

Sprawdź odpowiedzi w pytaniu Przepełnienie stosu Przerwanie scalania w Git , szczególnie Odpowiedź Charlesa Baileya , która 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
    
102
2017-05-23 11: 47: 34Z
  1. Sprawdź także opcję "-m" w "git checkout -m" - pozwala ona wyodrębnić różne muchy z powrotem do obszaru roboczego
    2015-02-05 22: 06: 41Z
  2. To mnie uratowało. Patrzenie na każdy plik osobno pozwoliło mi zapamiętać, co zamierzam w każdej gałęzi. Wtedy mógłbym podjąć decyzję o wyborze.
    2016-05-14 21: 59: 15Z

Konflikty scalania mają miejsce, gdy zmiany są dokonywane w pliku w tym samym czasie. Oto jak go rozwiązać.

 git CLI

Oto proste kroki, które należy wykonać, gdy dojdziesz do stanu konfliktu:

  1. Zwróć uwagę na listę konfliktowych plików z: git status (poniżej Unmerged paths sekcji).
  2. Rozwiąż konflikty osobno dla każdego pliku za pomocą jednego z następujących podejść:

    • Użyj GUI, aby rozwiązać konflikty: git mergetool (najprostszy sposób).

    • Aby zaakceptować wersję zdalną /inną, użyj: git checkout --theirs path/file. Spowoduje to odrzucenie wszelkich zmian lokalnych, które zrobiłeś dla tego pliku.

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

      Jednak musisz być ostrożny, ponieważ zdalne zmiany, które spowodowały konflikty z jakiegoś powodu.

      Powiązane: Jakie jest dokładne znaczenie słów „nasze” i „ich” w git?

    • Ręcznie edytuj konflikty plików i poszukaj bloku kodu między <<<<</>>>>>, a następnie wybierz wersję z poziomu powyżej lub poniżej =====. Zobacz: Jak prezentowane są konflikty .

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

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

    Jeśli nadal masz jakieś pliki w Unmerged paths i rozwiązałeś konflikt ręcznie, pozwól Gitowi wiedzieć, że rozwiązałeś go: git add path/file.

  4. Jeśli wszystkie konflikty zostały rozwiązane pomyślnie, wprowadź zmiany: git commit -a i naciśnij jak zwykle.

Zobacz też: Rozwiązywanie konfliktu łączenia z linii poleceń w GitHub

DiffMerge

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

Graficznie może pokazać zmiany między 3 plikami i umożliwia automatyczne scalanie (gdy jest to bezpieczne) i pełną kontrolę nad edycją pliku wynikowego.

 DiffMerge

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

Po prostu pobierz i uruchom w repo jako:

 
git mergetool -t diffmerge .

macOS

Na MacOS możesz zainstalować poprzez:

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

I prawdopodobnie (jeśli nie jest podany) potrzebujesz następującego prostego opakowania umieszczonego w 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 - Up / Down , aby przejść do poprzednich /następnych zmian.
  • - Alt - Left / Prawo , aby zaakceptować zmianę z lewej lub prawej strony

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

    
90
2017-05-23 10: 31: 39Z

Jeśli robisz częste małe zatwierdzenia, zacznij od obejrzenia komentarzy zatwierdzenia za pomocą git log --merge. Następnie git diff pokaże ci konflikty.

W przypadku konfliktów, które dotyczą więcej niż kilku linii, łatwiej jest zobaczyć, co dzieje się w zewnętrznym narzędziu GUI. Lubię opendiff - Git obsługuje także vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, pojawia 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że różnice w kontekst.

Za każdym razem, gdy edytujesz plik w celu rozwiązania konfliktu, git add filename zaktualizuje indeks, a Twój diff już go nie pokaże. Gdy wszystkie konflikty zostaną obsłużone, a ich pliki zostaną git add -ed, git commit dokończy scalanie.

    
76
2014-07-23 17: 43: 21Z
  1. Używanie "git add" to prawdziwa sztuczka. Możesz nawet nie chcieć zatwierdzać (może chcesz je przechowywać), ale musisz wykonać „git add”, aby ukończyć scalanie. Myślę, że mergetool wykonuje dodawanie dla ciebie (chociaż nie ma go na stronie podręcznika), ale jeśli wykonasz połączenie ręcznie, musisz użyć "git add", aby je ukończyć (nawet jeśli nie chcesz zatwierdzać).
    2010-10-25 09: 37: 00Z

Zobacz Jak prezentowane są konflikty lub, w Git , dokumentacja git merge, aby zrozumieć, czym są znaczniki konfliktów scalania.

Ponadto sekcja Jak rozwiązywać konflikty jak rozwiązać konflikty:

  

Po obejrzeniu konfliktu możesz zrobić dwie rzeczy:

     
  • Zdecyduj się nie łączyć. Jedyne, co musisz zrobić, to zresetować plik indeksu do HEAD zatwierdzić odwrócenie 2. i wyczyścić zmiany drzewa roboczego dokonane przez 2. i 3. .; W tym celu można użyć git merge --abort.

  •   
  • Rozwiąż konflikty. Git zaznaczy konflikty w drzewie roboczym. Edytuj pliki do kształtu i git add je do indeksu. Użyj git commit, aby zapieczętować transakcję.

  •   

Możesz pracować z konfliktem za pomocą wielu narzędzi:

     
  • Użyj łączenia. git mergetool, aby uruchomić graficzny moduł łączenia, który będzie działał przez scalanie.

  •   
  • Spójrz na różnice. git diff wyświetli trójdrożny diff, podkreślając zmiany zarówno w wersjach HEAD, jak i MERGE_HEAD.

  •   
  • Spójrz na różnice z każdej gałęzi. git log --merge -p <path> pokaże najpierw różnice dla wersji HEAD, a następnie dla 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.

  •   

Możesz także przeczytać o znacznikach konfliktów łączenia i jak je rozwiązać w sekcji książki Pro Git Podstawowe konflikty korespondencji seryjnej .

    
44
2014-07-23 17: 22: 15Z

Dla Emacs użytkowników, którzy chcą rozwiązać konflikty pół-ręcznie:

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

pokazuje wszystkie pliki wymagające 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 wizyty w buforze wymagającym edycji w Emacs, wpisz

 
ALT+x vc-resolve-conflicts

Spowoduje to otwarcie trzech buforów (mój, ich,i bufor wyjściowy). Nawiguj, naciskając „n” (następny region), „p” (region podglądu). Naciśnij „a” i „b”, aby skopiować kopie lub region do bufora wyjściowego. I /lub edytuj bufor wyjściowy bezpośrednio.

Po zakończeniu: naciśnij „q”. Emacs pyta, czy chcesz zapisać ten bufor: tak. Po zakończeniu bufora zaznacz go jako rozwiązany, uruchamiając go z poziomu przestępcy:

 
git add FILENAME

Kiedy skończysz ze wszystkimi buforami, wpisz

 
git commit

, aby zakończyć scalanie.

    
38
2014-07-23 17: 24: 52Z

Chcę, aby moja lub ich wersja była pełna, lub chcę przejrzeć poszczególne zmiany i zdecydować się na każdą z nich.

W pełni zaakceptuj moją lub ich wersję :

Zaakceptuj moją wersję (lokalną, naszą):

 
git checkout --ours -- <filename>
git add <filename>              # Marks conflict as resolved
git commit -m "merged bla bla"  # An "empty" commit

Zaakceptuj ich wersję (zdalne, ich):

 
git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"

Jeśli chcesz zrobić dla wszystkich plików konfliktów , uruchom:

 
git merge --strategy-option ours

lub

 
git merge --strategy-option theirs

Przejrzyj wszystkie zmiany i zaakceptuj je indywidualnie

  1. git mergetool
  2. Sprawdź zmiany i zaakceptuj każdą z nich dla każdej z nich.
  3. git add <filename>
  4. git commit -m "merged bla bla"

Domyślny mergetool działa w wierszu poleceń . Jak używać mergetool linii poleceń powinno być osobnym pytaniem.

Możesz również zainstalować narzędzie wizualne , np. meld i uruchom

 
git mergetool -t meld

Otworzy wersję lokalną (naszą), wersję „podstawową” lub „scaloną” (bieżący wynik scalania) i wersję zdalną (ich). Zapisz scaloną wersję, gdy skończysz, uruchom ponownie git mergetool -t meld, aż pojawi się „Żadne pliki nie wymagają scalenia”, a następnie przejdź do kroków 3. i 4.

    
35
2018-06-19 03: 29: 48Z
  1. To polecenie: git checkout --theirs - < filename > zmienił WSZYSTKIE pliki na swoje, nie tylko < filename >
    2018-06-26 01: 00: 29Z
  2. Właściwie to się myliłem. To tylko aktualizuje określony plik.
    2018-06-26 01: 23: 15Z

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

  1. Sprawdź status Git: status gita

  2. Uzyskaj patchset: git fetch (wyewidencjonuj poprawny patch z zatwierdzenia Git)

  3. Do kasy lokalnego oddziału (temp1 w moim przykładzie tutaj): git checkout -b temp1

  4. Wyciągnij ostatnią zawartość z urządzenia głównego: git pull --rebase master

  5. Rozpocznij scaletool i sprawdź konflikty i napraw je ... i sprawdź zmiany w oddziale zdalnym za pomocą bieżącego oddziału: git mergetool

  6. Sprawdź ponownie status:   status gita

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

  8. Sprawdź ponownie status: status gita

  9. Zatwierdź zmiany w tym samym identyfikatorze zatwierdzenia (pozwala to uniknąć nowego oddzielnego zestawu poprawek): git commit --amend

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

28
2018-06-19 03: 25: 07Z

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

 
git checkout . --ours

, aby rozwiązać zmiany na korzyść Twojego repozytorium lub

 
git checkout . --theirs

, aby rozwiązać zmiany na korzyść innego lub głównego repozytorium .

Albo będziesz musiał użyć narzędzia scalania GUI, aby przechodzić kolejno po plikach, powiedzmy, że narzędziem scalania jest p4merge, lub napisz dowolną nazwę, którą już zainstalowałeś

 
git mergetool -t p4merge

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

    
28
2018-06-19 03: 26: 09Z
  1. git checkout. --theirs rozwiązało mój problem dzięki
    2016-03-10 06: 53: 00Z
  2. jeśli wolisz rozwiązywać konflikty ręcznie, spróbuj otworzyć folder w Visual Studio Code, zaznacza pliki konfliktami i kolorami linie konfliktu wewnątrz każdego
    2016-07-03 08: 31: 42Z

Bonus:

Mówiąc o pull /fetch /merge w powyższych odpowiedziach, chciałbym podzielić się ciekawą i produktywną sztuczką,

git pull --rebase

Powyższe polecenie jest najbardziej użytecznym poleceniem w moim życiu, które zaoszczędziło mnóstwo czasu.

Przed wprowadzeniem nowo zatwierdzonej zmiany na serwer zdalny spróbuj git pull --rebase raczej git pull i instrukcji merge, aby automatycznie zsynchronizować najnowsze zmiany zdalnego serwera (z fetch + merge) i umieści lokalny najnowszy commit na górze w dzienniku git. Nie musisz martwić się o ręczne ściąganie /scalanie.

W przypadku konfliktu wystarczy użyć

 
git mergetool
git add conflict_file
git rebase --continue

Znajdź szczegóły na: http://gitolite.com/git-pull--rebase

    
27
2015-12-31 03: 30: 19Z

Konflikty scalania można naprawić na wiele sposobów, tak jak inne zostały szczegółowo opisane.

Myślę, że prawdziwym kluczem jest wiedza, jak zmieniają się zmiany w lokalnych i zdalnych repozytoriach. Kluczem do tego jest zrozumienie gałęzi śledzenia. Odkryłem, że myślę o gałęzi śledzenia jako o „brakującym elemencie pośrodku” między mną a moim lokalnym, rzeczywistym katalogiem plików i pilotem zdefiniowanym jako źródło.

Osobiście nabrałem zwyczaju dwóch rzeczy, aby tego uniknąć.

Zamiast:

 
git add .
git commit -m"some msg"

Który ma dwie wady -

a) Wszystkie nowe /zmienione pliki zostaną dodane i mogą zawierać niepożądane zmiany.
b) Nie możesz najpierw przejrzeć listy plików.

Zamiast tego robię:

 
git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.

W ten sposób jesteś bardziej świadomy tego, które pliki zostaną dodane, a także przejrzysz listę i zastanowisz się trochę podczas korzystania z edytora wiadomości. Uważam, że poprawia to również moje komunikaty zatwierdzające, gdy używam edytora pełnoekranowego, a nie opcji -m.

[Aktualizacja - w miarę upływu czasu zmieniłem więcej na:

 
git status # Make sure I know whats going on
git add .
git commit # Then use the editor

]

Również (i bardziej odpowiedni dla twojej sytuacji) staram się unikać:

 
git pull

lub

 
git pull origin master.

ponieważ ciąg pociąga za sobą scalenie, a jeśli masz lokalne zmiany, których nie chcesz scalić, możesz łatwo połączyć się w kod i /lub połączyć konflikty dla kodu, który nie powinien zostać scalony.

Zamiast tego próbuję zrobić

 
git checkout master
git fetch   
git rebase --hard origin/master # or whatever branch I want.

Możesz również znaleźć to pomocne:

git gałąź, rozwidlenie, pobieranie, scalanie, ponowne bazowanie i klonowanie, jakie są różnice?

    
25
2017-05-23 12: 18: 27Z
  1. Hej, zrozumiałem twoją odpowiedź. Ale ponieważ jestem nowy w gitubowaniu konfliktów scalających, myślę, że czegoś brakuje. Co stanie się z lokalnymi modyfikacjami, gdy wykonasz git checkout master i git fetch i git rebase --hard origin/master
    2017-08-08 17: 43: 36Z
  2. Uważam, że powinieneś dodać więcej szczegółów na temat tego, co robić. Inny przykład, który wprowadza mnie w błąd, wspomniałeś w swojej odpowiedzi: robimy git add ., czy zapisze to nasze lokalne modyfikacje, abyśmy mogli śledzić git checkout master? czy są dwa różne scenarios?
    2017-08-08 17: 47: 14Z

Istnieją 3 kroki:

  1. Znajdź, które pliki powodują konflikty za pomocą polecenia

     
    git status
    
  2. Sprawdź pliki, w których znajdziesz konflikty oznaczone jako

     
    <<<<<<<<head
    blablabla
    
  3. Zmień go na taki, jaki chcesz, a następnie zatwierdź za pomocą poleceń

     
    git add solved_conflicts_files
    git commit -m 'merge msg'
    
25
2018-07-05 21: 03: 45Z
  1. Pracowałem dla mnie! Dzięki!
    2017-09-18 04: 00: 54Z
  2. Musisz zwrócić uwagę, jeśli zrobisz to podczas rebase. Powinieneś użyć git rebase --continue zamiast git commit
    2018-10-29 13: 37: 48Z

Odpowiedź CoolAJ86 podsumowuje prawie wszystko. Jeśli masz zmiany w obu gałęziach w tym samym kawałku kodu, musisz dokonać ręcznego scalenia. Otwórz plik w konflikcie w dowolnym edytorze tekstu i powinieneś zobaczyć następującą strukturę.

 
(Code not in Conflict)
>>>>>>>>>>>
(first alternative for conflict starts here)
Multiple code lines here
===========
(second alternative for conflict starts here)
Multiple code lines here too    
<<<<<<<<<<<
(Code not in conflict here)

Wybierz jedną z alternatyw lub kombinację obu w sposób, w jaki chcesz, aby nowy kod był, usuwając znaki równości i nawiasy kątowe.

 
git commit -a -m "commit message"
git push origin master
    
22
2014-07-23 17: 17: 38Z
 
git log --merge -p [[--] path]

Wydaje się, że nie zawsze działa dla mnie i zazwyczaj kończy się wyświetlaniem każdego zatwierdzenia, które było różne między dwiema gałęziami, dzieje się tak nawet przy użyciu -- do oddzielenia ścieżki od polecenia.

To, co robię, aby obejść ten problem, to otwarcie dwóch linii poleceń i jednorazowe uruchomienie

 
git log ..$MERGED_IN_BRANCH --pretty=full -p [path]

i na drugim

 
git log $MERGED_IN_BRANCH.. --pretty=full -p [path]

Zastąpienie $MERGED_IN_BRANCH gałęzią, którą scaliłem i [path] z konfliktem. Polecenie to zaloguje wszystkie zatwierdzenia, w formie poprawki, pomiędzy (..) dwoma zatwierdzeniami. Jeśli pozostawisz jedną stronę pustą, tak jak w poleceniach powyżej, git automatycznie użyje HEAD (gałęzi, którą w tym przypadku łączysz).

Pozwoli to zobaczyć, jakie zatwierdzenia przeszły do ​​pliku w dwóch gałęziach po ich rozbieżności. Zwykle znacznie ułatwia rozwiązywanie konfliktów.

    
15
2016-01-05 03: 45: 43Z

Od 12 grudnia 2016 r. możesz łączyć gałęzie i rozwiązywać konflikty na stronie github.com

Tak więc, jeśli nie chcesz używać wiersza polecenia lub żadnych narzędzi innych firm, które są oferowane tutaj ze starszych odpowiedzi , przejdź do natywnego narzędzia GitHub.

Ten wpis na blogu wyjaśnia szczegółowo, ale Podstawą jest to, że po „scaleniu” dwóch gałęzi za pomocą interfejsu użytkownika, zobaczysz teraz opcję „rozwiązywania konfliktów”, która przeniesie Cię do edytora, który pozwoli ci poradzić sobie z tymi konfliktami scalania.

 wprowadź opis obrazu tutaj>> </a> </p>
    </div>
<div class = 15

2017-01-09 19: 57: 14Z
  1. to nie pyta o github, dlatego przegrałem głosowanie, co uważam za bardzo słabą odpowiedź.
    2017-01-25 05: 06: 51Z
  2. dzięki za trzymanie mnie w ryzach, człowieku.
    2017-01-26 23: 07: 24Z
  3. @mschuett ma rację, pytanie brzmi „jak rozwiązać konflikty w git”, a nie „jak rozwiązywać konflikty w github”. Jest różnica i jest już zbyt wielu ludzi, którzy myślą, że git i github są tym samym, więc wszystko, co propaguje to uczucie, jest błędne.
    2018-04-05 16: 21: 56Z

Używanie patience

Jestem zaskoczony, że nikt inny nie mówił o rozwiązywaniu konfliktów za pomocą patience ze strategią rekurencyjną scalania. W przypadku wielkiego konfliktu scalającego użycie patience dało mi dobre wyniki. Chodzi o to, że spróbuje dopasować bloki zamiast pojedynczych linii.

Jeśli zmienisz na przykład wcięcie swojego programu, domyślna strategia scalania Git czasami pasuje do pojedynczych nawiasów {, które należą do różnych funkcji. Jest to możliwe dzięki patience:

 
git merge -s recursive -X patience other-branch

Z dokumentacji:

 
With this option, merge-recursive spends a little extra time to avoid 
mismerges that sometimes occur due to unimportant matching lines 
(e.g., braces from distinct functions). Use this when the branches to 
be merged have diverged wildly.

Porównanie ze wspólnym przodkiem

Jeśli masz konflikt scalania i chcesz zobaczyć, co inni mieli na myśli podczas modyfikowania swojego oddziału, czasami łatwiej jest porównać ich oddział bezpośrednio ze wspólnym przodkiem (zamiast naszej gałęzi). Do tego możesz użyć merge-base:

 
git diff $(git merge-base <our-branch> <their-branch>) <their-branch>

Zazwyczaj chcesz zobaczyć zmiany tylko dla konkretnego pliku:

 
git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>
    
15
2018-06-19 03: 31: 39Z
  1. W moim przypadku nie rozwiązało to dobrze konfliktów scalania, ponieważ z jakiegoś powodu utrzymywało duplikaty linii config w projektach C #. Chociaż był bardziej przyjazny niż CAŁY PLIK JEST INNY, co miałem wcześniej
    2017-09-08 07: 55: 23Z

Zawsze przestrzegam poniższych kroków, aby uniknąć konfliktów.

  • git checkout master (Come to the master branch)
  • git pull (Zaktualizuj swojego mistrza, aby uzyskać najnowszy kod)
  • git checkout -b mybranch (sprawdź nową gałąź i rozpocznij pracę na tej gałęzi, aby twój mistrz zawsze pozostawał na szczycie pnia).
  • git add. AND git commit ORAZ git push (na twojej lokalnej gałęzi po zmianach)
  • git checkout master (Wróć do swojego mistrza.)

Teraz możesz zrobić to samo i utrzymywać tyle oddziałów lokalnych, które chcesz, i pracować jednocześnie, gdy tylko będę potrzebował.     

12
2015-02-12 04: 25: 58Z

Jeśli chcesz połączyć się z gałęzi (testu) do master, możesz wykonać następujące kroki:

Krok 1: Idź do oddziału

 
git checkout test

Krok 2: git pull --rebase origin master

Krok 3: Jeśli są jakieś konflikty, przejdź do tych plików, aby je zmodyfikować.

Krok 4: Dodaj te zmiany

 
git add #your_changes_files

Krok 5: git rebase --continue

Krok 6: jeśli nadal występuje konflikt, wróć ponownie do kroku 3. Jeśli nie ma konfliktu, wykonaj następujące czynności: git push origin +test

Krok 7: I wtedy nie ma konfliktu między testem a mistrzem. Możesz użyć scalania bezpośrednio.

    
11
2018-06-19 03: 23: 34Z

Konflikty scalania mogą występować w różnych sytuacjach:

  • Podczas uruchamiania „git fetch”, a następnie „git merge”
  • Podczas uruchamiania „git fetch”, a następnie „git rebase”
  • Podczas uruchamiania „git pull” (który jest rzeczywiście równy jednemu z wyżej wymienionych warunków)
  • Podczas uruchamiania „git stash pop”
  • Kiedy stosujesz poprawki git (zatwierdzenia, które są eksportowane do plików, które mają zostać przesłane, na przykład pocztą elektroniczną)

Musisz zainstalować narzędzie do scalania, które jest kompatybilne z Git, aby rozwiązać konflikty. Osobiście używam KDiff3 i uważam, że jest miły i poręczny. Możesz pobrać jego wersję Windows tutaj:

https://sourceforge.net/projects/kdiff3/files/

BTJeśli zainstalujesz rozszerzenia Git, w kreatorze instalacji jest opcja instalacji Kdiff3.

Następnie skonfiguruj git configs, aby użył Kdiff jako swojego mergetool:

 
$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false

$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false

(Pamiętaj, aby zastąpić ścieżkę rzeczywistą ścieżką pliku exe Kdiff.)

Następnie za każdym razem, gdy natrafisz na konflikt scalania, wystarczy uruchomić to polecenie:

 
$git mergetool

Następnie otwiera Kdiff3 i najpierw próbuje automatycznie rozwiązać konflikty scalania. Większość konfliktów zostanie rozwiązana spontanicznie i musisz naprawić resztę ręcznie.

Oto jak wygląda Kdiff3:

 Wpisz opis obrazu tutaj>> </a> </p>

<p> Następnie, kiedy skończysz, zapisz plik i przejdzie do następnego pliku z konfliktem, a zrobisz to samo, aż wszystkie konflikty zostaną rozwiązane. </p>

<p> Aby sprawdzić, czy wszystko zostało pomyślnie scalone, ponownie uruchom komendę mergetool, powinieneś otrzymać ten wynik: </p>

 <pre><code>$git mergetool
No files need merging
</code></pre>
    </div>
<div class = 11

2018-06-19 03: 28: 18Z

Te odpowiedzi mają na celu dodanie alternatywy dla użytkowników VIM, takich jak ja, którzy wolą robić wszystko w edytorze.


TL; DR

 wprowadź opis obrazu tutaj>> </a> </p>

<hr>
<p> Tpope wymyślił tę świetną wtyczkę do VIMu, zwaną <a href= zbiegiem . Po zainstalowaniu można uruchomić :Gstatus, aby sprawdzić pliki, które mają konflikt, i :Gdiff, aby otworzyć Git w 3-etapowy sposób.

Po połączeniu na 3 sposoby, zbiegający pozwoli ci uzyskać zmiany w dowolnej gałęzi, którą łączysz w następujący sposób:

  •  :diffget //2, pobierz zmiany z oryginalnej ( HEAD ) gałęzi:
  •  :diffget //3, pobierz zmiany z łączącej się gałęzi:

Po zakończeniu scalania pliku wpisz :Gwrite w scalonym buforze. Vimcasts opublikował świetne wideo , wyjaśniając to szczegółowo kroki.

    
7
2018-05-10 11: 45: 24Z
  

git fetch
  git checkout twój oddział
  git rebase master

W tym kroku spróbujesz naprawić konflikt za pomocą preferowanego IDE

Możesz śledzić ten link, aby sprawdzić ho, aby naprawić konflikt w pliku
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/
/>

  

git dodaj
  git rebase --continue
  git commit --amend
  git push origin HEAD: refs /drafts /master (pchnij jak wersje robocze)

Teraz wszystko jest w porządku i znajdziesz swoje zatwierdzenie w gerrit

Mam nadzieję, że pomoże to każdemu w tej kwestii.

    
4
2017-07-05 13: 25: 30Z

Kod Gitlense dla VS

Możesz spróbować Gitlense dla kodu VS. Najważniejsze z nich to:

3. Łatwo rozwiązuj konflikty.

Już lubię tę funkcję:

 wprowadź opis obrazu tutaj>> </p>

<h3> 2. Obecna winna linia. </h3>

<p> <a href= wprowadź opis obrazu tutaj>> </p>

<h3> 3. Gutter Blame </h3>

<p> <a href= wprowadź opis obrazu tutaj>> </p>

<h3> 4. Pasek stanu winny </h3>

<p> <a href =  wprowadź opis obrazu tutaj>> </p>

<p> Jest wiele funkcji, które możesz sprawdzić <a href= tutaj .

    
4
2019-01-05 18: 33: 46Z

Spróbuj edytować kod Visual Studio, jeśli jeszcze go nie masz. To, co robi, to próba scalenia (i lądowania w konfliktach scalania). Kod VS automatycznie wykrywa konflikty scalania.

Może ci bardzo pomóc, pokazując, jakie zmiany zostały wprowadzone w oryginalnym i czy powinieneś zaakceptować incoming lub

current change (co oznacza oryginał przed połączeniem) „?.

To pomogło mi i może działać również dla ciebie!

PS: Będzie działać tylko wtedy, gdy skonfigurujesz git za pomocą kodu i kodu Visual Studio.

    
2
2018-03-16 06: 26: 08Z

Bezpieczniejszym sposobem rozwiązywania konfliktów jest użycie git-mediate (sugerowane wspólne rozwiązania tutaj są dość podatne na błędy imho).

Zobacz ten post , aby szybko zapoznać się z tym, jak go używać.

    
1
2016-12-29 16: 46: 35Z

Dla tych, którzy używają Visual Studio (2015 w moim przypadku)

  1. Zamknij projekt w VS. Szczególnie w dużych projektach VS ma tendencję do przerażania podczas łączenia za pomocą interfejsu użytkownika.

  2. Wykonaj scalanie w wierszu polecenia.

    git checkout target_branch

    git merge source_branch

  3. Następnie otwórz projekt w VS i przejdź do Team Explorer - > Oddział. Teraz pojawia się komunikat, że Merge jest w toku, a konfliktowe pliki są wyświetlane tuż pod wiadomością.

  4. Kliknij plik powodujący konflikt, a będziesz miał możliwość scalenia, porównania, pobrania źródła, podjęcia celu. Narzędzie scalania w VS jest bardzo łatwe w użyciu.

1
2017-07-10 20: 29: 53Z
  1. Używam VS Code 2017 w bardzo dużym projekcie i nie muszę zamykać projektu. Dobrze sobie z tym radzi :)
    2017-08-10 16: 22: 46Z

Jeśli używasz intelliJ jako IDE Spróbuj połączyć rodzica z oddziałem za pomocą

 
git checkout <localbranch>
git merge origin/<remotebranch>

Pokaże wszystkie konflikty takie jak ten

  

A_MBPro: test anu $git merge origin /Auto-merging   src /test /java /com /.../TestClass.java CONFLICT   (treść): Połącz konflikt w   src /test /java /com /.../TestClass.java

Zauważ, że plik TestClass.java jest pokazany na czerwono w intelliJ Pokaże się również status git

 
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   src/test/java/com/.../TestClass.java

Otwórz plik w intelliJ, będzie miał sekcje z

 
  <<<<<<< HEAD
    public void testMethod() {
    }
    =======
    public void testMethod() { ...
    }
    >>>>>>> origin/<remotebranch>

gdzie HEAD to zmiany w lokalnym oddziale i pochodzenie /jest zmianą w oddziale zdalnym. Tutaj przechowuj rzeczy, których potrzebujesz i usuń rzeczy, których nie potrzebujesz. Po tym powinny zrobić się zwykłe kroki. To jest

 
   git add TestClass.java
   git commit -m "commit message"
   git push
    
1
2017-08-07 15: 09: 13Z

Postępuję zgodnie z poniższym procesem.

Proces naprawiania konfliktu scalania:

  1. Najpierw pobierz najnowszą z gałęzi docelowej, z którą chcesz połączyć git pull origin develop

  2. W miarę otrzymywania najnowszego z miejsca docelowego,teraz rozwiąż konflikt ręcznie w IDE, usuwając te dodatkowe znaki.

  3. Wykonaj git add, aby dodać te edytowane pliki do kolejki git, tak aby mogła być commit i push do tej samej gałęzi, nad którą pracujesz.

  4. Gdy skończy się git add, zrób git commit, aby zatwierdzić zmiany.

  5. Teraz przesuń zmiany do gałęzi roboczej za pomocą git push origin HEAD

To jest to, a zobaczysz, że zostało rozwiązane w twojej prośbie o ściągnięcie, jeśli używasz Bitbucket lub GitHub.

    
1
2017-11-23 09: 06: 54Z
źródło umieszczone tutaj