Должны ли проверки быть маленькими шагами или полными функциями? - PullRequest
25 голосов
/ 15 июня 2010

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

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

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

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

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

Так что же делать разработчику? Проверить маленькие шаги или полные функции?

Ответы [ 7 ]

20 голосов
/ 15 июня 2010

Так что же делать разработчику? проверить маленькие шаги или полные функции?

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

  • Ваш проект имеет master и release ответвлений. Каждый разработчик поддерживает свои развивающие ветви, которые они не продвигают.

  • Вы используете development , чтобы выполнять свою повседневную работу. Здесь появляются коммиты размером с укус, отражающие постепенные изменения состояния проекта с течением времени. Вы можете создать ветку - * для работы с более длинными функциями, охватывающими более нескольких дней, или с серьезными рефакторингами. Вы обязуетесь разрабатывать очень часто, возможно, несколько раз в час. Это как нажать «Сохранить» в редактируемом документе.

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

  • Когда релиз готов к выпуску, ваш ведущий разработчик объединяет все коммиты с момента последнего слияния с master в один коммит слияния, который появляется на мастер . Затем вы помечаете этот коммит идентификатором релиза (например, v.1.0.4). Это случается нечасто, возможно, один раз в итерацию или каждые несколько недель.

Здесь вы получите свой торт и съесть его тоже. Перед выпуском вы можете откатить изменения, которые не должны были произойти или которые вы не хотите включать в выпуск, и вы можете сделать это по одному за раз. Разработчик удобно! Но пользователи тоже получают то, что хотят: большие, неповоротливые коммиты на master , которые представляют, что изменилось с момента последнего выпуска.

19 голосов
/ 15 июня 2010

Прелесть систем DVCS в том, что вы можете иметь оба , потому что в DVCS в отличие от CVCS публикация ортогональна фиксации .В CVCS каждый коммит публикуется автоматически, но в DVCS коммиты публикуются только тогда, когда они выдвинуты .

Итак, коммит небольшими шагами, нотолько опубликовать работающие функции.

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

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

Теперь Linux немного особенный: в него входят коммиты со скоростью 1 коммит каждые 11 минут по 24 часа в сутки, 7 днейнеделю, 365 дней в году, включая ночи, выходные, праздники и стихийные бедствия.И этот показатель все еще увеличивается.Только представьте, сколько будет коммитов, если каждая опечатка и брейнфарт приведут к коммиту.

Но сами разработчики в своих личных репозиториях фиксируют, как часто хотят.

6 голосов
/ 15 июня 2010

Маленькие шаги. Есть причина, по которой он называется контроль версий , а не контроль релизов :)

Совершайте так часто, как вам нравится. Не сдерживайся. Не должно быть негативных последствий для фиксации кода в ветке «в процессе». Магазины разработки, которые ожидают, что не "сломают сборку", неправильно используют RCS. Аналогично, присвоение any , означающее что-либо для фиксации, является опасной политикой, просто потому, что она конфликтует с целью контроля версий. Вместо этого значение должно быть приписано тегам, ветвям, клонам, тайникам или тому, как их называет RCS. Эти вещи имеют метаданные (возможно, такие же минимальные, как имя ), предназначенные для передачи цели. Изменения - это просто история того, что вы изменили.

Последнее, что вы хотите сделать, - это ввести политику, запрещающую разработчикам фиксировать свой код, по любой причине.

3 голосов
/ 15 июня 2010

Маленькие шаги действительно великолепны.Вы всегда можете объединить их в более крупные шаги в другом репо.Чтобы сделать обратное, вы должны «переписать историю», что может быть сделано в некоторых системах (особенно git), но это не так хорошо поддерживается, как вам хотелось бы.

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

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

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

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

3 голосов
/ 15 июня 2010

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

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

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

3 голосов
/ 15 июня 2010

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

0 голосов
/ 15 июня 2010

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

  • Лучшие оценки развития.
  • Лучшие оценки тестирования.
  • Ускоренное время разработки.
  • Меньше общих ошибок.
  • Меньше связи между модулями.
  • Обнаружение раньше, если мой код непреднамеренно сломал что-то еще.
  • еще много

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

Надеюсь, это поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...