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.

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.

Wskazówka Czwarta

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

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.

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

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

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

4. Po rozwiązaniu wszystkich konfliktów, wykonaj git rebase --continue lub jakiekolwiek polecenie Git said to do when you zakończone.

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

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:

1. zwróć uwagę na listę skonfliktowanych plików z: git status (w sekcji Unmerged paths).

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

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

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

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.

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:

• 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żyj git commit, aby przypieczętować transakcję.

Możesz przejść przez konflikt za pomocą wielu narzędzi:]}

• 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 wersji HEAD, jak i MERGE_HEAD.

• Spójrz na różnice z każdej gałęzi. git log --merge -p <path> wyświetli najpierw diffy dla wersji HEAD, a następnie dla wersji MERGE_HEAD.

• Spójrz na oryginały. git show :1:filename pokazuje wspólny przodek, git show :2:filename pokazuje wersję HEAD, a git 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.

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.

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

1. Sprawdź status Git: git status

2. Pobierz patchset: git fetch (checkout the right patch from your git commit)

3. Sprawdź lokalny oddział (temp1 w moim przykładzie tutaj): git checkout-B temp1

4. Wyciągnij ostatnią zawartość z master: git pull --rebase origin mistrz

5. Uruchom mergetool, sprawdź konflikty i napraw je...i sprawdź zmiany w zdalnej gałęzi z bieżącą gałęzią: git mergetool

6. Sprawdź status ponownie: git status

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

8. Sprawdź status ponownie: git status

9. Zatwierdź zmiany do tego samego identyfikatora zatwierdzenia (pozwala to uniknąć nowego oddzielnego zestawu poprawek): git commit --amend

10. Push to the master branch: git push (do twojego repozytorium Git)

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.

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

1. git mergetool
2. przejrzyj zmiany i zaakceptuj każdą z nich.
3. git add <filename>
4. 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.

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.

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?

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

[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

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.

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.

Istnieją 3 kroki:

1. Znajdź pliki powodujące konflikty za pomocą polecenia

   git status
   

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

   <<<<<<<<head
   blablabla
   

3. Zmień go tak, jak chcesz, a następnie zatwierdź za pomocą komend

   git add solved_conflicts_files
   git commit -m 'merge msg'
   

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>

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.

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.

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

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.

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

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.

Dla tych, którzy korzystają z Visual Studio (w moim przypadku 2015)

1. Zamknij swój projekt w VS. zwłaszcza w dużych projektach VS ma tendencję do świrowania 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 - > Branch. Teraz jest komunikat, że Merge jest w toku i sprzeczne pliki są wymienione tuż pod wiadomość.

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

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

Postępuję zgodnie z poniższym procesem.

Proces naprawiania konfliktu merge:

1. Najpierw wyciągnij najnowszą gałąź z gałęzi docelowej, do której chcesz scalić git pull origin develop

2. Gdy otrzymasz najnowsze informacje 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, aby mogły być commit i push do tej samej gałęzi, w której pracujesz on

4. Gdy git add zostanie zrobione, wykonaj git commit, aby zatwierdzić zmiany.

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

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

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