Популярные Настройки Git Config. Начало
Джулия Эванс спросила у коллег-программистов мнения о самых популярных и полезных настройках Git, которые они используют. Вот такой список получился.
Описание всех настроек можно найти в документации Git.
1. pull.ff only или pull.rebase true
Эти две были самыми популярными. Обе они преследуют схожие цели: избежать случайного создания коммита слияния при запуске
git pull на ветке, где восходящая ветвь расходится.- pull.rebase true эквивалентен запуску
git pull --rebase каждый раз,- pull.ff only эквивалентен запуску
git pull --ff-only каждый раз.Скорее всего, нет смысла устанавливать обе одновременно, поскольку
--ff-only переопределяет --rebase.2. merge.conflictstyle zdiff3
Делаем конфликты слияний более читабельными!
По умолчанию в git конфликты слияния выглядят так:
<<<<<<< HEAD
def parse(input):
return input.split("\n")
=======
def parse(text):
return text.split("\n\n")
>>>>>>> somebranch
Вам предлагается решить, что лучше:
input.split("\n") или text.split("\n\n"). Но как? Что делать, если вы не помните, нужно \n или \n\n?Вот как выглядит тот же конфликт слияния с merge.conflictstyle diff3:
<<<<<<< HEAD
def parse(input):
return input.split("\n")
||||||| base
def parse(input):
return input.split("\n\n")
=======
def parse(text):
return text.split("\n\n")
>>>>>>> somebranch
Здесь содержится дополнительная информация: теперь исходная версия кода находится посередине! Итак, мы видим:
- одна сторона изменила
\n\n на \n,- другая сторона переименовала
input в text.Поэтому, по-видимому, правильным решением конфликта слияния является
return text.split("\n"), поскольку он объединяет изменения с обеих сторон.zdiff3 — это тот же diff3, но он лучше выносит любые общие строки в начале или конце за пределы зоны конфликта. То есть, если обе стороны сделали изменения, которые имеют общие строки в начале или в конце, то они будут корректно слиты и не будут входить в зону конфликта.
3. rebase.autosquash true
Цель autosquash — упростить модификацию старых коммитов. Допустим, у вас есть коммит с исправлением другого коммита (3 коммита назад), который вы хотели бы объединить с ним. Вы фиксируете новый коммит с помощью
git commit --fixup OLD_COMMIT_ID, что даёт новому коммиту сообщение «fixup! …».Теперь, когда вы запускаете
git rebase --autosquash main, он автоматически объединяет все коммиты-исправления (fixup!) со своими целями.rebase.autosquash true означает, что
--autosquash всегда автоматически передаётся в git rebase.4. rebase.autostash true
Это автоматически запускает
git stash перед git rebase и git stash pop после. По сути, он передаёт --autostash в git rebase. Это означает, что вы можете запустить rebase на «грязном» рабочем дереве. Однако будьте осторожны: применение изменений из stash после успешного перебазирования может привести к нетривиальным конфликтам. Хотя, похоже, это не очень часто встречается у людей, поскольку этот вариант конфигурации кажется действительно популярным.Продолжение следует…
Источник: https://jvns.ca/blog/2024/02/16/popular-git-config-options/