Wybierz strategię Git merge dla określonych plików ("nasze", "moje", " ich")

Jestem w trakcie rebasingu po git pull --rebase. Mam kilka plików z konfliktami scalającymi. Jak mogę zaakceptować "ich" 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

Normalnie po prostu otwieram plik lub narzędzie scalające i ręcznie akceptuję wszystkie" ich "lub" moje " zmiany. Jednak podejrzewam, że brakuje mi wygodnej komendy git.

Zauważ również, że będę mógł wybrać strategię scalania dla każdego pliku tylko wtedy, gdy zobaczę, jakie pliki trafiają w konflikty i prawdopodobnie jakie konflikty są.

Author: Steven Wexler, 2013-05-30
Source

3 answers

Dla każdego pliku, który otrzymujesz, możesz 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ź stage #2 (ours) lub #3 (theirs) dla niezerowanych ścieżek.

Indeks może zawierać niezerowane wpisy z powodu poprzedniego nieudanego scalenia. Domyślnie, jeśli spróbujesz sprawdzić taki wpis z indeksu, operacja kasowania zakończy się niepowodzeniem i nic nie zostanie sprawdzone. Użycie -f zignoruje te niezapisane wpisy. Zawartość z określonej strony scalenia można sprawdzić z indeksu za pomocą --ours lub --theirs. W przypadku -m zmiany wprowadzone w pliku drzewa roboczego mogą zostać odrzucone w celu odtworzenia oryginalnego wyniku scalenia wywołanego konfliktem.

 173
Author: ,
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
2013-05-30 00:21:47

Mimo że na to pytanie udzielono odpowiedzi, dając przykład co "ich " i" nasze " oznaczają w przypadku git rebase vs merge. Zobacz ten link

Git Rebase
theirs jest aktualną gałęzią w przypadku rebase. Tak więc poniższy zestaw komend akceptuje bieżące zmiany w gałęzi zdalnej.

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

Git Merge
Dla merge , znaczenie theirs i ours jest odwrócone. Więc, aby uzyskać ten sam efekt podczas merge , tzn. zachowaj bieżące zmiany gałęzi (ours) nad zdalną gałęzią, która jest scalana (theirs).

# assuming branch-a is our current version
$ git merge -X ours branch-b  # <- ours: branch-a, theirs: branch-b
 45
Author: Abe,
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-02-15 16:49:36

Zauważ, że git checkout --ours|--theirs nadpisze pliki całkowicie , wybierając wersję theirs lub ours, która może być lub nie być tym, co chcesz zrobić (jeśli masz jakieś niezakłócone zmiany pochodzące z drugiej strony, zostaną one utracone).

Jeśli zamiast tego chcesz wykonać trójstronne scalanie na pliku i rozwiązać tylko skonfliktowane fragmenty używając --ours|--theirs, podczas gdy zachowując niezakłócone fragmenty z obu stron, możesz skorzystać z git merge-file; Zobacz szczegóły w ta odpowiedź .

 9
Author: jakub.g,
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:34:29