Как вы проверяете код с разными комментариями к разным классам? - PullRequest
0 голосов
/ 10 июня 2009

Как вы думаете, что является лучшим методом проверки кода из нескольких файлов, в которых реализовано несколько изменений, но которые готовы войти одновременно?

Вы проверяете их все сразу, сохраняя проверку на атомарном уровне, и вносите изменения в один длинный комментарий?

Проверяете ли вы файлы в группах, чтобы правильный комментарий ассоциировался с нужным файлом?

Есть ли у вас инструменты, позволяющие регистрироваться сразу с разными комментариями к разным файлам?

Ответы [ 5 ]

1 голос
/ 10 июня 2009

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

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

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

1 голос
/ 10 июня 2009

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

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

1 голос
/ 10 июня 2009

Проверьте все сразу. Если вы регистрируетесь в группах, вы нарушаете сборку.

Но лучше зарегистрироваться, когда внесете изменения.

0 голосов
/ 10 июня 2009

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

0 голосов
/ 10 июня 2009

Я стараюсь, чтобы каждая регистрация была связана с определенным номером билета, проектом и т. Д.

...