Можно ли когда-нибудь зафиксировать неработающий код?

Это хорошая идея требовать, чтобы фиксировать только рабочий код?

Этот коммит не должен оставлять репозиторий в рабочем состоянии, так как:

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

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

  1. локальные файлы
  2. плацдарм
  3. совершает в местном филиале
  4. фиксирует в удаленной персональной ветке
  5. объединить с удаленной developветкой
  6. объединить с удаленной masterветкой
  7. объединить с удаленной releaseветкой

• ... совершать рано, совершать часто.

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

Добавлено: есть несколько комментариев с высокими оценками, в которых говорится, что на местном уровне можно делать все, что угодно. Однако меня не интересует техническая сторона вопроса. Скорее, я хотел бы изучить лучшие практики - привычки, которые люди, которые работали много лет в промышленности, преследовали наиболее продуктивно.

Я поражен огромным количеством отличных ответов! Они приводят меня к выводу, что я недостаточно искусен в использовании веток для организации своего кода.

Одна из философий ветвления (раздел Разработка стратегии ветвления и политики кодирования в расширенных стратегиях ветвления SCM - также прочитайте « Выполнение передового опыта» , это PDF-файл, но подробно разбирается в некоторых других) - это то, что вы переходите на несовместимую политику.

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

(из передовой практики Perforce)

Скажем, у вас есть ветки 'release' (или 'master'), из которых построен релиз, и 'trunk' (или 'dev'), где разработчики проверяют рабочий код. Это политика филиалов. Отмечая, что «рабочий код» является частью политики ветки «dev», никогда не следует фиксировать испорченный код в ветке dev. Часто есть такие вещи, как CI-серверы, подключенные к этим веткам, и проверка неработающего кода в dev может испортить все ветви и сломать сборку.

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

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

(из передовой практики Perforce)

Поймите, что это исходит от SCM на основе центрального сервера с сильным корпоративным мышлением. Основная идея все еще хороша. Об этом часто думают неявно - вы не проверяете непроверенный код dev в ветке release. Это политика.

Так ветвь, скажем, что эта ветка может иметь неработающий код и фиксировать.

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

Да, пока это не ветка релиза.

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

Ценность совершения неработающего кода ?: сотрудничество и эксперименты

Да, это нормально, и это то, чем я занимаюсь.

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

Мои практики:

• сначала напишите тесты
• WIP (работа в процессе) коммиты хороши
• часто совершать (несколько раз в течение дня) и рано (за исключением «рабочих» шагов)
• нажимайте после каждого коммита (в случае сбоя жесткого диска / попадания шины в вас).
• всегда сначала работай в филиалах
• при возможности только слить в рабочий код мастер
• интерактивная перебазировка в git, чтобы раздавить вайпы перед слиянием

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

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

Возможно, лучший вариант - это в основном более профессиональный подход к разработке программного обеспечения и действительно требующие рабочих тестов для любого подтвержденного кода. Часто это «трудная» часть разработки программного обеспечения, а не кодирование, которое представляют многие люди. Для лучшего подхода, вероятно, потребуются более точные начальные оценки, распределение ресурсов, установление приоритетов и т. Д., А также во время гибкой разработки, что позволит уделить достаточно времени и дисциплины, чтобы устранить любые проблемы как во время их возникновения, так и во время сеансов подготовки указателей.

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

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

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

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

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

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

Прежде чем начать понимать, как работать с управлением версиями, стоит подумать о том, почему вы работаете с управлением версиями.

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

Когда вы должны совершить? Когда есть разумный шанс, вы посмотрите на состояние вашего кода (или сообщение о коммите, объясняющее изменение) в будущем.

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

ПОЦЕЛУЙ . То, что лучше всего подходит для одного разработчика на ранних стадиях разработки небольшого проекта, будет совершенно другим, чем то, что вам нужно делать, когда у вас есть сотня разработчиков, работающих над десятилетней, критически важной системой. В любом процессе разработки программного обеспечения вы должны избегать создания ненужных артефактов просто потому, что кто-то другой сказал вам сделать это.

Построить / выпустить ветки

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

Другие отрасли: часто сохраняйте штат

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

Рассмотрим эти примеры, где сохраненное состояние дает значительное преимущество:

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

Фиксация неработающей кодовой базы - это нормально, если она локальна.

Зачем?

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

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

1. время, потраченное на дальнейшие функции, теперь потрачено на исправление ошибок ...
2. срез развития не встречен ...
3. товар не отправлен вовремя

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

Я не думаю, что это нормально для фиксации неработающего кода.

Что будет если

• Требуется срочное исправление. Кодовая база в неисправном состоянии. Вы вынуждены откатиться, починить и развернуть.

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

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

• Кто-нибудь развертывает ваш «сломанный код»? Это может быть «игра окончена», если вы работаете с личными данными или у провайдера платежей.

Ответить @WarrenT

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

Некоторые вопросы, которые помогут вам определить, можно ли фиксировать нерабочий код:

1. Вы переутомлены?
2. Ваши товарищи по команде постоянно ломают сборку?
3. Ваш кодовый код беспорядок и, кажется, не может стать хуже?

Если вы скажете «да» на любой из вышеперечисленных, то да, это нормально, чтобы зафиксировать нерабочий код.

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