Wybierz strategię scalania Git dla określonych plików ("nasz", "mój", "ich")

111

Jestem w trakcie reorganizacji po git pull --rebase. Mam kilka plików, które mają konflikty scalania. Jak mogę zaakceptować "swoje" zmiany lub "moje" zmiany dla określonych plików?Wybierz strategię scalania Git dla określonych plików ("nasz", "mój", "ich")

$ git status 
# Not currently on any branch. 
# You are currently rebasing. 
# (fix conflicts and then run "git rebase --continue") 
# (use "git rebase --skip" to skip this patch) 
# (use "git rebase --abort" to check out the original branch) 
# 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
#  modified: CorrectlyMergedFile 
# 
# Unmerged paths: 
# (use "git reset HEAD <file>..." to unstage) 
# (use "git add <file>..." to mark resolution) 
# 
#  both modified: FileWhereIWantToAcceptTheirChanges 
#  both modified: FileWhereIWantToAcceptMyChanges

Zazwyczaj otwieram plik lub narzędzie do scalania i ręcznie akceptuję wszystkie zmiany "ich" lub "moje". Podejrzewam jednak, że brakuje mi wygodnego polecenia git.

Należy również pamiętać, że będę mógł wybrać strategię scalania dla każdego pliku tylko wtedy, gdy zobaczę, jakie konflikty trafiają w pliki i jakie mogą być konflikty.

Źródło

2013-05-30 Steven Wexler

@AbeVoelker Nie sądzę, że rozwiązuje mój problem. Chcę wybrać strategię scalania dla określonych plików. Zauważ też, że wiem tylko, do czego użyć funkcji stragegy, gdy znajduję się w moim rebase i zobaczę, które pliki napotkały konflikty i jakie są konflikty. –

Zmieniłem to pytanie na bardziej ogólne: http://stackoverflow.com/questions/278081/resolving-a-git-conflict-with-binary-files. Może możemy zamknąć to pytanie jako duplikat tego? Czy to właściwe? –

@TheShadow Wydaje mi się to rozsądne. –

147

Dla każdego pliku skonfliktowanego masz, można określić

git checkout --ours -- <paths> 
# or 
git checkout --theirs -- <paths>

Z git checkout docs

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...

--ours
--theirs
Podczas sprawdzania ścieżek z indeksu, sprawdź etap # 2 (ours) lub # 3 (theirs) dla niezamkniętych ścieżek.

Indeks może zawierać niezmielone pozycje z powodu wcześniejszego nieudanego scalenia. Domyślnie, jeśli spróbujesz pobrać taki wpis z indeksu, operacja kasowania zakończy się niepowodzeniem i nic nie zostanie wyrejestrowane. Użycie -f zignoruje te niezajęte wpisy. Zawartość z określonej strony scalania może być sprawdzona z indeksu za pomocą --ours lub --theirs. Po wprowadzeniu -m zmiany wprowadzone w roboczym pliku drzewa można usunąć, aby ponownie utworzyć oryginalny wynik konfliktu.

Źródło

2013-05-30 00:21:47

Czy możliwe jest zaakceptowanie theires dla wszystkich plików, które pozostały umergowane? – aslakjo

+17

@aslakjo 'git rebase -s rekurencyjne -X ' lub 'git merge -s rekurencyjne -X '. Należy pamiętać, że w przypadku rebase "ours" i "theirs" są odwrócone od tego, co robią podczas scalania. Prawdopodobnie możesz również użyć globu pliku/powłoki, np. 'Git checkout --theirs - * .txt'. –

To polecenie nie działa, gdy wydaje się, że jest modułem podrzędnym. – user239558

Zauważ, że git checkout --ours|--theirs będzie nadpisać pliki całkowicie, wybierając opcję theirs lub ours wersję, która może być lub może nie być to, co chcesz zrobić (jeśli masz jakieś non-skonfliktowany zmian pochodzących od innych strony, zostaną utracone).

Jeśli zamiast tego chcesz wykonać trójdrożny scalić na pliku, a tylko rozwiązać skonfliktowany kromkami pomocą --ours|--theirs, natomiast utrzymanie non-skonfliktowany kromkami z obu stron w miejscu, można odwołać się do git merge-file; zobacz szczegóły w this answer.

Źródło

2016-08-25 09:11:10

Odnośnie do "zmian nie będących w sprzeczności", które zostaną utracone - dotyczy to tylko plików, w których występują niekonfliktowe zmiany w określonych liniach w innym miejscu, w tym samym pliku lub wszystkie zmiany ze wszystkich plików w wyrównanych historiach? – ktamlyn

Mimo odpowiedzi na to pytanie, podajemy przykład tego, co "ich" i "nasze" oznacza w przypadku git rebase vs merge. Zobacz this link

Git rebase
theirs jest rzeczywiście obecny oddział w przypadku rebase. Tak więc poniższy zestaw poleceń faktycznie akceptuje twoje bieżące zmiany gałęzi w zdalnym oddziale.

# see current branch 
$ git branch 
... 
* branch-a 
# rebase preferring current branch changes during conflicts 
$ git rebase -X theirs branch-b

GIT Scal
Na seryjnej, znaczenie theirs i ours jest odwrócona. Tak więc, aby uzyskać taki sam efekt podczas łączenia ,, tj. Zachowaj bieżące zmiany w gałęzi (ours) nad połączonym odgałęzieniem zdalnym (theirs).

# assuming branch-a is our current version 
$ git merge -X ours branch-b # <- ours: branch-a, theirs: branch-b

Źródło

2017-03-20 15:34:48 Abe

cóż, to dość ważne wyróżnienie! dzięki za wytłumaczenie. – verboze

Wybierz strategię scalania Git dla określonych plików ("nasz", "mój", "ich")

Odpowiedz

Powiązane problemy