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

Question

Я читал: 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

Перебазировать ветку разработки на новейшую версию Upstream

Чтобы поддерживать ветку разработкина сегодняшний день откатите ваши изменения поверх текущего состояния вышестоящего мастера.Смотрите что такое git-rebase?раздел ниже, чтобы узнать больше о перебазировании.

Если вы настроили ветку upstream, как описано выше, и ветку разработки под названием 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

Answer 1

Вики говорят с раздвоенной точки зрения репо. У вас есть доступ, чтобы тянуть и толкать от источника, который будет вашим форком основного репо диаспоры. Чтобы получить изменения из этого основного репо, вы добавляете удаленный «восходящий поток» в локальный репо, указывающий на этот оригинал и извлекающий его.

Итак, «origin» - это клон вашего репо-форка, из которого вы толкаете и тянете. «Upstream» - это название основного репо, откуда вы извлекаете и обновляете клон своего форка, но у вас нет к нему доступа с принудительным доступом.

Answer 2

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

Answer 3

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

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

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