Что помогает "git remote add upstream"?

Я читал на: https://wiki.diasporafoundation.org/Git_workflow#Rebase_your_development_branch_on_the_latest_upstream

вот выдержка:

ваш репозиторий обновлен

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

$ git remote add upstream git://github.com/diaspora/diaspora.git

Rebase вашей ветви развития на самом последнем Вверх по течению!--8-->

чтобы сохранить вашу ветку развития в актуальном состоянии, перебазируйте свои изменения сверху текущего состояния вышестоящего мастера. Вижу, что ГИТ-перебазироваться? раздел ниже, чтобы узнать больше о перебазирования.

если вы настроили восходящую ветвь, как описано выше, и ветка разработки под названием 100-retweet-bugfix, вы обновите вверх по течению, обновите локальный Мастер и перебазируйте свою ветку из него следующим образом:

$ git fetch upstream

$ git checkout master

$ git rebase upstream/master

$ git checkout 100-retweet-bugfix

[убедитесь, что все совершено по мере необходимости в филиале]

$ git rebase master

почему в этом случае требуется добавление "удаленного вверх по течению"? Не смогла я только что сделал:

$ git checkout master

$ git pull origin master

$ git checkout 100-retweet-bugfix

[убедитесь, что все совершено по мере необходимости в ветке]

$ git rebase master

3 ответов


Вики говорит с раздвоенной точки зрения РЕПО. У вас есть доступ к pull и push from origin, который станет вашей вилкой основного РЕПО диаспоры. Чтобы внести изменения из этого основного РЕПО, вы добавляете удаленный "вверх по течению" в локальном РЕПО, указывая на этот оригинал и вытаскивая из него.

Итак, "origin" - это клон вашего fork repo, из которого вы нажимаете и тянете. "Upstream" - это имя для основного РЕПО, из которого вы вытаскиваете и обновляете клон своей вилки, но вы этого не делаете имейте доступ к нему.


это полезно, если у вас есть свой origin Это не upstream. Другими словами, у вас может быть свой собственный origin РЕПО, что вы делаете разработку и локальные изменения, а затем иногда объединяете upstream изменения. Разница между вашим примером и выделенным текстом заключается в том, что в вашем примере предполагается, что вы работаете с клоном восходящего РЕПО напрямую. Выделенный текст предполагает, что вы работаете над клоном своего собственного РЕПО, который, предположительно, изначально был клоном восходящий поток.


Я думаю, что его можно использовать для "ретроактивно раздвоения"

Если у вас есть git РЕПО, и теперь решили, что он должен был еще раздвоенный РЕПО. Ретроактивно вы хотели бы, чтобы он стал вилкой, не нарушая команду, которая использует РЕПО, нуждаясь в них, чтобы нацелиться на новое РЕПО.

но я могу ошибаться.