Каков хороший рабочий процесс git для TDD?

Я не уверен, что это репрезентативно, но, как один разработчик, я использую git-flow и вот (примерно) мой рабочий процесс для новой функции:

• Создать ветку функции
• Напишите неудачный приемочный тест высокого уровня (огурец), который завершился неудачно с тегом @wip (в процессе), чтобы его пока не использовали в тестовом наборе, и зафиксируйте его в новой ветке.
• (Иногда) напишите тест запроса rspec для интеграционного тестирования крайних случаев и зафиксируйте его в ветке функций
• Напишите тесты нижнего уровня (rspec / jasmine) для отдельных компонентов функции, и для каждой примерно определенной «единицы» выполните фиксацию в ветви функции.
• Когда функция завершена достаточно, чтобы пройти приемочный тест, удалите тег @wip, убедитесь, что он прошел, и зафиксируйте его в ветке функции.
• Объедините ветку функций с веткой разработки, используя git merge (а не git flow finish). Это оставляет ветку функции там, поэтому я могу обновить эту функцию позже, если это будет необходимо.
• Как только ветка объединяется для разработки, travis-ci запускает на ней полный набор тестов, и если есть какие-то проблемы, я получаю электронное письмо. (Я включаю в свой файл .travis.yml только ветки development и master.)

Я должен сказать, что это мой "идеальный" рабочий процесс - на практике я часто нарушаю эти правила: фиксирую непроверенные изменения перед написанием теста, начинаю работать над частями функции, прежде чем фактически конкретизировать приемочный тест высокого уровня, и т. д. Я, по сути, единственный, кто принимает участие в проекте, поэтому у меня есть свобода делать это; Если вы работаете в большой группе, я думаю, вам придется строже придерживаться того рабочего процесса, который у вас есть.

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

ОБНОВЛЕНИЕ:

После того, как я написал это, я понял, что есть один смысл, в котором я отклоняюсь от вышеупомянутого потока, а именно, когда я добавляю «функции», которые, строго говоря, не являются обычным ориентированным на пользователя типом (т.е. не то, что пользователь мог бы знать из). Например, на раннем этапе разработки приложения мы решили, что хотим использовать backbone.js для структурирования нашего js-кода, поэтому я создал для него функциональную ветку и добавил теги @javascript к различным существующим функциям огурца. Я слил его обратно, как только ветка примерно могла делать (с backbone.js) то, что исходное приложение делало с HTML-представлениями.

Я также планирую перейти на использование require.js, и в этом случае я также создам ветку функций для этого, и как только это будет сделано, объединю ее обратно. Для него не будет никакого интеграционного теста высокого уровня - пока пройдут существующие тесты, все в порядке.

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

• Либо Красный -> Зеленый -> Рефакторинг -> Фиксация
• или Красный -> Зеленый -> Фиксация -> Рефакторинг -> Фиксация

Мой рабочий процесс очень похож, но я думаю о том, чтобы лучше использовать рабочую область.

1. Напишите тест, git add.
2. Тест может выдавать ошибки из-за несуществующих интерфейсов, исправьте это, git add.
3. Сделайте тестовый проход (пока только неудачный), git commit.
4. Рефакторинг, git commit изменить.
5. Перейти 1.

Это обеспечивает соблюдение дисциплины, что при каждой фиксации все тесты проходят. На этапах 1-3 я могу в любой момент вернуться к последнему git add с помощью git checkout.

Самый простой способ подумать, когда вам следует совершить коммит:

1. Могу ли я описать то, что я совершаю, с помощью сообщения о фиксации, которое имеет смысл?
2. Есть ли какие-либо причины, по которым я мог бы захотеть вернуться к этому моменту или отличаться от этого момента?

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

Еще одна альтернатива, если вы действительно не чувствуете, что шаг требует долгосрочной фиксации, - просто выполнить git add. Таким образом, git diff покажет вам, что изменилось с момента добавления, а git diff --cached покажет вам, что изменилось раньше. Я так и делаю, потому что предпочитаю, чтобы мои коммиты были компилируемыми и проходили модульные тесты. Таким образом, легко вернуться в заведомо исправное состояние.

Я не верю, что существует рабочий процесс фиксации, специфичный для TDD, единственное правило, которое я стараюсь соблюдать, связано с тем, что я стараюсь не отправлять коммиты с неработающими тестами в основную ветку (если она еще не сломана). В моих функциональных ветках обычно тестируются только тесты, связанные с функциями, но все тесты будут проверяться при выполнении обратного слияния в master. Если я знаю, что фиксация действительно оставляет некоторые функциональные тесты неработающими или по какой-либо другой причине, по которой это происходит, только тогда я буду указывать это как wip. С более практической стороны, я думаю, что больше пользы будет в том, чтобы проявлять особую осторожность, чтобы не помещать коммиты в неправильные ветки.