Я постараюсь ответить на ваш вопрос. (Я должен сказать здесь, что я не использовал GIT, только прочитайте об этом, поэтому, если что-то, что я упоминаю ниже, неверно, пожалуйста, исправьте меня)
«Можете ли вы перечислить сценарии, где это наследование является обязательным?»
Я не скажу, что это необходимо, потому что вы можете решить проблему с помощью имеющегося у вас инструмента, и это может быть правильным решением для вашей среды. Я предполагаю, что это больше зависит от процессов, чем от самого инструмента. Целью является обеспечение того, чтобы ваш процесс был последовательным, а также позволяющим вам вернуться в прошлое, чтобы воспроизвести любой промежуточный шаг / состояние, и плюс в том, что инструмент позволяет вам запускать свой процесс и SCMP настолько безболезненно, насколько это возможно
Единственный сценарий, который я вижу, удобно иметь такое поведение 'Наследование' и использовать всю мощь спецификации конфигурации, когда вы хотите, чтобы ваш набор изменений " изолировал"сопоставлен с задачей (devtask, CR, SR или что-то еще, что определяет цель / область действия вашего набора изменений)
Использование этой композиции позволяет очистить ветку разработки и при этом использовать другую комбинацию (используя композицию) остального кода, при этом содержит только то, что имеет отношение к задаче , изолированную в ветви в течение всего жизненного цикла задачи , вплоть до этапа интеграции.
Будучи пуристом, вынужденным совершать / объединять / перебазировать просто для того, чтобы иметь «определенную отправную точку», я думаю, это «1021 * загрязнит » вашу ветку, и вы в конечном итоге внесете свои изменения + другие изменения в вашу ветку. ветвь / набор изменений.
Когда / Где эта изоляция полезна?
Приведенные ниже пункты могут иметь смысл только в контексте компаний, преследующих CMM и некоторые сертификаты ISO, и могут не представлять интереса для других типов компаний или OSS
Будучи очень требовательным, вы, возможно, захотите точно подсчитать строки кода (добавленные / измененные / удаленные) набора изменений, соответствующего одному разработчику, позднее использовавшегося как один вход для оценки кода и усилий.
Может быть проще просмотреть код на разных этапах, имея только ваш код в одной ветке (без склеивания с другими изменениями)
В больших проектах с несколькими командами и +500 разработчиками, активно работающими одновременно над одним и тем же базовым кодом (где деревья версий с отдельными графическими элементами выглядят как запутанная запутанная сеть с несколькими линиями загрузки, по одной для каждого крупного клиента, или по одной для каждой технологии). ) большие спецификации конфигурации, использующие композицию глубиной в несколько градусов, позволили этому количеству людей без проблем работать над тем, чтобы адаптировать один и тот же продукт / систему (базовый код) для различных целей. Используя эту конфигурационную спецификацию, динамически предоставлял каждой команде или подгруппе различное представление о том, что им нужно, и от того, где они должны работать, (каскадирование в нескольких случаях) без необходимости создавать промежуточные ветви интеграции или постоянно объединять и перебазировать все биты, с которых вам нужно начать. Код из одной и той же задачи / цели был разветвленным, но имел смысл. (Вы можете утверждать здесь «известную базовую линию» как принцип SCM, но простые ярлыки, предусмотренные в письменном плане SCM, сделали свою работу)
Должно быть возможно решить эту проблему с помощью GIT (я полагаю, не в динамическом ключе), но мне очень трудно представить это без поведения «наследования».
Я предполагаю, что пункт, упомянутый VonC, «если разветвленные, все его файлы будут разветвляться с одной и той же уникальной отправной точки», был здесь нарушен, но помимо этого он был хорошо задокументирован на SCMP, я помню, что имелись веские деловые причины сделать это таким образом.
Да, создание этих конфигурационных спецификаций, о которых я упоминал выше, не было бесплатным, вначале там, где за SCM стояли 4-5 хорошо оплачиваемых людей, но позже их уменьшали автоматические скрипты, которые спрашивали вас, что вы хотите на условиях меток / веток / функции и напишет CS для вас.
Воспроизводимость здесь была достигнута путем простого сохранения спецификации конфигурации вместе с задачей в системе devTask, так что каждая задача вверх по течению сопоставлялась с требованиями, а вниз по течению сопоставлялась со спецификацией конфигурации, набором изменений (файлы кода, проектные документы , тестовые документы и т. д.)
Таким образом, здесь можно сделать один вывод, только если ваш проект достаточно большой / сложный (и вы можете позволить себе SC-менеджеров на протяжении всего жизненного цикла проекта :)), тогда вы только начнете думать, если вам нужно «наследование» поведение или действительно универсальный инструмент, в противном случае вы перейдете непосредственно к инструменту, который является бесплатным и уже позаботится о согласованности вашего SCM
... но на инструменте SCM могут быть и другие факторы, которые могут заставить вас придерживаться одного или другого ... читать дальше ..
Некоторые примечания, которые могут быть не по теме, но я думаю, что в некоторых случаях, например, мой, нужно учитывать.
Я должен добавить, что мы используем "добрый ол", а не UCM. Полностью согласен с VonC по , хорошая методология позволяет «направлять» гибкость в сторону более согласованной конфигурации . Хорошая вещь заключается в том, что CC довольно гибкий, и вы можете найти (не без особых усилий) хороший способ создать единообразные вещи, в то время как в других SCM вы можете иметь его бесплатно.
Но, например, здесь (и в других местах, где я работал с CC) для проектов на C / C ++, мы не можем позволить себе цену отсутствия функции winkin (повторное использование объектов Derive), которая сокращает в несколько раз X время компиляции. Можно утверждать, что лучший дизайн, более отсоединенный код и оптимизация Make-файлов могут уменьшить необходимость компиляции всего, но есть случаи, когда вам нужно компилировать всего зверя много раз в день, и совместное использование DO сохраняет куча времени / денег.
Там, где я сейчас нахожусь, мы стараемся использовать как можно больше бесплатных инструментов, и я думаю, что мы избавимся от CC, если сможем найти более дешевый или бесплатный инструмент, который реализует функцию winkin .
Я закончу с чем-то, что упомянул Пол, разные инструменты лучше, чем другие для разных целей , но я добавлю, что вы можете обойтись без некоторых ограничений инструмента, имея согласованный процесс и без Воспроизводимость, ключевые моменты от SCM
В конце концов, я думаю, что ответ на это стоит? зависит от вашей "проблемы", SDLC, который вы используете, ваших процессов SCM, и если есть какая-либо дополнительная функция (например, winkin), которая может быть полезной в вашем окружении.
мои 2 цента