Должен ли я ждать слияния ветви внука Git с мастером, пока дочерняя ветка не слилась с мастером? - PullRequest
Новая
       37

Должен ли я ждать слияния ветви внука Git с мастером, пока дочерняя ветка не слилась с мастером?

2 голосов
/ 12 июня 2019

В моем командном проекте я работал над веткой feature, которая была отделена от master. Я поднял запрос на получение feature, и он проходит проверку, но пройдет некоторое время, прежде чем я смогу объединить его.

Между тем, я работаю над тем, что основано на коде, который я реализовал в feature, но недостаточно связан, чтобы быть фактически реализованным в той же ветке. Итак, я разветвился на feature, вот так: 

master
└── feature
    └── different_feature

Если я поднял запрос на получение different_feature и он был одобрен до feature, могу ли я просто объединить его с master? Или я должен ждать, чтобы объединить different_feature, пока feature не объединится с master?

Меня беспокоит первый вариант: позже, когда вы проверяете журнал, некоторые части feature будут объединены в master в fghij, тогда как на самом деле его следует объединить в abcde. Это может быть неудобно, если мы хотим сохранить different_feature, но избавиться от feature (откат). 

git log (from newest to oldest - with dummy commit hashes)

abcde Merge pull request: feature
fghij Merge pull request: different_feature
klmno Merge pull request: something_implemented_before_all_this

Заранее спасибо.

[EDIT] Забыл упомянуть об этом: я сделал несколько дополнительных коммитов для feature после того, как я разветвил different_feature из него. Так что different_feature только частично наследует обновления, сделанные в feature.

[Обновить] В конце концов, я подождал, пока feature не будет объединен с master, а затем перенес different_feature на master, прежде чем объединить его с master. Это позволило мне отделить обновления, сделанные в feature от обновлений, сделанных в different_feature.

В качестве примечания, при поднятии запроса на получение для different_feature я узнал, что вы можете сравнивать только те изменения, которые вы внесли в эту ветку, установив базовую ветвь вашего запроса на feature вместо master , Обязательно измените его обратно на master при объединении этого запроса на извлечение.

1 Ответ

0 голосов
/ 12 июня 2019

В описываемой вами ситуации (я добавил несколько примеров коммитов для рассуждения) 

A---B---C <<< master
         \
          D---E <<< feature
               \
                F---G <<< different_feature

Запрос на получение для feature > master принесет только коммиты D и E, но еще один запросзапрос на different_feature > master принесет D, E, F и G.

Если вы попробуете запрос на извлечение feature > master ПОСЛЕ different_feature > master, уже принят / объединен, то естьничего не останется для слияния, и это приведет к неработоспособности.

Кроме того, следует отметить, что ничто не помешает вам отменить feature коммиты (D и E) позднееточка без возврата F и G, при условии, что вы не раздавили коммиты во время слияния .

Редактировать после комментариев

ФактическийСитуация кажется более похожей на 

A---B---C <<< master
         \
          D---E---H---I <<< feature
               \
                F---G <<< different_feature

Но общий принцип тот же, если вы помните, что git в основном работает на основе коммитов, а не ветвей.

Ситуация после первого PR(J - коммит слияния) 

A---B---C---------------J <<< master
         \             /
          D---E---F---G <<< different_feature
               \
                H---I <<< feature

Пульный запрос different_feature > master принесет D, E, F и G фиксируются в master, и если объединить первым, то только H и I будут оставлены для объединения во втором запросе на извлечение, который будетпересчитывается после объединения первого.

...