Принято применение стандартов кода в git до фиксации

Question

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

Хотя спецификации довольно строгие (например, мы не переключаемся на окна или подрывную деятельность), это проблема реального мира, поэтому существует определенная гибкость, если у вас есть решение, которое почти подходит.

• Мы используем Git и * nix.
• Обновленный код должен быть отправлен на другой сервер для запуска набора тестов.
• Необходимо предоставить список модифицированных файлов, чтобы убедиться, что они соответствуют стандарту кодирования.
• Его довольно большая база кода, поэтому мы должны отправить наименьший объем информации, необходимой для обеспечения идентичных копий кодовой базы.
• Если тесты не выдаются, сообщение должно быть отображено с ошибкой, и фиксация должна быть заблокирована.
• Предположим, мы доверяем нашей команде разработчиков, и все в порядке, чтобы тесты можно было обойти с помощью опции --no-verify.

Вопрос: Что является лучшим способом, чтобы получить тестовый сервер для синхронизации с местной средой для запуска тестов? Какой-то хэш-хэш-код, соответствующий патчу git для нового коммита? Пропустить Git вообще и просто сделать rsync? Что-то еще?

Обновление 8/7/13: Я выстрелил себе в ногу, даже упомянув дистанционное репо. Дело в том, что нельзя блокировать код, который будет перенаправлен на общий/удаленный репо, для предотвращения локального коммита. Независимо от того, считается ли это лучшей практикой, дело не в этом, так как это характерно для небольшой группы разработчиков, которым всем нужна эта точная функциональность. Речь идет о лучшем способе достижения цели.

Answer 1

Добавить команду заказ GIT, который:

1. Временно делает совершить
2. толкает его на удаленный сервер
3. запуск тестов (с использованием сервера CI, post-receive крюк или 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. Если тесты пройдут, код останется зафиксированным. Если тесты потерпят неудачу, это будет так, как будто это никогда не было совершено.

Answer 2

Локальные фиксации, безусловно, не то, что вы хотите здесь.

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

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

Continuous integration with Git

Также проверьте Дженкинс, gitlab и т.д ...

---

Update после 8/7/13:

Так что вы действительно хотите сделать некоторые 'тесты' на удаленный сервер для предотвращения коммитов. Если вы хотите предотвратить на основе содержимого самого коммита, используйте крюк pre-commit.See this question for how to get a list of changed files. После того, как у вас есть эти измененные файлы, вы можете отправить их на удаленный сервер с помощью scp или rsync и запустить тестовую команду с помощью ssh.

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

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

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

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

Answer 3

Короткий ответ:

НЕ

---

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

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

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

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

Не выполняйте ничего при совершении локального коммита.

Answer 4

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

Answer 5

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

Answer 6

Написать Makefile, что:

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

2. Находит выход модульных испытаний.

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

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

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

Edit:

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