Git оформить заказ и слить, не касаясь рабочего дерева

Question

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

git branch feature1
... [edit my code]
... [commit]
git fetch origin master
git merge fetch_head [or rebase]
... [resolve conflicts]
... [build and test code]

На данный момент я хочу внести свои изменения. Обычный способ сделать это будет:

git checkout master [changes a bunch of working tree files]
git merge feature1  [changes the same files right back]

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

Что-то вроде:

git checkout master --merge-branch feature1

EDIT:

Я говорю только об ускоренных слияниях, которые по определению не изменят состояние файлов.

Answer 1

Простой и безопасный способ сделать это - без принудительного или принудительного обновления - это загрузить feature1 в master:

(feature1)$ git fetch . feature1:master
From .
   4a6000d..8675309  feature1   -> master

Трюк использует ., чтобы получить local feature1 ref. Это безопаснее, чем принудительное обновление главной ветки, так как оно обеспечивает ускоренное обновление. (Подробнее см. Параметр в документации git-fetch .)

Теперь, когда feature1 и master совпадают, переключение между ними не затронет ни одного файла:

(feature1)$ git checkout master
Switched to branch 'master'
(master)$

Answer 2

[Редактировать] Это только частичное решение / обходной путь. См. Фактический ответ по @djpohly ниже.

Во-первых, вы можете нажать откуда угодно. Неважно, что вы извлекли, или коммиты, которые вы хотите нажать, находятся в master.

git push REMOTE_REPO feature1:master

см. git help push

Подсказка: git push remoteRepo localRef:remoteRef

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

# (while still on feature1 branch)
git checkout -B master origin/master

Но это делает полный сброс на мастере. т.е. он не проверяет перемотку вперед.

Answer 3

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

У вас всегда может быть другой клон (возможно, с помощью альтернативы или каталога объектов с символическими ссылками для экономии места на диске) или другой рабочий каталог с contrib/workdir/git-new-workdir. Или используйте инструмент, такой как ccache .

Answer 4

Если вы заботитесь только о нескольких файлах и используете Unix, вы можете вручную изменить mtime после факта, используя touch -d <timestamp>. Убедитесь, что вы используете ls --full-time для получения метки времени, так как отображение по умолчанию не имеет точности.

Например, представьте, что вы используете Docker для создания образа для веб-приложения на основе Python. Если файл requirements.txt изменится, потребуется много времени для его восстановления, поскольку он должен загрузить кучу сторонних библиотек и скомпилировать их. Просто сбросьте mtime этого файла после слияния:

ls -og --full-time src/requirements.txt
# -rw-r--r-- 1 282 2015-11-04 20:03:28.918979065 +0400 src/requirements.txt

git checkout master
git merge --no-ff feature-foo

touch src/requirements.txt -d "2015-11-04 20:03:28.918979065 +0400"