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

59

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

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

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

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

Ответы:

79

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

Нил Баттерворт
источник
10
Я согласен с дополнением, что багажник - это отдельная история. Например, чтобы проверить сундук моей команды, он должен: а) правильно построить и б) что-то завершить. Любой член команды может создать ветку, и он может находиться в том состоянии, в котором он хочет.
Эдвард Стрендж,
34

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

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

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

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

tdammers
источник
Я предполагаю, что то же самое относится и к новым ветвям, где все новые разработки передаются в вашу собственную ветку, которую вы затем подтолкнете, когда функция будет готова? То есть. Вы можете отправить даже много неполного кода в свою частную ветку.
Юха Унтинен,
Да, но в меньшей степени, потому что (см. Оригинальный ответ) вы никому не будете мешать напрямую. В зависимости от рассматриваемого SCM, обычно считается хорошей практикой очистить историю коммитов перед слиянием в апстрим (например git rebase -i).
tdammers
13

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

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

Vartec
источник
+1 Поражен, за это больше не проголосовали. Это была моя первая мысль - dvcs или vcs
Майкл Даррант
9

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

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

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

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

Рейн Хенрикс
источник
1
+1. Когда вы комбинируете BDD-As-If-You-Mean-It, Refactor Till You Drop, Атомное кодирование и язык с высокой выразительностью, 90 секунд могут быть долгим временем без фиксации.
Йорг Миттаг
8

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

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

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

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

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

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

justjkk
источник
Я думаю, что этот ответ должен быть принятым, но, вероятно, спрашивающий искал более простое объяснение :)
Behnam Rasooli
7

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

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

Catchops
источник
5
Это было бы верно, если бы вы фиксировали в транке, но если вы фиксировали в ветви функций или в частной ветви, нет необходимости, чтобы она была готова к интеграции.
Нил Баттерворт
1
@Neil Butterworth: ... если нет других разработчиков, работающих над той же веткой с некоторыми зависимостями в вашем коде.
FrustratedWithFormsDesigner
@ Разочарованный В этом случае он, безусловно, должен быть компилируемым, но я не вижу, что он должен быть готов к интеграции и тестированию системы.
Нил Баттерворт
1
Интересная дихотомия здесь между распределенными и централизованными vcs. С распределенными vcs это никогда не будет проблемой, так как вы можете использовать локальные ветки и не мешать другим разработчикам.
Джордж Мауэр
2
@ Джордж - Это ложная дихотомия. Реальная дихотомия заключается в использовании частных (для каждого разработчика) веток или публичных (совместно используемых несколькими разработчиками). Это ортогонально тому, используете ли вы централизованную распределенную VCS (однако DVCS поощряют частные ветви, так как ветви начинаются как частные, пока вы их не опубликуете).
Стивен С. Сталь
6

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

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

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

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

Tyanna
источник
1
+1 для предупреждения компиляции. У нас была копилка в офисе, где каждый должен был вносить плату каждый раз, когда он совершал что-то, что в результате приводило к сбою сборки. К сожалению, мы получили довольно много денег таким образом, по крайней мере, на начальном этапе :)
Ray
@Ray - на моем последнем месте штраф попал в фонд лото. Увы, мы никогда не избавляли его от этой вредной привычки. : P
Тианна
1

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

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

FrustratedWithFormsDesigner
источник
Помните, что в распределенных системах commit! = Share. Вы должны нажать, когда у вас есть что-то готовое для обмена.
Рейн Хенрикс
@ Rein Henrichs: Хороший вопрос, хотя система управления исходным кодом здесь на работе не имеет такой функциональности (по крайней мере, насколько я знаю). Когда что-то фиксируется, все остальные в проекте могут видеть и повторно синхронизировать (и обычно делают это, иногда вслепую) с ним.
FrustratedWithFormsDesigner
Что может указывать на то, что вы могли бы извлечь выгоду из лучших инструментов. Все, что мешает частым коммитам, является ненужным препятствием.
Рейн Хенрикс
@ Рейн Хенрикс: я не буду спорить !!
FrustratedWithFormsDesigner
1

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

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

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

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

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


источник
1

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

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

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

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

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

Джаспер Кеннис
источник
Похоже, это не дает ничего существенного по поводу высказанных и объясненных в 10 предыдущих ответах. Кроме того, последний абзац, похоже, относится к git-специфической функции, в то время как вопрос, похоже, не о git
gnat
Бисекция не специфична Это может быть сделано с любым типом управления версиями, это был просто пример, так как я знаю, что Git
встроил
-1

Когда:

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