Перебазировать ветку, которая не была объединена владельцем репо - PullRequest
Новая
       85

Перебазировать ветку, которая не была объединена владельцем репо

2 голосов
/ 23 октября 2019

Я разработал проект на Github. Я настроил свою локальную версию своего форка на обновление с исходного репо с помощью , добавив его в качестве апстрима .

Теперь я создал ветку объектов, внес изменения и перетянул в исходное репо. Так как изменения огромны, получение (пока) не было принято владельцем репо.

Тем временем я обновил свою основную ветку от мастера оригинального репо, выполнив git pull upstream master несколько раз, так что моя особенностьВетка не синхронизирована с главной веткой.

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

Что я знаю (я не мерзавецpro) заключается в том, что я сначала локально зафиксировал бы свои спрятанные изменения в моей ветви функций, а затем, также локально, перебазировал свою ветку против master (или как это называется в git lingua).

Но я прочитал эту перебазировкусоздаст хаос в репо других людей.

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

1 Ответ

1 голос
/ 23 октября 2019

Во многих рабочих процессах git вы можете различать ветви функций и "стабильные" ветви.

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

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

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

С другой стороны, функциональные ветви являются изменчивыми и одноразовыми. Каждый из них создается для определенной потребности (как правило, исправления ошибок, новой функции) и удаляется, когда он, наконец, объединяется в свое стабильное место назначения. (В приведенной выше схеме feature-bar и feature-foo, но мы также можем догадаться, что в какой-то момент была ветвь, указывающая на C, которая была удалена после объединения E.)

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

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

Я использовал слияния здесь в своей схеме и объяснении, но рабочий процесс, использующий rebase, также сделал бы такое же различие между стабильными / функциональными ветвями.

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

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

Статья, на которую вы ссылаетесь, очень интересна, я согласен с основным пунктом, однако учтите, что она может вводить в заблуждение, когда вы обнаруживаете git и пытаетесь использовать его эффективно. Это довольно продвинутые соображения, которые могут привести к " cargo-cult " практикам, если им следовать без ясного понимания. Rebase - полезный инструмент, не выбрасывайте его.

...