Для Git 2.6+ (выпущен 28 сентября 2015 г.)
только git config
интересующая настройка:
rebase.autoStash
(Git 2.27, Q2 2020, теперь у вас тоже есть merge.autostash
, см. ниже)
Если задано значение true, автоматически создавать временное хранилище перед началом операции и применять его после завершения операции.
Это означает, что вы можете запустить rebase на грязном рабочем дереве.
Однако используйте с осторожностью: последнее приложение тайника после успешной перебазировки может привести к нетривиальным конфликтам. По умолчанию - false.
объедините это с:
pull.rebase
Если установлено значение true, перебазировать ветки поверх выбранной ветки вместо слияния ветки по умолчанию с удаленного по умолчанию при запуске «git pull».
git config pull.rebase true
git config rebase.autoStash true
Этого хватило бы, чтобы простая git pull
работала даже на грязном дереве.
В этом случае псевдоним не нужен.
См. Commit 53c76dc (4 июля 2015 г.) Кевина Даудта ( Ikke
) .
(Объединено Junio C Hamano - gitster
- в фиксации e69b408 , 17 августа 2015 г.)
pull
: разрешить грязное дерево при rebase.autostash
включении
rebase научился прятать изменения, когда он встречает грязное дерево работы, но git pull --rebase
не делает этого.
Проверяйте, загрязнено ли рабочее дерево, только когда rebase.autostash
он не включен.
Примечание: если вы хотите тянуть без autostash (даже если rebase.autoStash true
он установлен), у вас с git 2.9 (июнь 2016 г.) есть:
pull --rebase --no-autostash
См. Фиксацию 450dd1d , фиксацию 1662297 , фиксацию 44a59ff , фиксацию 5c82bcd , фиксацию 6ddc97c , фиксацию eff960b , фиксацию efa195d (2 апреля 2016 г.) и фиксацию f66398e , фиксацию c48d73b (21 марта 2016 г.) Мехул Джайн ( mehul2029
) .
(Объединено Junio C Hamano - gitster
- в коммите 7c137bb , 13 апреля 2016 г.)
В частности, коммит f66398e включает:
pull --rebase
: добавить --[no-]autostash
флаг
Если rebase.autoStash
переменная конфигурации установлена, невозможно изменить ее для " git pull --rebase
" из командной строки.
Обучает " git pull --rebase
" --[no-]autostash
флаг командной строки, который отменяет текущее значение rebase.autoStash
, если он установлен. Как " git rebase
" понимает --[no-]autostash
опцию, это просто вопрос передачи опции базовому " git rebase
" при git pull --rebase
вызове "".
Предупреждение: до Git 2.14 (3 квартал 2017 г.) " git pull --rebase --autostash
" не сохранялась автоматически при быстрой пересылке локальной истории в вышестоящий.
См. Commit f15e7cf (01 июня 2017 г.) Тайлера Брейзера ( tylerbrazier
) .
(Объединено Junio C Hamano - gitster
- в коммите 35898ea , 5 июня 2017 г.)
pull
: ff --rebase --autostash
работает в грязном репо
Когда git pull --rebase --autostash
в грязном репозитории произошла перемотка вперед, ничего не сохранялось автоматически, и извлечение не удавалось.
Это произошло из-за ярлыка, позволяющего избежать выполнения перебазирования при быстрой перемотке вперед, но автостэш игнорируется в этом кодовом пути.
Обновление: Мариуш Павельски задает в комментариях интересный вопрос:
Итак, все пишут о том, autostash
когда вы делаете rebase (или pull --rebase
).
Но никто не думает об автостэшировании, когда вы делаете обычное извлечение со слиянием .
Значит, для этого нет автоматического переключателя? Или я чего-то упускаю? Я предпочитаю делать, git pull --rebase
но OP спросил о " стандартном " git pull
Ответ:
Исходный поток обсуждать эту autostash функцию, она была реализована изначально как для git pull
(слияния) и git pull --rebase
.
Но ... Junio C Hamano (сопровождающий Git) заметил, что:
Если бы это pull-merge
было что-то, что вызвало бы "раздражение", вызвавшее эту тему, по определению, локальное изменение перекрывается с объединением, и этот внутренний "всплывающий тайник" коснется путей, которых коснулось объединение, и, вероятно, не приведет к "Отброшено" "но оставьте дальнейшие конфликты для разрешения.
Я подозреваю, что pull.autostash
конфигурация не является хорошим дополнением, потому что она способствует плохому, мучительному рабочему процессу.
В простых случаях это может не повредить, но когда локальные изменения сложны, это будет активно вредить, чем его отсутствие, а конфигурация лишает стимула к выбору.
Уравнение для «pull-rebase» несколько иное, так как «rebase» настаивает на том, чтобы вы начали с чистого рабочего дерева, поэтому раздражение «скачать, а затем остановиться» кажется еще большим. У меня есть подозрение, что ослабление, которое может быть более продуктивным решением реальной проблемы.
Итак, что касается классического пул-слияния, лучше:
побудите пользователя подумать о характере незавершенного производства в рабочем дереве перед запуском " git pull
" .
Это слишком сложный зверь, который может мешать тому, что делают другие, или это банальное изменение, которое он может спрятать и вернуть обратно?
Если первое, ему будет гораздо лучше сделать " checkout -b
", продолжайте работать до тех пор, пока локальное изменение не приобретет несколько лучшую форму и не "зафиксирует", прежде чем переходить к исходной ветке.
В последнем случае ему лучше сделать:
- "
git pull
",
- обнаружив конфликт, запустите
git stash
,
git merge FETCH_HEAD
и
git stash pop
При этом с Git 2.27 (второй квартал 2020 г.) " git pull
" научился предупреждать, когда pull.rebase
конфигурация не существует, и ни одна из них --[no-]rebase
не --ff-only
задана (что приведет к слиянию).
См. Commit d18c950 (10 марта 2020 г.) от Alex Henrie ( alexhenrie
) .
(Объединено Junio C Hamano - gitster
- в коммите 1c56d6f , 27 марта 2020 г.)
pull
: предупреждать, если пользователь не сказал, перебазировать или объединить
Подписано: Алекс Хенри
Часто начинающие пользователи Git забывают сказать « pull --rebase
» и в конечном итоге получают ненужное слияние из восходящего потока.
Обычно они хотят либо " pull --rebase
" в более простых случаях, либо " pull --ff-only
" обновить копию основных ветвей интеграции и отдельно перенастроить свою работу. Переменная конфигурации существует , чтобы помочь им в более простых случаях, но не существует никакого механизма , чтобы эти пользователи знают об этом.
pull.rebase
Выдавать предупреждающее сообщение, если --[no-]rebase
в командной строке не pull.rebase
указаны параметры и переменная конфигурации.
Это доставит неудобства тем, кто никогда не хочет " pull --rebase
", кому не приходилось делать ничего особенного, но стоимость неудобств оплачивается только один раз на пользователя, что должно быть разумной стоимостью, чтобы помочь ряду новых пользователей.
В Git 2.27 (второй квартал 2020 г.) " git merge
" изучает параметр " --autostash
" и новый merge.autostash
параметр.
См совершать d9f15d3 , совершать f8a1785 , совершают a03b555 , совершают 804fe31 , совершают 12b6e13 , совершают 0dd562e , совершают 0816f1d , совершают 9bb3dea , совершают 4d4bc15 , совершают b309a97 , совершают f213f06 , совершают 86ed00a , совершают facca7f , совершают be1bb60 , совершают efcf6cf , совершают c20de8b , совершить bfa50c2 , фиксация 3442c3d , фиксация 5b2f6d9 (7 апреля 2020 г.), фиксация 65c425a(4 апреля 2020 г.) и фиксация fd6852c , фиксация 805d9ea (21 марта 2020 г.) Дентоном Лю ( Denton-L
) .
(Объединено Junio C Hamano - gitster
- в фиксации bf10200 , 29 апреля 2020 г.)
pull
: pass --autostash для слияния
Подписано: Дентон Лю
Раньше --autostash
работал только с git pull --rebase
.
Однако в последнем патче слияние --autostash
также изучалось, поэтому нет причин, по которым у нас больше нет этого ограничения.
Научите pull to pass --autostash
для слияния, как это было для rebase.
И:
rebase
: использовать apply_autostash()
из Sequencer.c
Подписано: Дентон Лю
apply_autostash()
Функция builtin/rebase.c
подобна достаточно , чтобы apply_autostash()
функции в sequencer.c
том , что они почти взаимозаменяемы, для типа Arg они принимают за исключением. Сделайте sequencer.c
версию extern и используйте ее в rebase.
Версия rebase была представлена в 6defce2b02 («builtin rebase: support --autostash
option», 2018-09-04, Git v2.20.0-rc0 - слияние указано в пакете №8 ) как часть преобразования оболочки в C.
Он решил продублировать функцию, потому что в то время был еще один незавершенный проект по преобразованию интерактивной перебазировки из оболочки в C, и они не хотели конфликтовать с ними из-за рефакторинга sequencer.c
версии apply_autostash()
.
Поскольку оба усилия уже давно сделаны, мы можем свободно объединить их вместе.