Принесет ли слияние и разомкнутый запрос на извлечение исходящего потока в мой собственный форк мне горе, когда позже я попытаюсь выдвинуть ответвление моего ответвления на восходящий?

Question

Это одно замысловатое название, но сама ситуация не так сложна.

Есть проект с открытым исходным кодом, которому я помогаю, с его главной веткой A. У него есть ожидающий PR B, который, как я ожидаю, скоро будет объединен с мастером. Я разрабатываю некоторые новые функции в своей собственной ветке на своем форке в C, но мне нужны изменения, сделанные в B, чтобы продолжить. Я знаю, что могу объединить B в C без проблем . Вопрос в том, приведет ли это к проблемам, когда позже я захочу включить C в A? В этот момент оба они, вероятно, слились в B независимо друг от друга. Это создаст лишние коммиты?

Answer 1

Единственный ответ, который мы можем дать: возможно или это зависит .

Вы можете спросить: зависит от чего? и это где это становится немного сложнее. Git сам по себе не имеет PR. Сами запросы на извлечение - и разветвления в этом отношении - содержат данные, которые c указаны для любого конкретного хостинг-провайдера.

Что Git имеет, хранит и обменивает, совершает . Коммиты идентифицируются необработанными идентификаторами ha sh, которые всегда одинаковы в каждом хранилище. GitHub, GitLab, Bitbucket и т. Д. Построены поверх Git, поэтому они также сохраняют и обмениваются коммитами, но в них также встроен большой модный интерфейс. С командной строкой Git у нас есть определенные c команды, которые определяют c вещи с коммитами. Благодаря веб-интерфейсам у нас есть кнопки, которые часто запускают непонятные, неописанные команды - возможно, многие отдельные команды командной строки - и трудно сказать, что они делают.

Однако мы можем сказать, что здесь задействовано как минимум три репозитория. Есть тот, который вы назвали восходящим, вероятно, размещенный на каком-либо хостинг-сервере. На том же хостинг-провайдере есть еще один форк - еще один Git репозиторий, в котором существует этот PR B, который вам интересен. На этом же хостинг-провайдере есть ваша вилка, третий репозиторий. Вероятно, на вашем компьютере есть хотя бы еще один репозиторий Git (например, ноутбук).

Если вы буквально объединяете коммиты из PR B, так что вы добавляете в свой репозиторий коммит, родитель которого является После коммитного коммита этого PR B вы добавили фактические коммиты этого PR с их фактическими идентификаторами ha sh в ваш репозиторий и ваши филиалы (возможно, на вашем ноутбуке, возможно, на хост-сервере). Но если вы используете операцию, которая копирует PR B коммиты, такие как git merge --squash или git cherry-pick или git rebase, - тогда вы получите разные совершает. Некоторые веб-хостинги, нажимающие кнопки «объединить это», делают такие копии, а не используют оригиналы.

У любого, кто владеет исходным хранилищем, есть аналогичный выбор: они могут фактически объединить коммит с коммитом PR B. Если они буквально сливают это, а , вы буквально сливаете это, Git в конечном итоге делает все, что в его силах, с минимально возможным количеством проблем. Но если они используют процесс, который копирует коммитов, у них будет другой набор коммитов, чем у вас, независимо от того, скопировали ли вы также коммиты из этого PR B.

И, конечно же, тот, кто представил PR B вышестоящему, мог отозвать его и предоставить ему новые коммиты, причем все самостоятельно. (Точный механизм этого может зависеть от хост-сервера.)

Все это просто возвращает все к несколько неудовлетворительному ответу: Возможно; это зависит.