Как определить, выполняется ли слияние Git

Ответ 1

Один трюк заключается в использовании команды Git, которая будет терпеть неудачу, если выполняется слияние. Затем вы можете проверить код возврата команды. Вы также захотите убедиться, что команда не повлияет на вашу рабочую копию или индекс в случае успеха. Хотя в эту категорию входит множество команд, подходящим является

git merge HEAD

который возвращает код 128, если выполняется слияние, но 0 в противном случае. Обратите внимание, что когда слияние не выполняется, эта команда будет просто печатать уже актуально, поскольку вы просто сливаетесь с самим собой. Итак, для сценариев вы можете сделать это (в BASH)

git merge HEAD &> /dev/null
result=$?
if [ $result -ne 0 ]
then
    echo "Merge in progress."
else
    echo "Merge not in progress."
fi

Обратите внимание, что даже с флагом --quiet git merge слияние в процессе все равно приведет к тому, что эта команда будет печататься в поток ошибок. Вот почему я перенаправляю свой вывод на /dev/null.

Ответ 2

Вы можете безопасно проверить наличие MERGE_HEAD в вашем каталоге git [1], чтобы определить, происходит ли слияние. Файл MERGE_HEAD содержит идентификаторы слияния, которые объединяются, которые будут n м родителем совершенного слияния. Например, если я попытаюсь объединить ветвь br1 которая находится в c085e0c:

> git merge --no-ff --no-commit br1
Automatic merge went well; stopping before committing as requested

> cat .git/MERGE_HEAD
c085e0caa2598064bfde9cc6318bd2c73fee2371

Если вы выполняете слияние с осьминогом, то в этом файле вы увидите более одного идентификатора коммита (разделены новой строкой):

> git merge --no-ff --no-commit br2 br3
Fast-forwarding to: br2
Trying simple merge with br3
Automatic merge went well; stopping before committing as requested

> cat .git/MERGE_HEAD
69b0169b1cba60de86161b375f013c59ad9581d8
99dad0187351d61ae8e88d49c96d7383f9e8fa6d

Использование MERGE_HEAD - это то, как git-клиенты определяют, происходит ли слияние. Некоторые предоставляют это понимание через неплотные абстракции:

> git merge --abort
fatal: There is no merge to abort (MERGE_HEAD missing).

Таким образом, проверка на наличие MERGE_HEAD вполне приемлема и является такой же будущей проверкой, как и все в программном обеспечении. Это означает, что любые изменения в git-merge должны учитывать совместимость с другими git-клиентами и (надеюсь!) Изящно переходить и/или обеспечить обратную совместимость.

[1] Вы можете доверять существованию MERGE_HEAD гораздо больше, чем можете доверять тому, что .git находится в вашем рабочем каталоге. Кто-нибудь может использовать флаг --git-dir или переменную среды GIT_DIR.

Ответ 3

вы можете запустить git status

git расскажет вам, что происходит в вашем репозитории.

например.  * конфликтующие файлы (несвязанные файлы)

Ответ 4

Другой вариант - проверить наличие файла .git/MERGE_MSG.

Это потому, что до 2.14.x/2.15 (Q3 2017) вы можете оказаться в ситуации, когда у вас нет .git/MERGE_HEAD, даже если выполняется слияние.

См. commit 9d89b35, зафиксировать 8e6a6bb, commit 62dc42b (23 августа 2017 г.) и commit e2de82f (21 августа 2017 г.) Майкл Дж Грубер (mjg).
^{(слияние Junio ​​C Hamano - gitster - в совершить 6e6ba65, 27 августа 2017 г.}

Убийство "git merge --edit" перед тем, как редактор вернет управление влево репозиторий в состоянии с MERGE_MSG, но без MERGE_HEAD, который неправильно сообщает последующему "git commit", что происходит слияние сквоша.
Это было исправлено.

После Git 2.14.x/2.15 этого больше не будет, и тестирования для .git/MERGE_HEAD будет достаточно.

Ответ 5

Поскольку MERGE_HEAD доступен только во время слияния и также предназначен для будущего, мы можем просто использовать git rev-list -1 MERGE_HEAD (удобно, сантехническую команду), который завершится с кодом 128, если MERGE_HEAD не найден. Для проверки чистоты передайте stdout и stderr в /dev/null. Или, что еще лучше, используйте git rev-parse -q --verify MERGE_HEAD.