Предотвратить git pull от изменения файла, если есть конфликт?

Question

Когда я запускаю git pull и возникает конфликт, git вставляет «маркеры конфликта» в мой файл и устанавливает для состояния файла какое-то ожидание слияния или какое-то подобное.Лично я нахожу это действительно раздражающим, поскольку у меня есть доступ к намного лучшим способам разрешения конфликтов, чем попытка декодировать то, что, по его мнению, было слиянием, из простого текстового файла.

Есть ли способ предотвратить создание этих маркеров в git?В частности, я хочу, чтобы все команды, включая git pull, ничего не делали, если возникнет конфликт, независимо от того, в каком состоянии начинаются события.

По сути, я ищу изменение вКонфигурация мерзавцаИзменение в моем рабочем процессе (например, «всегда фиксировать перед извлечением») - это не то, что я ищу.

В идеале, я бы хотел, чтобы он абсолютно ничего не делал с моими локальными файлами, если он не может этого сделать.идеально чистое слияние, но вместо этого просто распечатайте ошибку и скажите мне исправить ее самостоятельно.

Answer 1

Обычный рабочий процесс в git - это вызов git mergtool после сбоя слияния.Mergetool может быть вызван с любой программой, которая вам нравится: kdiff3, bcompare, p4merge по команде:

git mergetool [--tool=<tool>]. 

Вы даже можете использовать какой-нибудь пользовательский инструмент.Для установки по умолчанию mergetool

 git config --global merge.tool [tool]

Считайте там о настройке.

Answer 2

Есть несколько способов справиться с этим.

Сначала нужно привыкнуть к этому.Это стандартные маркеры конфликта, используемые большинством инструментов слияния.Вы будете часто их видеть.

[Я хочу разрешить конфликт] с помощью редактора, который я уже открыл в другом окне

Хороший редактор увидит, когда файл был изменен на диске, и покажет вам конфликтующую версию.Если ваш редактор этого не делает, возможно, это вариант конфигурации или пришло время для нового редактора, который лучше понимает файловую систему.Многие редакторы понимают эти маркеры и предоставят окраску синтаксиса и другую помощь. Atom , например, делает все это из коробки.

Если есть инструмент слияния, который вы предпочитаете, вы можетеиспользуйте это, настроив и запустив git mergetool в случае конфликта.Git запустит ваш настроенный инструмент слияния, и вы сможете использовать его для разрешения конфликта.Это включает в себя открытие файлов в вашем редакторе.

Если нет существующего адаптера mergetool, который делает то, что вы хотите, вы можете написать его.Посмотрите, например, vimdiff, а также этот ответ, демонстрирующий написание собственного инструмента слияния .

---

Тогда есть различные способы избежать конфликтовво-первых, на git pull.

Не нужно совершать коммитов на master.Вместо этого делайте всю свою работу в тематических ветвях.Это ветки, которые вы создаете для работы с одной функцией или ошибкой.Даже простые.Они изолируют вашу работу от всех остальных, пока вы не закончите.Работайте в ветке, пока функция не будет завершена.

# After `git checkout -b feature` and some commits.
          [origin/master]
A - B - C [master]
         \
          D - E - F [feature]

Тем временем вы можете git pull на master обновлять так часто, как вам нравится.Без локальных изменений не будет никаких конфликтов.

# After `git pull` on `master` to get other's work.
                  [origin/master]
A - B - C - G - H [master]
         \
          D - E - F [feature]

Вы можете обновлять свою ветку функций с помощью последних работ других людей с помощью git rebase master, чтобы воспроизвести вашу работу поверх master.Использование rebase вместо merge позволяет избежать ненужных слияний, которые просто ведут учет, и упрощает историю.

# After `git rebase master`
                  [origin/master]
A - B - C - G - H [master]
                 \
                  D1 - E1 - F1 [feature]

Когда вы закончите работу в feature, обновите master в последний раз, объединитесь в вашей ветви функций и нажмите master.Используйте git merge --no-ff feature, чтобы сохранить существование ветви функции для будущей археологии.

# After `git merge --no-ff feature`
                 [origin/master]
A - B - C - G - H ------------- I [master]
                 \            /
                  D1 - E1 - F1 [feature]

# After `git push`
                                  [origin/master]
A - B - C - G - H ------------- I [master]
                 \            /
                  D1 - E1 - F1 [feature]

Затем удалите ветку.Топография истории сохранит свое существование.Это поможет будущим археологам кода понять ваш код, показывая, какие коммиты были сгруппированы в единую функцию.

                                  [origin/master]
A - B - C - G - H ------------- I [master]
                 \            /
                  D1 - E1 - F1

---

Наконец, если вы действительно хотите сделать это по-своемуВы можете использовать git checkout --ours, чтобы оформить чистую версию.Это "наше", потому что когда вы git pull, вы действительно делаете git fetch + git merge origin/master.master - это «наше», а origin/master - «их».

Я не рекомендую это делать, так как теперь вам нужно вручную выполнить слияние, победив суть использования инструмента слияния.С большой вероятностью вы допустите ошибку, вызвав еще больше конфликтов.