Добавьте настраиваемую команду git, которая:

1. Временно делает фиксацию
2. Отправляет его на удаленный сервер
3. Запускает тесты (используя CI-сервер, post-receive hook или ssh)
4. Отменяет фиксацию, если тесты терпят неудачу

Создайте исполняемый файл с именем git-test-n-commit и поместите его на свой путь:

#!/bin/bash
echo "Committing results..."
git commit "$@"
echo "Pushing to remote testing server..."
git push remote-server-git-url remote-branch -f
echo "Running tests"
ssh remote-server 'cd my_repo; run-my-tests' || 
   (echo "Tests failed, undoing commit" && git reset HEAD^)

Тогда вместо вызова git commit ARGS разработчики могут вызвать git test-n-commit ARGS. Если тесты пройдут успешно, код останется зафиксированным. Если тесты не пройдут, это будет так, как будто это никогда не было зафиксировано.

Short answer:

НЕ

Длинный ответ:

Невозможность выполнить фиксацию из-за каких-то странных локальных хуков кажется мне странной: вы должны отделить фиксацию (т.е. сохранение ваших изменений) от публикации этой фиксации.

Хотя совершенно разумно иметь pre-receive хук на сервере git, о котором вы говорите, который обеспечивает соблюдение ваших правил, это будет драматично для репозиториев ваших разработчиков: каждый раз, когда они хотят сохранить свою работу, попробовать что-то новое или что-то еще, они сначала должны отполировать свой код, прежде чем они смогут выполнить фиксацию.

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

Не применяйте никаких принудительных мер при выполнении локального коммита.

Локальные перехватчики фиксации определенно не то, что вам нужно.

Ваше требование о том, что «у нас нет доступа для изменения сервера git, поэтому это должно быть сделано с использованием локального перехватчика фиксации на каждой машине разработчика», является полностью подделкой. Вы всегда можете настроить другой репозиторий, который будет вашим «тестовым пультом», над которым у вас есть полный контроль (который затем будет синхронизироваться с сервером git, который вы не контролируете).

Настроив этот тестовый пульт, вы можете добавить хуки для запуска тестов при любом нажатии. Попытки набрать git push test-remote my-branch для получения результатов тестирования минимальны.

Непрерывная интеграция с Git

Также посмотрите Jenkins, gitlab и т. Д.

Обновление после 07.08.13:

Итак, вы действительно хотите провести некоторые «тесты» на удаленном сервере, чтобы предотвратить коммиты. Если вы хотите предотвратить, основываясь на содержимом самого коммита, используйте ловушку pre-commit. См. этот вопрос, чтобы узнать, как получить список измененных файлов. Один раз. у вас есть эти измененные файлы, вы можете передать их на удаленный сервер с помощью scp или rsync и запустить тестовую команду с ssh.

Если вам нужно проверить сообщение фиксации, используйте ловушку commit-msg.

Вот хороший учебник по хукам: http://git-scm.com/book/en/Customizing-Git-Git-Hooks

Также упоминается несколько причин, по которым это может быть плохой идеей.

Они часто используются для обеспечения соблюдения определенных политик, хотя важно отметить, что эти скрипты не передаются во время клонирования. Вы можете принудительно применить политику на стороне сервера, чтобы отклонять отправку коммитов, которые не соответствуют какой-либо политике, но использование этих скриптов на стороне клиента полностью зависит от разработчика. Итак, это сценарии в помощь разработчикам, и они должны быть настроены и поддерживаться ими, хотя они могут быть переопределены или изменены ими в любое время.

Я думаю, что лучший подход, который я видел, - это git + gerrit + jenkins. Gerrit вводит понятие набора изменений. Плагин jenkins gerrit может создавать каждый опубликованный набор изменений (запускать любые тесты, которые вы хотите) и отмечать их как «проверенные», после чего проверенный набор изменений можно объединить в основную ветку. Если сборка набора изменений не удалась, коммиттер получает уведомление по электронной почте, после чего он может изменить фиксацию и обновить набор изменений.

После настройки промежуточного сервера, как предлагали другие, установите pre-receive соединение для запуска сценария над входящей фиксацией и нормализации его в соответствии с вашими стандартами кодирования. Часто стандарты кодирования определяются компьютерными правилами. Не заставляйте своих разработчиков постоянно настраивать пробелы, когда простой сценарий bash или что-то еще может сделать это за них. И если у вас есть сценарий для этого, зачем заставлять разработчика запускать его вручную, если он может запускаться автоматически на каждом push промежуточном репозитории.

Напишите Makefile, который:

1. Копирует текущие файлы на тестовый сервер.

2. Находит результат модульных тестов.

2.1. Если аномалий нет, запустите git commit.

2.2 Если есть аномалии, повторите ошибку.

Использование Makefiles для компиляции и коммитов было настоящей находкой. Я могу автоматизировать сложное форматирование и очистку файлов перед фиксацией.

Редактировать:

Конечно, Makefiles - не единственное, что вы можете делать. Ant / Bash / другие языки сценариев могут сделать это за вас.