Лучшая практика отслеживания восходящего потока в форке на github
Резюме :Каковы передовые методы обработки длительного отслеживания вышестоящих репозиториев, в которых вы хотите поддерживать набор локальных изменений?
Я хочу сохранить форк на github с датой -до -с восходящим потоком, но при этом разрешить четкое отслеживание изменений, уникальных для форка. (для этого обсуждения предположим, что upstreamуказывает на основной репозиторий проекта, а origin— на мой форк репозитория)
Представьте, что у меня есть что-то вроде этого, где я разветвил репозиторий, когда восходящий поток/мастер был в E.
Upstream:
A-B-C-D-E-F
Fork:
A-B-C-D-E ----- P ------T
\-L-M-/ \-Q-R-/
После разветвления репозитория я создал две ветки функций (L -M и Q -R ), чтобы добавить новые функции, которые мне нужны, и объединил их обратно в мой источник/мастер. Итак, теперь в моей ветке есть улучшения, которых нет в основной ветке.
Я обнаружил, что в апстриме есть пара интересных исправлений, поэтому я хочу вернуться к синхронизации с апстримом. Основываясь на большинстве ссылок, которые я нашел(вилка концентратора git), рекомендуемый способ сделать это — объединить upstream/master с вашим origin/master и продолжить свой путь. Поэтому я бы выдавал такие команды, как:
git checkout master
git fetch upstream
git git merge upstream/master
git push
Тогда я бы получил репозитории, которые выглядят так:
Upstream:
A-B-C-D-E-F
Fork:
A-B-C-D-E ----- P ------T-F'
\-L-M-/ \-Q-R-/
Однако я вижу в этом пару проблем.
На самом деле у меня нет фиксации F в моем репо,У меня есть F' с таким же содержанием, но с другим хешем. Поэтому я не могу легко ссылаться на коммиты между двумя репозиториями и знать, что у меня есть изменение. (это становится еще более сложным, если учесть, что вышестоящая часть, вероятно, имеет более одного изменения и имеет свой собственный набор веток функций, которые были объединены)
По мере того, как я продвигаюсь вперед и продолжаю это делать, мне становится все труднее узнать, какие изменения у меня есть в моем репозитории помимо того, что находится в основной ветке разработки. Например, я могу отправить некоторые из этих изменений обратно вверх по течению, продолжая добавлять свои собственные уточнения. После нескольких итераций этого, как кто-либо, просматривающий мой репозиторий, узнает, чем он отличается от основного? (Есть ли команда git для поиска этих изменений?)
Аналогично #2, как кто-то может найти исправление в восходящем потоке и проверить, содержит ли это исправление мой форк?
Я предполагаю, что корень проблемы в том, что я не могу гарантировать, что мой репозиторий «синхронизирован» с восходящим потоком в любой момент, потому что код и хэши не совпадают. Итак, как я могу точно отслеживать изменения и не сойти с ума, пытаясь синхронизировать вещи?
Примечание. :Я рассматривал возможность использования перебазирования, чтобы продолжать перебазировать мой репозиторий за пределы восходящего потока, но это имеет совершенно другой набор проблем. Например, если кто-то ссылается на мой репозиторий через подмодули, ветки и т. Д., Перезапись истории нарушит их ссылки. Кроме того, я не думаю, что моя история веток переживет перебазирование, поэтому у меня не будет полного представления обо всех ветках функций, которые я создал, и связанной с ними истории.
Как другие люди справляются с этим? Какие лучшие практики я должен изучить?
Обновление:
Основываясь на отзывах Сета, я создал набор тестовых репозиториев, чтобы показать, о чем я говорил, и как это работает так, как он говорит.
Хранилища:
Они должны более четко показывать, как выглядит слияние из апстрима, когда есть и локальные изменения.