Когда совершать код?

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

Итак, вопрос в том, когда действительно сделать коммит в хранилище, чтобы коммит был оправданным?

Как дополнение: это правильная практика для измерения развития проекта на основе его коммитов?

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

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

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

Это также зависит от системы SCM, которую вы используете. Распределенные системы обычно делают слияние и разветвление безболезненными и быстрыми, и вы можете выполнять их локально; это означает, что вы должны совершать много, и вставлять / объединять, когда вы проделали значительную работу. В централизованных системах, таких как svn или cvs, фиксация затрат обходится дороже и влияет на всех. Ветвление частично решает эту проблему, но поскольку это происходит на сервере, оно может быть мучительно медленным, а объединение может быть громоздким. Так что с централизованными SCM часто существует более осторожная культура, когда вы делаете обязательства только после того, как проделали значительный объем работы.

Что касается дополнения: Пожалуйста, пожалуйста, не делайте этого. Строки кода, количество коммитов, количество найденных / исправленных ошибок и т. Д. - все это очень плохие показатели качества или даже количества.

Если вы используете DVCS, например Mercurial или Git, вы должны фиксировать свой локальный репозиторий всякий раз, когда вы проделали значительный объем работы. Тем не менее, отправляйте его в общий репозиторий только после того, как оно заработало, было проведено автономное изменение, которое было протестировано.

Для нераспределенных VCS (таких как, например, SVN) применяется та же логика, вместо локального репозитория используйте приватную ветвь, а не push-merge к основной ветке.

Вы должны совершать рано и часто.

Я знаю людей, которые совершают так часто, как каждые 90 секунд. Шутки в сторону. Кажется, работает на них. Я экспериментировал с фиксацией каждый раз, когда сохраняю файл, что, вероятно, чаще, чем 90 секунд. Сегодня я, вероятно, совершаю примерно каждые 15 минут. VCS, который позволяет вам объединять несколько коммитов в один и который позволяет локальные коммиты (например, git), делает это намного проще.

Как часто вы должны совершать? Трудно сказать, но, вероятно, чаще, чем вы сейчас. Продолжайте совершать все чаще и чаще, находите точку, которая кажется абсурдной слишком часто, и затем отступайте немного. Скорее всего, вы получите что-то разумное.

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

Коммиты являются строительными блоками любых данных / кода, контролируемых версией. Каждый коммит должен выполнять одно из следующих действий:

• Добавить новый фрагмент данных или функцию
• Исправьте одну или несколько ошибок (один коммит для каждого исправления, если это возможно), где исправление может быть:
  • Улучшение производительности
  • Исправление неправильного поведения кода
  • Удаление типографских ошибок
• Рефакторинг кода или данных без изменения семантики. Это включает в себя:
  • Переписывающий код, который ведет себя идентично оригиналу
  • Изменение представления данных в другой формат
  • Форматирование кода или данных в соответствии с рекомендациями по форматированию проекта
• Объединить изменения из другой ветви (восходящий / нисходящий)

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

Если коммиттеры следуют вышеуказанному правилу, становится тривиально:

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

Что касается измерения прогресса проекта на основе коммитов, то это возможно, если рефакторинг коммитов и коммитов исправления ошибок не будут приняты во внимание.

Принимайте меры только тогда, когда вы успешно проверили модулем данную функцию / модуль / функциональность, и вы разумно уверены, что она готова к интеграции или системному тестированию.

И ответить на ваши дополнительные вопросы - НЕТ !! мера того, где находится проект, никогда не должна определяться количеством коммитов ... кто знает, что на самом деле было совершено? Был ли он успешно протестирован системой или даже модульным. То, что оно совершено, не означает, что оно готово к производству.

Как дополнение: это правильная практика для измерения развития проекта на основе его коммитов?

Нет. Был ежедневный WTF о том, почему это ужасная идея.

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

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

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

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

Как только соответствующее задание выполнено . Задача является частью пользовательской истории .

Задача выполняется в следующих случаях:

• соответствующий блок тестов пройден,
• код правильно документирован и
• Код передан.

Вы можете иметь другое определение сделано .

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

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

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

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

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

Вот как это работает с Git, но принцип относится к любому контролю версий.

Когда:

• это строит (ВСЕГДА)
• модульные тесты проходят
• это работает (если только оно не помечено как "работа в процессе")
• Преимущества сохранения состояния кода перевешивают трудности, связанные с выполнением тестов, продумывая хорошее сообщение о коммите и разрешая любые конфликты слияния во время процесса фиксации.