Jak rozwiązać konflikty merge w repozytorium Git?
Chcę rozwiązać konflikty merge w moim Git repozytorium.
Jak to zrobić ?
30 answers
Spróbuj: git mergetool
Otwiera interfejs graficzny, który przeprowadzi Cię przez każdy konflikt, i możesz wybrać, jak połączyć. Czasami wymaga to trochę ręcznej edycji, ale zwykle wystarcza samo w sobie. Jest to o wiele lepsze niż robienie wszystkiego ręcznie.
Jak na @JoshGlover komentarz:
Komenda
Niekoniecznie otwiera GUI, chyba że go zainstalujesz. Bieganie
git mergetool
dla mnie zaowocowałovimdiff
użyciem. Możesz zainstalować jeden z następujące narzędzia do korzystania z niego zamiast: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 terminalu
git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false
To ustawi vimdiff jako domyślne narzędzie scalania.
Krok 2: uruchom następujące polecenie w terminalu
git mergetool
Krok 3 : zobaczysz wyświetlacz vimdiff w następującym formacie
╔═══════╦══════╦════════╗
║ ║ ║ ║
║ LOCAL ║ BASE ║ REMOTE ║
║ ║ ║ ║
╠═══════╩══════╩════════╣
║ ║
║ MERGED ║
║ ║
╚═══════════════════════╝
Te 4 odsłony to
LOCAL - jest to plik z bieżącej gałęzi
BASE-wspólny przodek, jak plik wyglądał przed obiema zmianami
REMOTE-plik, który łączysz do swojej gałęzi
MERGED-wynik scalenia, to jest to, co jest zapisywane w repo
Możesz poruszać się między tymi widokami używając ctrl+w . Możesz bezpośrednio przejść do widoku scalonego używając ctrl+w , po którym następuje j .
Więcej informacji o nawigacji vimdiff tutaj i tutaj
Krok 4 . Można edytować scalony widok w następujący sposób
Jeśli chcesz pobrać zmiany ze zdalnego
:diffg RE
Jeśli chcesz uzyskać zmiany z bazy
:diffg BA
Jeśli chcesz uzyskać zmiany z lokalnego
:diffg LO
Krok 5 . Zapisz, Zakończ, Zatwierdź i wyczyść up
:wqa
Zapisz i wyjdź z vi
git commit -m "message"
git clean
usuń dodatkowe pliki (np. *.orig) stworzony przez narzędzie diff.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-09-08 08:57:05
Oto prawdopodobny przypadek użycia, od góry:
Będziesz wyciągać pewne zmiany, ale oops, nie jesteś na bieżąco:
git fetch origin
git pull origin master
From ssh://[email protected]: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://[email protected]: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 postanowiłeś przyjrzeć się zmianom:
git mergetool
Oh my, oh my, upstream zmieniło kilka rzeczy, ale ż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"
And then we try a final time
git pull origin master
From ssh://[email protected]:22/projectname
* branch master -> FETCH_HEAD
Already up-to-date.
Ta-da!Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-06-10 08:10:35
Uważam, że narzędzia scalające rzadko pomagają mi zrozumieć konflikt lub rozwiązanie. Zazwyczaj lepiej sprawdzam znaczniki konfliktu w edytorze tekstu i używam git log jako dodatku.
Oto kilka wskazówek:
Tip One
Najlepszą rzeczą jaką znalazłem jest użycie stylu" diff3 " merge conflict:
git config merge.conflictstyle diff3
To tworzy znaczniki konfliktu takie jak:
<<<<<<<
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 tym, jak wyglądał wspólny przodek. Jest to przydatne ponieważ możesz porównać ją z górną i dolną wersją, aby lepiej zrozumieć, co zostało zmienione na każdej gałęzi, co daje lepsze wyobrażenie, jaki był cel każdej zmiany.
Jeśli konflikt jest tylko kilka linijek, to na ogół sprawia, że konflikt jest bardzo oczywisty. (Wiedza o tym, jak rozwiązać konflikt, jest zupełnie inna; musisz być świadomy tego, nad czym pracują inni ludzie. Jeśli jesteś zdezorientowany, prawdopodobnie najlepiej po prostu zadzwonić do tej osoby do swojego pokoju, aby mogła zobaczyć, kim jesteś patrzę.)
Jeśli konflikt jest dłuższy, wytnę i wkleję każdą z trzech sekcji do trzech oddzielnych plików, takich jak" moje"," wspólne "i"ich".
Następnie mogę uruchomić następujące polecenia, aby zobaczyć dwa diff hunks, które spowodowały konflikt:
diff common mine
diff common theirs
To nie to samo, co używanie narzędzia scalania, ponieważ narzędzie scalania będzie również zawierać wszystkie niekonfliktowe fragmenty różnic. To mnie rozprasza.
Wskazówka Druga
Ktoś już wspomniał to, ale zrozumienie intencji stojącej za każdym kawałkiem różnicowym jest ogólnie bardzo pomocne w zrozumieniu, skąd wziął się konflikt i jak sobie z nim poradzić.
git log --merge -p <name of file>
Pokazuje wszystkie commity, które dotknęły tego pliku pomiędzy wspólnym przodkiem a dwiema scalonymi głowami. (Więc nie zawiera commitów, które już istnieją w obu gałęziach przed scaleniem.) Pomaga to ignorować różnice, które wyraźnie nie są czynnikiem w obecnym konflikcie.
Końcówka Trzy
Zweryfikuj swoje zmiany za pomocą zautomatyzowanych narzędzi.
Jeśli masz zautomatyzowane testy, uruchom je. Jeśli masz lint, uruchom to. Jeśli jest to projekt do zbudowania, zbuduj go przed zatwierdzeniem itp. We wszystkich przypadkach musisz przeprowadzić trochę testów, aby upewnić się, że Twoje zmiany niczego nie zepsuły. (Heck, nawet połączenie bez konfliktów może złamać działający kod.)Wskazówka Czwarta
Planuj z wyprzedzeniem; komunikuj się ze współpracownikami.Planowanie z wyprzedzeniem i świadomość tego, co inni pracują nad może pomóc zapobiec konfliktom scalania i / lub pomóc rozwiązać je wcześniej-podczas gdy szczegóły są wciąż świeże w umyśle.
Na przykład, jeśli wiesz, że ty i inna osoba pracujecie nad różnymi refaktoryzacjami, które będą miały wpływ na ten sam zestaw plików, powinieneś porozmawiać ze sobą wcześniej i lepiej zrozumieć, jakie rodzaje zmian wprowadza każdy z was. Możesz zaoszczędzić sporo czasu i wysiłku, jeśli przeprowadzasz planowane zmiany seryjnie, a niż równolegle.
W przypadku głównych refaktoringów, które przecinają duży obszar kodu, należy zdecydowanie rozważyć pracę seryjną: każdy przestaje pracować nad tym obszarem kodu, podczas gdy jedna osoba wykonuje pełną refaktoryzację.
Jeśli nie możesz pracować seryjnie (być może z powodu presji czasu), komunikowanie o oczekiwanych konfliktach scalania przynajmniej pomaga rozwiązać problemy wcześniej, podczas gdy szczegóły są wciąż świeże. Na przykład, jeśli współpracownik dokonuje uciążliwego seria commitów w ciągu jednego tygodnia, możesz zdecydować się na scalanie / rebase w tej gałęzi co-workers raz lub dwa razy dziennie w ciągu tego tygodnia. W ten sposób, jeśli znajdziesz konflikty merge/rebase, możesz je rozwiązać szybciej niż jeśli poczekasz kilka tygodni, aby połączyć wszystko razem w jedną dużą bryłę.
Tip Five
Jeśli nie jesteś pewien połączenia, nie zmuszaj go.Scalanie może być przytłaczające, zwłaszcza gdy istnieje wiele sprzecznych plików i konflikt znaczniki obejmują setki linii. Często podczas szacowania projektów oprogramowania nie uwzględniamy wystarczająco dużo czasu na nadmiarowe elementy, takie jak obsługa gnarly merge, więc spędzanie kilku godzin na analizowaniu każdego konfliktu wydaje się być prawdziwym wyzwaniem.
W dłuższej perspektywie planowanie z wyprzedzeniem i świadomość tego, nad czym pracują inni, są najlepszymi narzędziami do przewidywania konfliktów scalania i przygotowania się do ich poprawnego rozwiązania w krótszym czasie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-07-23 17:32:54
Określ, które pliki są w konflikcie (Git powinien ci to powiedzieć).
Otwórz każdy plik i sprawdź dyfuzory; Git je rozgranicza. Mam nadzieję, że będzie oczywiste, która wersja każdego bloku zachować. Być może będziesz musiał omówić to z innymi programistami, którzy popełnili ten kod.
Po rozwiązaniu konfliktu w pliku
git add the_file
.Po rozwiązaniu wszystkich konfliktów, wykonaj
git rebase --continue
lub jakiekolwiek polecenie Git said to do when you zakończone.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-08-07 17:48:46
Konflikty scalania występują, gdy zmiany są wprowadzane do pliku w tym samym czasie. Oto jak go rozwiązać.
git
CLI
Oto proste kroki, co zrobić, gdy wejdziesz w stan konfliktowy:
- zwróć uwagę na listę skonfliktowanych plików z:
git status
(w sekcjiUnmerged paths
). -
Rozwiązuj konflikty oddzielnie dla każdego pliku za pomocą jednego z następujących sposobów:
Użyj GUI do rozwiązywania 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
jednak trzeba być ostrożnym, jak zdalne zmiany, że konflikty zostały wykonane z jakiegoś powodu.
Related: jakie jest dokładne znaczenie "Nasze" i " ich " w git?
Ręcznie Edytuj skonfliktowane pliki i poszukaj bloku kodu między
<<<<<
/>>>>>
następnie wybierz wersję z góry lub z dołu=====
. Zobacz: Jak przedstawia się konflikty .Konflikty ścieżek i nazw plików można rozwiązać poprzez
git add
/git rm
.
-
Na koniec przejrzyj pliki gotowe do zatwierdzenia używając:
git status
.Jeśli nadal masz jakieś pliki Pod
Unmerged paths
i rozwiązałeś konflikt ręcznie, daj znać Gitowi, że rozwiązałeś go przez:git add path/file
. Gdyby wszystkie konflikty były rozwiązano pomyślnie, zatwierdź zmiany przez:
git commit -a
i wciśnij jak zwykle do remote.
Zobacz także: rozwiązywanie konfliktu merge z linii poleceń {[49] } na GitHub
Aby uzyskać praktyczny samouczek, sprawdź: Scenariusz 5-naprawianie konfliktów Merge przez Katacoda .
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 pomiędzy 3 plikami i umożliwia automatyczne scalanie (gdy jest to bezpieczne) i pełną kontrolę nad edycją pliku wynikowego.
źródło obrazu: DiffMerge (Linux screenshot)
Po prostu pobierz i uruchom w repo jako:
git mergetool -t diffmerge .
MacOS
Na macOS można zainstalować przez:
brew install caskroom/cask/brew-cask
brew cask install diffmerge
I prawdopodobnie (jeśli nie podano) potrzebujesz dodatkowego prostego wrappera umieszczonego w ścieżce (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 klawiszowych:
- ⌘-Alt-do góry/W Dół aby przejść do poprzednich / następnych zmian.
- ⌘-Alt-zostawić/prawo aby zaakceptować zmianę od lewej lub prawej
Alternatywnie możesz użyć opendiff (część narzędzi Xcode), który pozwala połączyć dwa pliki lub katalogi razem, aby utworzyć trzeci plik lub katalog.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-10-15 09:32:29
Sprawdź odpowiedzi w pytaniu Stack Overflow przerywanie połączenia 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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 11:47:34
Jeśli tworzysz często małe commity, zacznij od spojrzenia na komentarze commitów za pomocą git log --merge
. Następnie git diff
pokaże Ci konflikty.
W przypadku konfliktów, które obejmują więcej niż kilka wierszy, łatwiej jest zobaczyć, co się dzieje w zewnętrznym narzędziu GUI. Lubię opendiff -- Git obsługuje również vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, emerge out of the box i można zainstalować inne: git config merge.tool "your.tool"
ustawi wybrane narzędzie, a następnie git mergetool
po nieudanym scaleniu pokaże diffy w kontekst.
Za każdym razem, gdy edytujesz plik w celu rozwiązania konfliktu, git add filename
zaktualizuje indeks i twój diff nie będzie go już wyświetlał. Gdy wszystkie konflikty są obsługiwane i ich pliki zostały git add
- ed, {[6] } zakończy połączenie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-07-23 17:43:21
Zobacz Jak prezentowane są konflikty lub, w Git, dokumentację git merge
aby zrozumieć czym są znaczniki konfliktu merge.
Po zobaczeniu konfliktu, możesz zrobić dwie rzeczy:
Możesz przejść przez konflikt za pomocą wielu narzędzi:]}
Zdecyduj się nie łączyć. Jedyne, czego potrzebujesz, to zresetowanie pliku indeksu do commitu
HEAD
do reverse 2. i sprzątanie pracujące zmiany drzewa dokonane przez 2. oraz 3.;git merge --abort
może być do tego używany.Rozwiąż konflikty. Git zaznaczy konflikty w roboczym drzewie. Edytuj pliki do kształtu i
git add
je do indeksu. Użyjgit commit
, aby przypieczętować transakcję.
Użyj mergetool.
git mergetool
aby uruchomić graficzny program mergetool, który będzie pracował przez połączenie.Spójrz na różnice.
git diff
pokaże trójdrożny diff, zaznaczanie zmian zarówno w wersjiHEAD
, jak iMERGE_HEAD
.Spójrz na różnice z każdej gałęzi.
git log --merge -p <path>
wyświetli najpierw diffy dla wersjiHEAD
, a następnie dla wersjiMERGE_HEAD
.- Spójrz na oryginały.
git show :1:filename
pokazuje wspólny przodek,git show :2:filename
pokazuje wersjęHEAD
, agit show :3:filename
pokazuje wersjęMERGE_HEAD
.
Możesz również przeczytać o znacznikach konfliktu merge i jak je rozwiązać w sekcji Pro Git Podstawowe Konflikty Merge .
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-06-20 09:12:55
Chcę albo moją lub ich wersję w całości, albo chcę przejrzeć poszczególne zmiany i zdecydować dla każdej z nich.
W pełni Zaakceptuj moją lub ich wersję :
Accept my version (local, ours):
git checkout --ours -- <filename>
git add <filename> # Marks conflict as resolved
git commit -m "merged bla bla" # An "empty" commit
Przyjmij ich wersję (zdalną, ich):
git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"
Jeśli chcesz zrobić dla wszystkich plików konfliktowych Uruchom:
git merge --strategy-option ours
Lub
git merge --strategy-option theirs
Przejrzyj wszystkie zmiany i zaakceptuj je indywidualnie
git mergetool
- przejrzyj zmiany i zaakceptuj każdą z nich.
git add <filename>
git commit -m "merged bla bla"
Domyślnie mergetool
działa w linii poleceń . Jak używać wiersza poleceń mergetool powinno być osobnym pytaniem.
Możesz również zainstalować visual tool , np. meld
i uruchomić
git mergetool -t meld
Otworzy wersję lokalną (naszą)," bazową " lub "scaloną" (bieżący wynik scalenia) i wersja zdalna (ich). Zapisz scaloną wersję po zakończeniu, uruchom git mergetool -t meld
ponownie, aż otrzymasz "żadne pliki nie wymagają scalania", a następnie przejdź do kroków 3. i 4.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-06-19 03:29:48
Dla Emacs użytkowników, którzy chcą rozwiązywać konflikty merge 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 na raz przez:
emacs $(git diff --name-only --diff-filter=U)
Podczas odwiedzania bufora wymagającego edycji w Emacsie wpisz
ALT+x vc-resolve-conflicts
Otworzy to trzy bufory (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ć mój lub ich region do odpowiednio bufor wyjściowy. I / lub bezpośrednio edytować bufor wyjściowy.
Po zakończeniu: naciśnij "q". Emacs pyta, czy chcesz zapisać ten bufor: tak. Po zakończeniu bufora oznacz go jako rozwiązany, uruchamiając z teriminalu:
git add FILENAME
Po zakończeniu wszystkich buforów typu
git commit
Aby zakończyć połączenie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-07-23 17:24:52
Bonus:
Mówiąc o pull/fetch/merge w powyższych odpowiedziach, chciałbym podzielić się ciekawą i produktywną sztuczką,
git pull --rebase
Powyższa komenda jest najbardziej użyteczną komendą w moim życiu Gita, która zaoszczędziła dużo czasu.
Przed wysłaniem nowo zatwierdzonej zmiany do serwera zdalnego, spróbuj git pull --rebase
raczej git pull
i manual merge
, Aby automatycznie zsynchronizować ostatnie zmiany na serwerze zdalnym (za pomocą fetch + merge) i umieścić lokalny najnowszy commit na górze w git log. Nie musisz się martwić ręcznym ciągnięciem / scalaniem.
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-06-20 09:12:55
Po prostu, jeśli dobrze wiesz, że zmiany w jednym z repozytoriów nie są ważne, a 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 .
W przeciwnym razie będziesz musiał użyć narzędzia scalania GUI, aby przejść przez pliki jeden po drugim, powiedzmy, że narzędzie scalania to p4merge
, lub wpisać czyjąś nazwę, którą już masz installed
git mergetool -t p4merge
I po zakończeniu Pliku będziesz musiał zapisać i zamknąć, więc otworzy się następny.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-06-19 03:26:09
Wykonaj następujące kroki, aby naprawić konflikty merge w Git:
Sprawdź status Git: git status
-
Pobierz patchset: git fetch (checkout the right patch from your git commit)
Sprawdź lokalny oddział (temp1 w moim przykładzie tutaj): git checkout-B temp1
Wyciągnij ostatnią zawartość z master: git pull --rebase origin mistrz
Uruchom mergetool, sprawdź konflikty i napraw je...i sprawdź zmiany w zdalnej gałęzi z bieżącą gałęzią: git mergetool
Sprawdź status ponownie: git status
Usuń niechciane pliki lokalnie utworzone przez mergetool, Zwykle mergetool tworzy dodatkowy plik z *.oryg. Proszę usunąć ten plik, ponieważ jest to tylko duplikat i naprawić zmiany lokalnie i dodaj poprawną wersję swoich plików. git add #your_changed_correct_files
Sprawdź status ponownie: git status
Zatwierdź zmiany do tego samego identyfikatora zatwierdzenia (pozwala to uniknąć nowego oddzielnego zestawu poprawek): git commit --amend
-
Push to the master branch: git push (do twojego repozytorium Git)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-06-19 03:25:07
Istnieją 3 kroki:
-
Znajdź pliki powodujące konflikty za pomocą polecenia
git status
-
Sprawdź pliki, w których znajdziesz konflikty oznaczone jako
<<<<<<<<head blablabla
-
Zmień go tak, jak chcesz, a następnie zatwierdź za pomocą komend
git add solved_conflicts_files git commit -m 'merge msg'
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-05 21:03:45
[2] odpowiedź CoolAJ86 podsumowuje prawie wszystko. W przypadku zmian w obu gałęziach w tym samym fragmencie kodu będziesz musiał wykonać ręczne scalanie. 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 taki 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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-07-23 17:17:38
Można naprawić konflikty merge na wiele sposobów, jak inne szczegółowo opisały.
Myślę, że kluczem do sukcesu jest wiedza o przepływie zmian w repozytoriach lokalnych i zdalnych. Kluczem do tego jest zrozumienie gałęzi śledzenia. Odkryłem, że myślę o gałęzi śledzenia jako "brakujący kawałek w środku" między mną mój lokalny, rzeczywisty katalog plików i zdalny zdefiniowany jako origin.
Osobiście mam w zwyczaju dwie rzeczy, aby tego uniknąć.Zamiast of:
git add .
git commit -m"some msg"
Który ma dwie wady -
A) dodawane są wszystkie nowe/zmienione pliki, które mogą zawierać niepożądane zmiany.
b) nie możesz najpierw przejrzeć listy plików.
Więc 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 rozmyślny o tym, które pliki zostaną dodane, a także możesz przejrzeć listę i pomyśleć trochę więcej podczas korzystania z edytora wiadomości. Uważam, że poprawia to również moje komunikaty commit, gdy używam edytora pełnoekranowego, a nie -m
opcja.
[Update - z biegiem czasu przesiadłem się na:
git status # Make sure I know whats going on
git add .
git commit # Then use the editor
]
Również (i bardziej istotne dla twojej sytuacji), staram się unikać:
git pull
Lub
git pull origin master.
Ponieważ pull implikuje scalenie i jeśli masz zmiany lokalnie, których nie chcesz scalać, możesz łatwo skończyć z scalonym kodem i / lub konfliktami scalania dla kodu, który nie powinien być scalony.
Zamiast tego staram się zrobić
git checkout master
git fetch
git rebase --hard origin/master # or whatever branch I want.
Możesz również znaleźć to pomocne:
Git branch, fork, fetch, merge, rebase i clone, jakie są różnice?
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:18:27
Jeśli chcesz połączyć się z gałęzi test
do master
, możesz wykonać następujące kroki:
Krok 1 : przejdź do gałęzi
git checkout test
Krok 2:
git pull --rebase origin master
Krok 3: Jeśli występują 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 istnieje konflikt, wróć do kroku 3 ponownie. Jeśli nie ma konfliktu, zrób po:
git push origin +test
Krok 7: i wtedy nie ma konfliktu między testem a mistrzem. Możesz użyć merge bezpośrednio.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2021-02-02 05:24:33
git log --merge -p [[--] path]
Wydaje się, że nie zawsze działa na mnie i zwykle kończy się wyświetlaniem każdego commita, który różnił się między dwiema gałęziami, dzieje się tak nawet wtedy, gdy używasz --
do oddzielenia ścieżki od polecenia.
Aby obejść ten problem, otwieram dwie linie komend i w jednym uruchomieniu
git log ..$MERGED_IN_BRANCH --pretty=full -p [path]
I w drugiej
git log $MERGED_IN_BRANCH.. --pretty=full -p [path]
Zastąpienie $MERGED_IN_BRANCH
gałęzią, z którą się połączyłem i [path]
plikiem, który jest sprzeczny. To polecenie zarejestruje wszystkie commity w patchu form, between (..
) two commits. Jeśli pozostawisz jedną stronę pustą, jak w powyższych poleceniach, git automatycznie użyje HEAD
(gałąź, do której w tym przypadku się łączysz).
To pozwoli Ci zobaczyć, jakie commity weszły do pliku w obu gałęziach po ich rozdzieleniu. Zwykle znacznie ułatwia to rozwiązywanie konfliktów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-01-05 03:45:43
Użycie patience
W przypadku dużego konfliktu scalania, użycie patience
dało mi dobre wyniki. Będzie starał się dopasować bloki, a nie poszczególne linie.
Jeśli zmienisz na przykład wcięcie programu, domyślna strategia Git merge czasami pasuje do pojedynczych nawiasów {
, które należą do różnych funkcji. Unika się tego za pomocą 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 połączenie konflikt i chcesz zobaczyć, co inni mieli na myśli modyfikując swoją gałąź, czasami łatwiej jest porównać ich gałąź 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>
Zwykle chcesz zobaczyć tylko zmiany dla konkretnego pliku:
git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file>
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-08-06 08:31:30
Od 12 grudnia 2016 r. można łączyć gałęzie i rozwiązywać konflikty na github.com
Tak więc, jeśli nie chcesz używać wiersza poleceń lub jakichkolwiek narzędzi innych firm, które są oferowane tutaj ze starszych odpowiedzi , Wybierz natywne narzędzie GitHub.
Ten wpis na blogu wyjaśnia szczegółowo, ale podstawy są takie, że po "połączeniu" dwóch gałęzi za pośrednictwem interfejsu użytkownika zobaczysz opcję "rozwiązuj konflikty", która zabierze cię do edytora, który pozwoli Ci poradzić sobie z tymi problemami scalanie konfliktów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-01-09 19:57:14
Zawsze postępuję zgodnie z poniższymi krokami, aby uniknąć konfliktów.
- Git checkOut master (Come to the master branch)
- git pull (Update your master to get the latest code)
- git checkout-B mybranch (Checkout a new a branch and start working on that branch so that your master always remains top of trunk.)
- git add . Oraz git commit i git push (w lokalnej gałęzi po zmianach)
- git checkout master (wróć do swojego mistrza.)
Teraz możesz zrobić to samo i utrzymać tyle lokalnych oddziałów, ile chcesz i pracować jednocześnie my po prostu robi Git checkout do swojej gałęzi, gdy kiedykolwiek będzie to konieczne.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-02-12 04:25:58
Konflikty scalające mogą wystąpić w różnych sytuacjach:
- podczas biegu
git fetch
a następniegit merge
- podczas biegu
git fetch
a następniegit rebase
- podczas biegu
git pull
(który jest w rzeczywistości równy jednemu z wyżej wymienionych warunków) - podczas biegu
git stash pop
- podczas stosowania łatek git (commity, które są eksportowane do plików, które mają być przesłane, na przykład przez e-mail)
Musisz zainstalować narzędzie scalające, które jest kompatybilne z Git, aby rozwiązywać konflikty. Osobiście używam KDiff3 i uważam, że jest ładny i poręczny. Możesz pobrać jego wersję Dla Windows tutaj:
Https://sourceforge.net/projects/kdiff3/files/
BTW jeśli instalujesz Git Extensions jest opcja w kreatorze konfiguracji aby zainstalować Kdiff3.
Następnie skonfiguruj git configs, aby używał 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ę ścieżką pliku exe kdiff.)
Wtedy za każdym razem, gdy natkniesz się na merge conflict wystarczy uruchomić to polecenie:
$ git mergetool
Następnie otwiera Kdiff3 i najpierw próbuje rozwiązać konflikty scalania automatycznie. Większość konfliktów zostanie rozwiązana spontanicznie, a resztę trzeba naprawić ręcznie.
Oto jak wygląda Kdiff3:
Następnie po zakończeniu zapisz plik i przechodzi do następnego pliku z konfliktem i robisz to samo ponownie, dopóki wszystkie konflikty nie zostaną rozwiązane.
To sprawdź, czy wszystko zostało połączone pomyślnie, po prostu uruchom ponownie polecenie mergetool, powinieneś otrzymać taki wynik:
$ git mergetool
No files need merging
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-09-30 16:19:38
Ta odpowiedź polega na dodaniu alternatywy dla tych użytkowników VIMÓW, takich jak ja, którzy wolą robić wszystko w edytorze.
TL;DR
Tpope wymyślił świetną wtyczkę dla Vima o nazwie fugitive. Po zainstalowaniu możesz uruchomić :Gstatus
, aby sprawdzić pliki, które mają konflikt i :Gdiff
, aby otworzyć Git na 3 sposoby.
Po połączeniu 3-ways, pozwoli ci uzyskać zmiany dowolnej gałęzi, którą jesteś łączenie w następujący sposób:
-
:diffget //2
, get changes from original (HEAD) branch: -
:diffget //3
, pobiera zmiany z gałęzi scalania:
Po zakończeniu scalania pliku wpisz :Gwrite
w scalonym buforze.
Vimcasts opublikował świetny film wyjaśniający szczegółowo te kroki.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-05-10 11:45:24
Gitlense for VS Code
Możesz wypróbować Gitlense dla VS Code, kluczowe cechy to:
3. Łatwe Rozwiązywanie Konfliktów.
Już lubię tę funkcję:
2. / Align = "Left" / Linear
3. Gutter Blame
4. Pasek Stanu
I jest wiele funkcji, które możesz sprawdzić tutaj .
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-01-05 18:33:46
git fetch <br>
git checkout **your branch**<br>
git rebase master<br>
W tym kroku spróbujesz rozwiązać konflikt używając preferowanego IDE.
Możesz śledzić ten link, aby sprawdzić, jak naprawić konflikt w pliku
git add<br>
git rebase --continue<br>
git commit --amend<br>
git push origin HEAD:refs/drafts/master (push like a drafts)<br>
Teraz wszystko jest w porządku i znajdziesz swój commit w gerrit
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-09-30 16:35:03
Bezpieczniejszym sposobem rozwiązywania konfliktów jest użycie git-mediate (typowe rozwiązania proponowane tutaj są dość podatne na błędy imho).
W tym artykule dowiesz się, jak z niego korzystać.Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-12-29 16:46:35
Dla tych, którzy korzystają z Visual Studio (w moim przypadku 2015)
Zamknij swój projekt w VS. zwłaszcza w dużych projektach VS ma tendencję do świrowania podczas łączenia za pomocą interfejsu użytkownika.
-
Wykonaj scalanie w wierszu polecenia.
Git checkout target_branch
Git merge source_branch
Następnie otwórz projekt W VS i przejdź do Team Explorer - > Branch. Teraz jest komunikat, że Merge jest w toku i sprzeczne pliki są wymienione tuż pod wiadomość.
Kliknij plik kolidujący, a będziesz miał opcję scalania, porównywania, pobierania źródła, pobierania celu. Narzędzie merge W VS jest bardzo łatwe w użyciu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-07-10 20:29:53
Spróbuj edytować Visual Studio Code, Jeśli jeszcze tego nie zrobiłeś. To, co robi, to po próbie scalenia (i wylądowaniu w konfliktach scalania).VS code automatycznie wykrywa konflikty scalania.
Może ci bardzo pomóc, pokazując, jakie są zmiany wprowadzone do oryginału i powinieneś zaakceptować incoming
lub
current change
(czyli oryginalna przed połączeniem)"?.
Pomogło mi i może działać również dla Ciebie !
PS: będzie działać tylko jeśli skonfigurowałeś git z Twój kod i Visual Studio Code.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-03-16 06:26:08
Używam kodu wizualnego Microsoftu do rozwiązywania konfliktów. Jest bardzo prosty w użyciu. Mój projekt jest otwarty w przestrzeni roboczej. Wykrywa i podświetla konflikty, ponadto daje opcje GUI, aby wybrać dowolną zmianę, którą chcę zachować z głowy lub przychodzącą.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-10-02 06:53:35
Jeśli używasz intelliJ jako IDE Spróbuj połączyć rodzica z gałęzią przez
git checkout <localbranch>
git merge origin/<remotebranch>
Pokaże wszystkie konflikty jak to
A_mbpro: test Anu$ git merge origin/ Auto-merging src / test / java / com/.../ TestClass.java CONFLICT [content]: Merge conflict in src / test / java / com/.../ TestClass.java
Teraz zauważ, że plik TestClass.java jest pokazana na Czerwono w intelliJ Również git status pokaże
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 zmienia się w lokalnej gałęzi, a origin / zmienia się w zdalnej gałęzi. Tutaj trzymaj rzeczy, których potrzebujesz i usuń rzeczy, których nie potrzebujesz.Po tym normalne kroki powinny zrobić. To jest
git add TestClass.java
git commit -m "commit message"
git push
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-08-07 15:09:13