Jak rozwiązywać konflikty merge w Git
Czy jest dobry sposób na wyjaśnienie jak rozwiązywać konflikty merge w Git?
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:
Polecenie nie musi otwierać interfejsu graficznego, chyba że go zainstalujesz. Bieganie git mergetool
dla mnie zaowocowało vimdiff
użyciem. Możesz zainstalować jedno z następujących narzędzi użyj go zamiast tego: 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świetlanie 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 w swoją gałąź
MERGED-wynik scalenia, to jest to, co jest zapisywane w repo
Możesz poruszać się między tymi widokami za pomocą ctrl+w
. Możesz bezpośrednio dotrzeć do widoku scalonego za pomocą ctrl+w
, a następnie 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 . Save, Exit, Commit and Clean 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
2018-03-23 10:52:49
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 me, 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
2014-04-16 23:13:42
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
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
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
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 łączenie (gdy jest to bezpieczne) i pełną kontrolę nad edycją plik wynikowy.
ź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ącej klawiatury skróty:
- ⌘-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
2017-05-23 10:31:39
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. oraz do sprzątania pracującego drzewa zmian dokonanych przez 2. i 3.;git merge --abort
może być do tego używany.Rozwiązywać 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żne rozróżnienie, podkreślające zmiany 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 Pro Git book section Basic Merge Conflicts.
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:22:15
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
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
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
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
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
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 ręcznie merge
, Aby automatycznie zsynchronizować najnowsze zmiany na serwerze zdalnym (z fetch + merge) i umieści twój lokalny najnowszy commit u góry 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
2015-12-31 03:30:19
[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
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
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
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
Użycie patience
Dziwię się, że nikt inny nie mówił o rozwiązywaniu konfliktów za pomocą patience
ze strategią rekurencyjną merge. W przypadku dużego konfliktu scalania użycie patience
dało mi dobre wyniki. Chodzi o to, że 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 przy 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, 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
2018-06-19 03:31:39
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
Jeśli chcesz połączyć gałąź (test) z 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, wykonaj następujące czynności: git push origin +test
Krok 7: i wtedy nie ma konfliktu między testem a mistrzem. Ty można 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
2018-06-19 03:23:34
Konflikty scalające mogą wystąpić w różnych sytuacjach:
- podczas uruchamiania "git fetch" i "git merge"
- podczas uruchamiania "git fetch" i "GIT rebase"
- podczas uruchamiania "git pull" (który jest w rzeczywistości równy jednemu z wyżej wymienionych warunków)
- podczas uruchamiania "git stash pop"
- podczas stosowania łatek git (commity, które są eksportowane do plików, które mają zostać przesłane, na przykład przez e-mail)
Musisz zainstalować narzędzie scalające, które jest kompatybilny z Git do rozwiązywania konfliktów. 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 jego 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 konflikt scalający, wystarczy uruchomić tę komendę:
$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, aż wszystkie konflikty są rozwiązane.
Aby sprawdzić, 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
2018-06-19 03:28:18
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
Git fetch
git checkout your branch
Git rebase master
W tym kroku spróbujesz naprawić konflikt używając preferowanego IDE
Możesz skorzystać z tego linku, aby sprawdzić ho, aby rozwiązać konflikt w file
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/
Git add
Git rebase --continue
git commit --amend
git push origin HEAD: refs/drafts / master (push like a drafts)
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
2017-07-05 13:25:30
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
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
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
Postępuję zgodnie z poniższym procesem.
Proces naprawiania konfliktu merge:
Najpierw wyciągnij najnowszą gałąź z gałęzi docelowej, do której chcesz scalić
git pull origin develop
Gdy otrzymasz najnowsze informacje z miejsca docelowego, teraz rozwiąż konflikt ręcznie w IDE, usuwając te Dodatkowe znaki.
Wykonaj
git add
aby dodać te edytowane pliki do kolejki git, aby mogły byćcommit
ipush
do tej samej gałęzi, w której pracujesz onGdy
git add
zostanie zrobione, wykonajgit commit
, aby zatwierdzić zmiany.Teraz przesuń zmiany do działającej gałęzi przez
git push origin HEAD
To jest to i zobaczysz to rozwiązane w żądaniu pull, jeśli używasz Bitbucket lub GitHub.
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-11-23 09:06:54
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
git checkout branch1
git fetch origin
git rebase -p origin/mainbranch
Jeśli występują konflikty scalające, napraw je. Następnie kontynuuj proces rebase, uruchamiając: git rebase –-continue
Po naprawieniu Możesz zatwierdzić i wypchnąć lokalną gałąź do zdalnej gałęzi
git push origin branch1
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-01-15 09:15:45