Как git помогает справиться со сценарием ниже:
У меня есть задача, разбитая на 2 части: внутренняя задача и внешняя задача. Я делаю пулл-запрос, чтобы объединить внутренние изменения и жду его слияния (и адрес обратной связи). Во время ожидания я не могу по-настоящему работать над изменениями во внешнем интерфейсе, потому что это зависит от изменений во внутреннем интерфейсе, которые еще не доступны в основной ветке.
Каков наилучший способ получить изменения в ветке изменений внешнего интерфейса из ветви внутренних изменений, пока она еще рассматривается?
Ответы:
У меня тоже иногда есть эта проблема. Git очень гибкий. Вот один из способов, которым вы можете сделать это.
Ваша первая ветка
featureA
готова для просмотра.Ваша вторая ветка
featureB
находится в разработке и зависит от кода вfeatureA
ветке.Слить
featureA
ветку вfeatureB
ветку.Если вы вносите изменения в
featureA
ветку, то вам следует снова объединитьfeatureA
ветку сfeatureB
веткой, чтобы включить изменения.Вы также должны убедиться, что
featureA
сначала слились с основным стволом, в противном случае, когда вы слилисьfeatureB
с основным стволом, вы также случайно слилисьfeatureA
. ПослеfeatureA
слияния с основным стволом вы можете избавиться отfeatureA
ветви, посколькуfeatureB
теперь это зависит только от основного ствола.Я предпочитаю это, когда мои функциональные ветви не зависят друг от друга, но иногда они есть, и вы должны катиться с этим.
источник
featureA
на вfeatureB
случае необходимости?featureA
, если вам придется начинать все сначала. Хорошо думать о ветвях Git как одноразовых. Они дешевы и просты, всегда можно сделать новую ветку. Вы можете даже создать тестовую ветку на своейfeatureB
ветке, если хотите поиграть с чем-то, в чем вы не уверены, а затем удалить его, если он не сработал, или объединить его с вашейfeatureB
веткой, если он это сделал.Держись, пропусти слияние
При таком подходе, вы не хотите , чтобы объединить ваши
feature_a
вfeature_b
несколько раз.Перебазирование упоминалось в других ответах, но только для перебазирования вещей на
master
. Что вы хотите сделать в вашем случае:Начните
feature_b
сfeature_a
, то есть:Всякий раз, когда
feature_a
изменения ожидают слиянияmaster
, вы перебазируетеfeature_b
их:Наконец, как только
feature_a
вы объединяетесьmaster
, вы просто получаете новоеmaster
и перезагружаетеfeature_a
его в последний раз:Эта финальная перебазировка прививает все коммиты, которые свисают с
feature_a
коммита (который теперь не имеет значения, поскольку он был объединенmaster
) прямо наmaster
.feature_b
Теперь ваша простая, стандартная ветка идет прямо отmaster
.РЕДАКТИРОВАТЬ: вдохновленный комментариями, немного наполовину: если вам нужно внести некоторые изменения, которые влияют на обе функции, то обязательно внесите их
feature_a
(а затем выполните перезагрузку, как показано на рисунке). Вы не сделать это в двух различных фиксаций в обеих ветвях, даже если может быть заманчивым; как этоfeature_a
является частью историиfeature_b
, наличие единственного изменения в двух разных коммитах будет семантически неверным и, возможно, позже приведет к конфликтам или «воскрешению» нежелательного кода.источник
feature_a
многократной перезагрузке вы можете столкнуться с проблемами,feature_a
которые произошли в то же время. В результате выполненияgit checkout feature_b; git rebase feature_a
вы можете получить конфликты или некоторые забавные коммиты, содержащие коммиты, отменяющие новые измененияfeature_a
. Обычно это можно решить, используя--interactive
и пропуская коммиты, взятые из старой версии другой ветки (недавно мне приходилось делать это несколько раз).rebase
и многие другие индивидуальные шаги, а не простыеmerge
, у него, безусловно, гораздо больше шансов создать конфликты; с другой стороны, этоmerge
было бы семантически неправильно в этом случае.merge
что возникли бы похожие или худшие проблемы (конфликт не так плох, как попадание в нежелательные изменения). Я рассматриваю ветвь как последовательность желаемых изменений, которым предшествует множество несвязанных изменений (логически принадлежащих другой ветке). При многократной перебазировке с одной и той же веткой я всегда удаляю несвязанные изменения, так как знаю, что они в любом случае придут (возможно, в обновленной форме), и все работает отлично.git rebase --onto
FTW: DУ вас уже есть ветвь, от которой зависит каждая ветка вашей функции и которая постоянно меняется. Это называется
master
.Типичный способ синхронизации ветвей объектов
master
- это оставаться на вершине . Когдаmaster
меняется, вы обычноgit fetch origin master:master && git rebase master
в рабочем каталоге вашего филиала.Вы можете сделать то же самое с другой веткой функций: продолжайте извлекать ее и перебрасывать поверх нее.
Если по какой-то причине вам необходимо перенести изменения в другую ветку, вы можете выбрать свои коммиты, которые никогда не смешиваются с коммитами других веток.
источник
feature-b
наfeature-a
, и сделать время перебазирования после времени , какfeature-a
меняется. Это типичный способ сделать заметным большое изменение: разбить его наpart-A
(основано наmaster
),part-B
(основано наpart-A
) и больше, если необходимо. Затем сделайте запрос на извлечение для каждой части, и рецензентам будет легче смотреть на небольшие, логически сгруппированные фрагменты.В этом случае, когда задача внешнего интерфейса имеет критическую зависимость от кода бэкэнда, и вы хотите начать работу с внешним интерфейсом до того, как бэкэнд будет завершен и принят на главном сервере, я бы просто запустил задачу внешнего интерфейса как ветвь функции, выходящую из бэкэнд ветвь, а не ветвь фронтэнда на master.
Ветвь функции, которая живет достаточно долго, должна сливаться с изменениями от мастера иногда (чтобы вы могли согласовать любые слияния или семантические конфликты как часть работы разработчика над веткой функций, а не как часть «обзора», qa, merge- чтобы освоить "процесс). Таким образом, вы делаете это в своей ветке переднего плана, и когда бэкэнд будет принят к мастеру, вы получите любые незначительные изменения, которые были внесены в бэкэнд как часть его проверки / принятия автоматически, по тому же маршруту, что и вы. получить любые другие изменения кода на мастере.
Если выяснилось, что бэкэнд-ветке требуется гораздо больше работы, и она продолжает меняться в течение определенного периода времени перед объединением с мастером (скажем, если во время обзора обнаруживаются серьезные проблемы), то вам, вероятно, вы захотите выполнить периодическое слияние напрямую. из бэкэнд-ветви в ветвь внешнего интерфейса (так что вы не будете основывать всю свою работу на внешнем коде). Это легко, если вы являетесь единственным разработчиком, выполняющим обе функции (так как вы знаете, вносите ли вы какие-либо серьезные изменения), но даже если обе функции работают параллельно с разными разработчиками, все должно быть хорошо; вам просто нужно поддерживать связь (что вам и нужно в любом случае, если вы работаете над параллельными задачами, в которых одна критически зависит от другой).
Если оказывается, что всю ветку бэкэнда нужно оставить и никогда не объединять (кажется, что это будет довольно серьезная сделка, которая случается редко), то вы либо выбираете свои коммиты для новой ветки, выходящей из мастера без бэкэнда, или вы применяете обратные коммиты, которые удаляют весь код бэкенда в ветвь веб-интерфейса. Но, как я вижу, с большей вероятностью будет приостановлена работа внешнего интерфейса, пока вы не выясните, что должно заменить заменяемый сервер, а затем решите, что делать.
источник
Я не вижу здесь проблемы.
У вас уже есть это каждый раз с вашей
master
веткой, которая постоянно меняется, пока функции разрабатываются и затем объединяютсяИтак, в вашем конкретном примере вы сначала создаете
feature_xxx_backend
ветку и разрабатываете изменения бэкэнда. Когда это будет сделано, ветвь будет готова к рассмотрению и будет объединенаmaster
после завершения проверки.Итак, просто начните другую ветку
feature_yyy_frontend
. Вероятно, вы захотите перейти прямо из филиалаfeature_xxx_backend
, чтобы эти изменения уже были в вашем филиале. затем просто разработайте внешний интерфейс, если ветвь былаmaster
.Когда
feature_xxx_backend
ветвь изменяется, например, потому что есть вещи, которые возникают во время проверки, которые необходимо учитывать, просто внесите эти изменения и объедините их вfeature_yyy_frontend
ветку. Затем продолжите на ветке интерфейса.Как только проверка внутренней ветки завершена, она объединяется в
master
. На данный момент, было бы целесообразно , чтобы перебазироваться вfeature_yyy_frontend
ветви наmaster
, так что рецензенты нужно только рассмотреть новые изменения , которые эта отрасль вносит свой вклад вmaster
, и не нужно повторно просмотреть изменения , сделанные для внутреннего интерфейса (которые уже были утверждены ).Это также может быть сделано, когда у вас есть две, три или более зависимых веток. Если у вас есть две ветви функций, от которых вы зависите, просто создайте производную ветвь, в которой объединены обе функции. Оттуда ветвь, разработайте третью функцию, объединяйте обе ветви функции по пути, когда каждая из них изменяется. Когда обе функции завершены и объединены в производную ветвь, переназначьте ее или, если они объединены в основную, перебазируйте в основную.
Перебазирование (как предложено выше) действительно мощно и помогает вести чистый журнал изменений, делая обзор намного проще.
источник
Как уже упоминалось в Polygnome, вы можете фактически объединить свою ветвь внешнего интерфейса со своей внутренней веткой вместо основных. Даже с текущей настройкой ветки вы можете просто:
или просто
Имейте в виду, что если изменения в бэкэнде не принимаются и требуется дополнительная работа, вам придется объединять обновления из бэкэнда в интерфейс, чтобы избежать конфликтов. Как только изменения будут приняты мастером, вы можете переназначить свой внешний интерфейс на мастер, чтобы избавиться от коммитных слияний.
Технически вы также можете делать все с rebase, но это испортит историю коммитов вашей ветки интерфейса. Откуда я родом, это считается плохой практикой. YMMV
источник
Большинство ответов здесь правильно описывают процесс объединения изменений из второй ветви в первую, но в них не рассматривается, как минимизировать количество конфликтов, которые вам, возможно, потребуется разрешить.
Всякий раз, когда у вас есть два набора больших изменений, которые вы хотите просмотреть по отдельности (например,
featureA
иfeatureB
), создайте PR, который НЕ предназначен для слияния, но для сбора ранних отзывов о PoC offeatureA
.Люди смогут быстро его просмотреть (это всего лишь PoC), и цель состоит в том, чтобы проверить общий дизайн или подход.
Затем вы можете продолжить работу с функцией A, создать для нее запрос на извлечение и выполнить ветвление и работать с функцией B.
Большая разница состоит в том, что теперь вы можете ожидать,
featureA
что ничего не изменится радикально: дизайн и подход уже были проверены. Обзор кода и требуемые изменения могут быть тонкими и локальными, а не «woops, вам нужен другой подход». Это позволит свести к минимуму объем работы , что вам нужно сделать , чтобы в дальнейшем объединитьfeatureB
наfeatureA
«ы кода, независимо от метода вы выбрали.источник