Является ли кольцо интегрированным в Git хорошей идеей или даже возможно
В течение многих лет я работаю с Perforce и, к сожалению, не очень много работал с Git, за исключением нескольких хобби-проектов, поэтому прошу прощения за мое незнание.
В Perforce я использую концепцию интегрирования кольца, как описано ниже.
Разработчики работают в ветке feature1v, feature2 и feature3. Они интегрируются в ветку разработчика. Ветвь dev становится стабильной, только если все машины успешно ее скомпилировали. Это означает, что у каждого разработчика, который интегрируется из стабильного в Feature1, Feature2 или Feature3, всегда есть рабочая база для интеграции.
+---+stable
| ^
| |
| |
| dev <---+---+
| | |
| | |
+--->feature1+ |
| |
+--->feature2+---+
| |
+--->feature3+---+
Вопрос, имеет ли эта концепция смысл в git и возможно ли это даже с DAG? Или как бы вы структурировали структуру веток в Git?
1 ответ
Это должно быть возможно, и я считаю, что это несколько распространено. То, что вы нарисовали, это всего лишь кольцо с точки зрения того, как вы его поддерживаете, но на самом деле не вводите циклы в DAG для фиксации, потому что имена ветвей (особенно "стабильные") являются движущимися целями, тогда как DAG для фиксации использует точного родителя. идентификаторы.
То есть "feature1" не записывается как "стабильный", он основан на конкретном коммите, который в тот момент был "стабильным". Когда вы объединяете "feature1" в "dev" и оттуда в "stable", это не приводит к обратному обновлению базы всех ветвей функций, они сохраняют тот же DAG, что и раньше.
И точно так же, слияние ветки просто объединяет коммиты с этого момента времени и не обновляется задним числом. Таким образом, вы можете безопасно вставить обратно "stable" в "feature1" во время разработки, и это не повлияет на будущее объединение "future1" в "dev" / "stable". (Я вижу, что это иногда делается в linux.git, но я полагаю, что они стараются избегать этого, потому что это генерирует ужасно выглядящий DAG.)
Вместо обратного слияния у вас также есть возможность вручную перебазировать ветку функций, чтобы интегрировать новую работу из "стабильного". Хотя это (как и любое переписывание) создает новые коммиты поверх новой базы, отбрасывая те, которые уже присутствуют в базе. (Таким образом, перебазирование недавно объединенной ветви приведет к пустой ветви.)
Таким образом, по-прежнему невозможно вводить циклы, потому что идентификатор каждого коммита зависит от его родителя (например, если есть A←B, совершенно невозможно переписать A, чтобы получить B←A, не сделав недействительным существующий указатель, который уже есть у B; d получить это A←B←A', а не цикл).