байпас обхода для фиксации слияния

Я настраиваю некоторые git-крючки для запуска некоторых команд gulp на pre-commit. Я в основном работать jshint/plato. Я в основном хочу обойти их для двух случаев:

  1. ветки исправлений (мастер/исправление)
  2. git merge (или найти способ сделать это способом, который не сбой в случае слияния)

Команда plato gulp запускает анализ источника и создает каталог /reports/, который отслеживает сложность с течением времени. Если мы это сделаем на ветке исправления, это приведет к конфликтам слияния при объединении их в процесс разработки. Достаточно говорить здесь простой крючок:

#!/bin/sh

if git diff --cached --name-only --diff-filter=ACM | grep '.js$' >/dev/null 2>&1
then
  git stash -q --keep-index
  ./node_modules/.bin/gulp jshint
  RESULT=$?
  git stash pop -q
  [ $RESULT -ne 0 ] && exit 1
  git stash -q --keep-index
  ./node_modules/.bin/gulp plato
  git add report/
  git stash pop -q
fi

exit 0

Проблема прямо сейчас, если у меня конфликт слияния на "отчеты", и я разрешаю слияние. All conflicts fixed but you are still merging. а затем зафиксировать его снова и снова анализирует и ставит коммит, и когда он совершает ошибку, это вызывает ошибку:

/Users/Nix/work/project/.git/modules/somesubmodule/MERGE_HEAD 'для чтения: нет такого файла или каталога.

Каталог существует, но нет слияния...

Ответы

Ответ 1

Поэтому я просто нашел команду, которую, я думаю, могу использовать для обнаружения "merge_head",

 git rev-parse -q --verify MERGE_HEAD

Если rev-parse возвращает хэш, это означает, что мы в настоящее время находимся в состоянии слияния. Я могу использовать это, чтобы обойти эту логику. Но будет ждать лучшего совета от более опытных людей.

Ответ 2

Как упоминалось в этом связанном ответе, вы можете проверить наличие $GIT_DIR/MERGE_HEAD чтобы обнаружить коммит слияния:

Вот что вы получаете:

  • Если вы используете git commit --amend для изменения коммита слияния, ловушка перед фиксацией запускается как обычно, но она не может действительно обнаружить, что это происходит. Новый коммит будет слиянием, но вы не можете сказать.

  • Если вы используете обычный старый git commit для создания git commit без слияния, файл MERGE_HEAD не будет существовать в каталоге git, и вы можете сказать, что он не собирается создавать коммит слияния.

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

  • Если вы запустили git merge и он завершился успешно сам по себе, он делает новый коммит без использования ловушки pre-commit, поэтому вы даже не вызываетесь здесь.

Следовательно, если вы хотите разрешить git commit --amend при слияниях git commit --amend, вы можете приблизиться к тому, что вы хотите: просто проверьте наличие $GIT_DIR/MERGE_HEAD чтобы увидеть, $GIT_DIR/MERGE_HEAD ли это git commit конфликтующее слияние. (Использование $GIT_DIR - хитрость, чтобы заставить эту работу работать, даже если команды запускаются вне дерева git. Git устанавливает $GIT_DIR так, чтобы команды git, находящиеся в $GIT_DIR, работали правильно.)

Ответ 3

Бесстыдно приспособился от ОП здесь. До сих пор не тестировалось, но работало до сих пор.

Добавьте это в начало скрипта (или там, где вы считаете нужным). echo не требуется.

if [ -e "${GIT_DIR}/MERGE_MODE" ]
then
    echo "Merging, don't continue"
    exit 0
fi

... rest of the hook ...