Автоматический git commit между шагами Red, Green и Refactor? - PullRequest
6 голосов
/ 15 августа 2011

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

Мне просто интересно, кто-нибудь еще пробовал это раньше?Я думал, что однажды прочитал об этом, но не могу найти никаких ссылок.

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

Я собирался реализовать это какПлагин guard , чтобы при сохранении файла спецификации или библиотеки он запускал спецификации и фиксировал изменения с сообщением о фиксации, например:

Green: 1621 examples, 0 failures, 2 pending (1659 tests/s, 0.0006 p/test)

Идея заключалась в том, что я мог визуально сканироватьэто при раздавливании и определении, где сгруппировать соответствующие коммиты Red / Green / Refactor с помощью логических изменений.

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

Ответы [ 4 ]

1 голос
/ 17 августа 2011

Мне это нравится, и я обдумывал это сам раз или два.Я не уверен, что я полностью вижу ценность этого все же.С первого взгляда я подумал, что будет легко вернуться к моему последнему известному зеленому состоянию.После просмотра JUnitMax в него встроена функциональность «вернуться к зеленому», поэтому с тех пор я не чувствовал желания автоматически фиксировать.

1 голос
/ 15 августа 2011

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

1 голос
/ 16 августа 2011

Вау !! Хотите верьте, хотите нет, но несколько дней назад у меня была похожая идея (для работы в качестве проекта выходного дня), когда я читал о модульном тестировании, что я хотел создать модуль для git, выполняющий аналогичные действия.

Моя идея была не полностью автоматизирована, а скорее частью. Например, пользовательская фиксация увидит, что такое RED, и даст им некоторый идентификатор, а затем GREEN увидит, что все RED решает, и добавит соответствующий комментарий в сообщение фиксации вместе с идентификатором теста и фиксациями RED.

Некоторые дополнительные функции могут включать просмотр этих коммитов на основе некоторых критериев ...

В любом случае, если вы найдете ссылку, о которой говорите, обновите эту ветку.

1 голос
/ 15 августа 2011

Мне нравится идея.

Показ новой / обновленной спецификации может быть плюсом. :)

Плагину может быть сложно узнать, когда код достиг «истинного» красного / зеленого состояния.

Будет ли это:

  • фиксирует --amend 'Red', когда спецификации не передаются и никакие файлы, кроме файлов 'spec', не изменяются?
  • после этого фиксирует 'Green', как только спецификации проходят из-за обновления в lib?
...