Git Tracking Upstream

Я работаю над проектом, и у меня есть центральный репозиторий Git. Этот проект является каркасом, который станет основой для ряда вилок.

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

Я думаю, я хочу, чтобы мой рабочий процесс был что-то вроде:

Создать скелет & gt; & gt; Скелет вилки & gt; & gt; Скелет извлекает изменения из Fork 2 & gt; & gt; Вилка 1 тянет изменения от скелета

Есть ли лучший способ сделать то, что я описал?

Ответы на вопрос(2)

вы должны сдвигать вилки на скелете всякий раз, когда он меняется, используя

$ git rebase upstream

Это изменит ситуацию следующим образом

initially:
1 - 2 - 3 <- upstream
        \- 4 <- fork

upstream changes:
1 - 2 - 3 - 5 - 6 <- upstream
        \- 4 <- fork

after rebase:
1 - 2 - 3 - 5 - 6 <- upstream
                \- 4 <- fork

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

Недостатком этого подхода является то, что он меняет историю вилок ... Если вы не хотите этого, вы можете просто слить вверх по течению в форк (думаю, не нужно выбирать вишню).

 22 июл. 2012 г., 13:39
Если вы не изменили файлы, они будут удалены во время восстановления. Если вы изменили их, у вас возникнет конфликт, который вам придется разрешить вручную.
 Steve Buzonas13 июн. 2012 г., 14:59
Если файлы были удалены в апстриме после разветвления и перед ребазингом, что произойдет, когда git применит изменения к этим файлам?
Решение Вопроса

Шаг 3: Настройте пульты& Quot; GitHub "Форк Репо" страница (я знаю, что вы не упомянули GitHub, но он все еще актуален)

origin is the remote address of your fork, that your local clone can pull from/push to upstream is the remote address of your original repo Skeleton (you can add it with a git remote add upstream https://..../Skeleton.git)

Таким образом, восходящий поток не является ветвью.

Но вы можете определить локальную ветвь, которая будет иметь для восходящей ветки удаленный мастер отслеживания веток из репозитория восходящего направления, смерзавец ветка:

git branch --set-upstream upstream_master upstream/master

Однако вам не нужен местный филиал, особенно если вы никогда не будете делать новые коммиты на нем: вы можете сравнить своего мастера сupstream/master непосредственно послеgit fetch upstreamсобирать вишню, что нужно отupstream/master.

 13 июн. 2012 г., 14:56
сразу послеremote add? Тебе необходимоgit fetch upstream во-первых, для ветки удаленного слеженияupstream/master быть доставленным и помещенным в ваш местный репо.git fetch не изменяет ни один из ваших локальных файлов.
 Steve Buzonas13 июн. 2012 г., 14:54
Это соответствовало тому, что я пытался сделать, что вызвало этот вопрос. Командаgit branch --set-upstream upstream_master upstream/master не будет работать сразу послеgit remote add upstream /srv/repos/git/skeleton.git, Это почему? Я случайно исправил проблему, пытаясь устранить неисправность. Я не хочу бежатьgit fetch upstream в моем главном рабочем дереве, но использование этого для устранения неполадок позволяет мне добавить удаленную ветвь отслеживания в upstream / master. Я предполагаю, что это потому, что удаленная ветвь upstream / master не находится в моем репо до того времени.

Ваш ответ на вопрос