2012-06-15 13 views
8

Połączyłem dwie gałęzie. Mam mnóstwo konfliktów. Rozwiązał je wszystkie. Teraz nie jestem pewien, może popełniłem błąd podczas rozwiązywania konfliktów. I nie widzę innego sposobu sprawdzenia, czy to prawda - wystarczy ponownie uruchomić scalanie i sprawdzać konflikty jeden po drugim.git powoduje konflikty z poprzedniego łączenia bez ponownego scalania

Oznacza to, że muszę utworzyć jeszcze jeden oddział do przechowywania wyników mojego scalenia, prawda?

Czy mogę tego uniknąć? Być może jest możliwe, aby uzyskać wszystkie sprzeczne pliki z tymi wszystkimi <<<<<<, ======, >>>>>> skądś w git, bez ponownego uruchamiania scalania?

+0

Może powinieneś zaakceptować jedną z odpowiedzi. – dotancohen

+0

Nie sądzę, że odpowiedzi rzeczywiście odpowiadają na pytanie. Późniejsze scalenia nie powinny wykazywać takich samych konfliktów z poprzednich połączeń. – e40

Odpowiedz

3

Jeśli chcesz spojrzeć na to, co scalania nie można zrobić

git show <hash-of-merge-commit> 

Jeśli chcesz przerobić całą seryjnej robisz

git checkout <branch-that-you-merged-to> 
git reset --hard <hash-of-the-commit-just-before-the-merge> 
git merge <branch-that-you-merged-in> 

Jeśli chcesz przerobić seryjnej, a następnie porównaj drugie scalenie z pierwszym scaleniem (aby rozważyć, czy było lepiej) możesz zrobić:

git checkout <branch-that-you-merged-to> 
git rev-parse HEAD 

To da s jesteś haszem bieżącego zatwierdzenia. Zanotuj to. Następnie zrobić

git reset --hard <hash-of-the-commit-just-before-the-merge> 
git merge <branch-that-you-merged-in> 

Ukończ scalanie, a następnie zrobić to porównać scala

git difftool <hash-of-commit-noted-above> 

Jeśli czujesz, że oryginalny seryjnej było lepiej, można zrobić

git reset --hard <hash-of-commit-noted-above> 
+0

Podczas scalania możesz grać z "git show: 1: file.txt", aby dostać się do bazy scalonej, ": 2: file.txt", aby pokazać docelowy plik scalania, ": 3: file.txt ", aby pokazać plik scalający –

2

Tak, jest trywialne. Przede wszystkim musisz znaleźć identyfikator sha1 zatwierdzenia scalenia przy użyciu git log. Gdy wykonasz następną:

git checkout <sha1>^1 
git merge <sha1>^2 

będziesz w stanie bez głowy. ^n oznacza n-tego rodzica zatwierdzenia. Dlatego nie są tworzone żadne gałęzie. Można bardziej ostrożnie rozwiązywać konflikty, a następnie sprawdzać, czy nie ma różnic w rozwiązywaniu konfliktów.

BTW, gałąź w gitarze to nazwa przyjazna człowiekowi, dla sha1 zatwierdzenia, więc nie bój się tworzyć ich tak dużo, jak chcesz.

PS: Jeśli pracujesz w systemie Windows, symbol w wierszu poleceń jest specjalny, musisz podwoić lub podać argumenty wiersza poleceń.

Powiązane problemy