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

Jestem w trakcie rebasingu po git pull --rebase. Mam kilka plików, które mają konflikty scalania. Jak mogę zaakceptować „ich” zmiany lub „moje” zmiany dla określonych plików?

$ 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

Zwykle po prostu otwieram plik lub narzędzie do scalania i ręcznie akceptuję wszystkie „ich” lub „moje” zmiany. Podejrzewam jednak, że brakuje mi wygodnego polecenia git.

Zauważ też, że będę mógł wybrać strategię scalania dla każdego pliku tylko wtedy, gdy zobaczę, które pliki uderzają w konflikty i być może takie są konflikty.

Dla każdego otrzymanego pliku będącego w konflikcie możesz określić

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

Z git checkoutdokumentów

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) pod kątem nie połączonych ścieżek.

Indeks może zawierać niepołączone wpisy z powodu poprzedniego nieudanego scalenia. Domyślnie, jeśli spróbujesz wyewidencjonować taki wpis z indeksu, operacja pobierania zakończy się niepowodzeniem i nic nie zostanie wyewidencjonowane. Użycie -fspowoduje zignorowanie tych niepołączonych wpisów. Zawartość z określonej strony scalania można sprawdzić w indeksie za pomocą --ourslub --theirs. Za pomocą -mzmian dokonanych w działającym pliku drzewa można odrzucić, aby odtworzyć oryginalny wynik scalenia będącego w konflikcie.

Pomimo odpowiedzi na to pytanie, stanowi przykład tego, co „ich” i „nasze” oznaczają w przypadku git rebase vs scalanie. Zobacz ten link

Git Rebase
theirs jest tak naprawdę aktualną gałęzią w przypadku rebase . Tak więc poniższy zestaw poleceń akceptuje bieżące zmiany gałęzi w oddziale zdalnym.

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

Git Merge
W przypadku scalania znaczenie theirsi oursjest odwrócone. Tak więc, aby uzyskać ten sam efekt podczas scalania , tzn. Zachowaj bieżące zmiany gałęzi ( ours) nad łączoną gałęzią zdalną ( theirs).

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

Zauważ, że git checkout --ours|--theirsbędzie nadpisać pliki całkowicie , wybierając albo theirsalboours wersja, która może być lub może nie być, co chcesz zrobić (jeśli masz jakiekolwiek zmiany nie kolidowały pochodzących z drugiej strony, zostaną one utracone).

Jeśli zamiast tego chcesz wykonać trzykrotne scalenie pliku i rozwiązywać tylko konfliktowe porcje za pomocą --ours|--theirs, zachowując bezkonfliktowe porcje po obu stronach, możesz skorzystać z git merge-file; zobacz szczegóły w tej odpowiedzi .