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

40

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

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

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

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

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


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


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

Vorac
источник
28
В местных филиалах все идет. Совершайте все, что вы хотите. Просто уберись, прежде чем нажать.
Иоахим Зауэр
@Joachim Sauer, я спрашиваю о передовых практиках и их обосновании, чтобы выработать хорошие привычки . В настоящее время я часто фиксирую неработающий код. И возвращение - это кошмар, через десятки коммитов за последние пару дней.
Vorac
9
если вы разрабатываете каждую функцию в своей собственной ветви, то это решение тривиально: откажитесь от ветви, продолжайте с новой ветви, созданной на текущем мастере
Joachim Sauer
1
если вы не определите, что делает коммит «нарушенным», невозможно авторитетно ответить на этот вопрос. Смотрите также: Должен ли программист исправить чью-то неудачную сборку?
Комнат
1
"Почему? Какова ценность сломанного коммита?" Способность выявить проблему и протестировать несколько различных решений поверх нее и иметь возможность надежно вернуться к проблеме, которую вы знали, у вас была, а не к состоянию, в котором она у вас есть, и, возможно, к некоторым новым тоже ,
Джошуа Тейлор

Ответы:

20

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

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

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

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

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

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

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

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

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


источник
40

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

WarrenT
источник
2
Это действительно прекрасная вещь. Я не думаю, что сообщество действительно научилось ценить git и DVCS в целом.
ChaosPandion
5
Пока люди не путают эту философию с программированием проб и ошибок, чего следует избегать.
Питер Б
10

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

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

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

dukeofgaming
источник
Незначительный твик: Да, пока он не будет запущен в производство. Например, код, скрытый переключателем функций.
Роб Кроуфорд
5

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

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

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

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

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

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

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

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

Майкл Даррант
источник
3

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

nvoigt
источник
8
Это не обязательно верно для DVCS. Например, если локальный личный репозиторий или ветвь функций являются локальными, резервное копирование может выполняться, а может и не сохраняться (это особенно верно, если вы работаете в автономном режиме из корпоративной сети без доступа к ресурсам компании). Ветви master и release должны быть где-то, для которых выполняется резервное копирование, но это не обязательно верно для локальной ветки.
Томас Оуэнс
Коммит даже в DVCS стоит чего-то, поскольку код в нем «более постоянен», чем код в файлах. По крайней мере, для мерзавца.
Иоахим Зауэр
3
@ThomasOwens, при всем уважении, если ваш администратор DVCS настроил вашу систему так, чтобы локальные репозитории или филиалы не были зарезервированы, ваш администратор DVCS - идиот, и ему нужно найти новую работу, более подходящую для его талантов («Хотели бы вы картошка с этим? "). Если ваш администратор DVCS сделал это таким образом, потому что ваши ИТ-специалисты сказали ему об этом, то это относится и к вашей ИТ-организации. Во всяком случае, это, возможно, обвинительный акт всей концепции DVCS: фиксация кода в VCS должна ПО УКАЗАНИЮ означать фиксацию его в автоматическом резервном копировании.
Джон Р. Штром
6
@ JohnR.Strohm Во время путешествий я часто имею ограниченный доступ к сети, поэтому у меня нет доступа к резервным ресурсам или сетевым дискам. Я разрабатываю без резервного копирования, пока у меня нет доступа к сети. Это точка DVCS - вам не нужна сеть. Следует ли резервировать ваш репо? Возможно, но это только требование для релиза или мастер-репо. В любом случае, вы не должны идти несколько дней между нажатием на резервное хранилище, но эти толчки не должны быть испорченным кодом.
Томас Оуэнс
1
@ThomasOwens, моя точка зрения заключается в том, что хотя ваш доступ к указанному серверу резервного копирования носит эпизодический характер, принятие его должно быть приоритетом по сравнению с тем, чтобы ваш код работал. Вы всегда можете заставить свой код работать на другой машине, даже другие люди в вашей команде могут заставить код работать на своих машинах. Если он установлен только на вашей машине, клиенту, скорее всего, все равно, будет ли он работать. Заказчик заботится о новом выпуске с сервера сборки, который, в свою очередь, обращается из репозитория сервера.
nvoigt
3

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

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

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

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

Майкл Шоу
источник
3

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

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

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

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

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

Шон Максомт
источник
Ваш ответ вдохновляет, но неясен для меня. Моя проблема в том, что я создаю (я думаю) слишком много коммитов, и когда мне нужно вернуться, я не знаю куда, так как многие из них не работают. Контекст соло разработки небольшой команды <5. Я думаю, что забираю вещь «часто совершать» слишком далеко, и, возможно, мне нужно прийти в себя. Как я делаю коммиты, которые будут иметь значимое сообщение коммита?
Vorac
1
Если вы обнаружите, что вам нужно совершать коммиты каждый раз, когда вы компилируете / тестируете, возможно, вам нужно найти лучший редактор, который даст вам больше истории отмен. Если вы не можете написать сообщение о коммите, которое содержательно выражает ваши изменения, не фиксируйте.
Шон МакSomething
Если у вас возникли проблемы с запоминанием того, к чему вы хотите вернуться, вы не будете достаточно часто объединять свои изменения. Держите "стабильную" ветку, ветку "разработки" и "экспериментальную" ветку. Когда код работает, объедините ваши изменения из «экспериментального» в «dev» (сначала разбейте ваши коммиты), а затем свободно разбивайте «экспериментальный», зная, что вы можете просто удалить его и создать новую ветку из «dev». Как только вся функция завершена, объедините dev в stable.
RubberDuck
2

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

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

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

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

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

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

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

Зачем?

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

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

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

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

iGbanam
источник
0

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

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

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

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

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

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

Ответить @WarrenT

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

CodeART
источник
Downvote. Ни один из этих сценариев маловероятен, если вы используете стандартный рабочий процесс DVCS.
user16764
1
С рабочим процессом git (или другим DVCS) разработчики работают над ветвями, локальными ветвями, а не над основной магистралью. Следующий вопрос будет, если разработчик когда-нибудь отправит сломанный код в другой репозиторий. Это вопрос команды, которая понимает, для чего нужны ветки, и использует хорошие комментарии к вашим коммитам. Оперативное исправление может быть сделано только в ветке релиза. Конечно, никто не должен объединять там неработающий код. Команды должны иметь правила рабочего процесса, но то, что делается в локальном репозитории, - это совсем другое дело.
WarrenT
Я думаю, что есть разница между «нерабочим кодом» (о чем спрашивал ОП) и «неработающим кодом», на который вы ссылаетесь.
Саймон
@WarrenT Пожалуйста, смотрите ответ.
CodeART
-1

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

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

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

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

Рудольф Олах
источник