Я начал играть с Git и столкнулся с терминами «upstream» и «downstream». Я видел это раньше, но никогда не понимал их полностью. Что означают эти термины в контексте SCM ( инструменты управления конфигурацией программного обеспечения ) и исходного кода?

С точки зрения контроля над исходным кодом вы находитесь в нисходящем направлении, когда копируете (клонирование, извлечение и т. Д.) Из хранилища. Информация текла «вниз по течению» к вам.

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

Иногда вы читаете о менеджерах пакетов или релизов (люди, а не инструмент), говорящих о том, как отправить изменения в «апстрим». Обычно это означает, что им нужно было настроить исходные источники, чтобы они могли создать пакет для своей системы. Они не хотят продолжать вносить эти изменения, поэтому, если они отправят их «вверх по течению» в первоисточник, им не придется сталкиваться с той же проблемой в следующем выпуске.

Когда вы читаете на git tagстранице руководства :

Одним из важных аспектов git является то, что он распространяется, и его распространение в значительной степени означает, что в системе нет присущих «вверх по течению» или «вниз по течению».

, что просто означает, что не существует абсолютного обратного или обратного репо.
Эти понятия всегда являются относительными между двумя репозиториями и зависят от способа передачи данных:

Если «yourRepo» объявил «otherRepo» удаленным, то :

• Вы вытягиваете из «другого» Репо вверх по течению («ДругоеРепо» означает «по восходящему потоку от вас», и вы «по течению к другомуРепо»).
• вы подталкиваете к восходящему потоку («otherRepo» по-прежнему является «восходящим», куда теперь возвращается информация).

Обратите внимание на «от» и «для»: вы не просто «ниже по течению», вы «ниже по течению от / для », отсюда и относительный аспект.

Суть DVCS (распределенной системы управления версиями) такова: вы не представляете, что на самом деле представляет собой нисходящий поток, кроме вашего собственного репо относительно объявленных вами удаленных репо.

• Вы знаете, что вверх по течению (репо, из которого вы тянете или толкаете)
• Вы не знаете, из чего сделан нисходящий поток (другие репо тянут или тянут к вашему репо ).

В принципе:

С точки зрения « потока данных », ваше репо находится в нижней части («нисходящего») потока, идущего из репозиториев в восходящем направлении («извлекать из») и возвращающегося к (тому же или другому) репозиториям в восходящем направлении («толчок в») ).

Вы можете увидеть иллюстрацию в git-rebaseсправочной странице руководства с параграфом «ВОССТАНОВЛЕНИЕ ОТ РЕБАЗЫ UPSTREAM»:

Это означает, что вы вытаскиваете из репо «вверх по течению», в котором произошла перебазировка , и вы (репо «вниз по течению») застряли со следствием (множество дублирующих коммитов, потому что ветвь, перебазированная вверх по течению, воссоздала коммиты той же ветки, что и вы. есть локально).

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

Опять же, по аналогии с «потоком данных», в DVCS одна плохая команда «вверх по потоку» может иметь « волновой эффект » вниз по потоку.

Примечание: это не ограничивается данными.
Это также относится к параметрам , так как команды git (например, «фарфоровые») часто вызывают внутри себя другие команды git («соединительные»). Смотрите rev-parseсправочную страницу :

Многие команды git porcelainish принимают смесь флагов (то есть параметров, начинающихся с тире ' -) и параметров, предназначенных для базовой git rev-listкоманды, которую они используют внутри, и флагов и параметров для других команд, которые они используют ниже по потокуgit rev-list . Эта команда используется для различения между ними.

Отслеживание вверх по течению (в связи с)

Термин « восходящий поток» также имеет однозначное значение, поскольку он относится к набору инструментов GIT, особенно в отношении отслеживания.

Например :

   $git rev-list --count --left-right "@{upstream}"...HEAD
   >4   12

напечатает (последнее кэшированное значение) количество коммитов позади (слева) и впереди (справа) вашей текущей рабочей ветви, относительно ( если есть ) отслеживающей в данный момент удаленной ветви для этой локальной ветви. В противном случае будет напечатано сообщение об ошибке:

    >error: No upstream branch found for ''

• Как уже было сказано, у вас может быть любое количество удаленных устройств для одного локального репозитория, например, если вы разветвляете репозиторий из github, а затем выполняете «запрос на извлечение», у вас наверняка есть как минимум два: origin(ваш разветвленный репозиторий включен github) и upstream(репозиторий на github, с которого вы ответили). Это просто взаимозаменяемые имена, их идентифицирует только URL «git @ ...».

Ваш .git/configчитает:

   [remote "origin"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = git@github.com:myusername/reponame.git
   [remote "upstream"]
       fetch = +refs/heads/*:refs/remotes/upstream/*
       url = git@github.com:authorname/reponame.git

• С другой стороны, значение @ {upstream} для GIT уникально:

это «ветвь» (если есть) на «указанном удаленном» , которая отслеживает «текущую ветвь» в вашем «локальном хранилище» .

Это ветвь, которую вы выбираете / извлекаете всякий раз, когда вы запускаете обычный git fetch/ git pullбез аргументов.

Допустим, вы хотите установить источник / мастер удаленной ветви как ветвь отслеживания для локальной ветки master, которую вы извлекли. Просто выпустите:

   $ git branch --set-upstream  master origin/master
   > Branch master set up to track remote branch master from origin.

Это добавляет 2 параметра в .git/config:

   [branch "master"]
       remote = origin
       merge = refs/heads/master

Теперь попробуйте (при условии, что удаленный «upstream» имеет ветку «dev»)

   $ git branch --set-upstream  master upstream/dev
   > Branch master set up to track remote branch dev from upstream.

.git/config сейчас читает:

   [branch "master"]
       remote = upstream
       merge = refs/heads/dev

git-push(1)Страница руководства :

   -u
   --set-upstream

Для каждой ветки, которая обновлена ​​или успешно отправлена, добавьте ссылку вверх по течению (отслеживание) , используемую git-pull (1) без аргументов и другими командами. Для получения дополнительной информации см. branch.<name>.mergeВ git-config (1).

git-config(1)Страница руководства :

   branch.<name>.merge

Определяет, вместе с branch.<name>.remote, то выше по течению отделение для данной отрасли. Он сообщает git fetch / git pull / git rebase, какую ветку объединять, а также может влиять на git push (см. Push.default). \ (...)

   branch.<name>.remote

Находясь в ветке <name>, он сообщает git fetch и git push, с какого пульта следует выбрать / push. По умолчанию используется источник, если пульт не настроен. origin также используется, если вы не находитесь ни на одной ветке.

Вверх по течению и толчок (Gotcha)

взгляните на git-config(1)страницу руководства

   git config --global push.default upstream
   git config --global push.default tracking  (deprecated)

Это сделано для предотвращения случайных толчков к ветвям, которые вы еще не готовы нажать.

Это немного неформальной терминологии.

Что касается Git, то все остальные репозитории - это просто удаленные.

Вообще говоря, вверх по течению это то место, откуда вы клонировали (источник). Downstream - это любой проект, который объединяет вашу работу с другими работами.

Условия не ограничиваются репозиториями Git.

Например, Ubuntu является производной от Debian, поэтому Debian является основной веткой разработки для Ubuntu.

Вверх по течению называется вредным

Увы, существует еще одно использование «восходящего потока», на которое другие ответы здесь не нахо- дятся, а именно для ссылки на родительские и дочерние отношения коммитов в репо. Скотт Чакон в книге о Pro Git особенно склонен к этому, и результаты неутешительны. Не подражайте такому разговору.

Например, он говорит о слиянии в результате ускоренной перемотки, что это происходит потому, что

коммит, на который указывает ветка, в которую вы вошли, был непосредственно перед коммитом, на котором вы находитесь

Он хочет сказать, что коммит B является единственным потомком единственного потомка ... единственного потомка коммита A, поэтому для слияния B с A достаточно указать ссылку A, чтобы указать на коммит B. Почему это направление следует называть «восходящим», а не «нисходящим», или почему геометрия такого чисто линейного графа должна быть описана «непосредственно вверх по течению», совершенно неясно и, вероятно, произвольно. (Страница git-mergeсправочника для гораздо лучше объясняет эту взаимосвязь, когда говорит, что «текущая глава ветки является предком именованного коммита. Так Чакон должен был сказать.)

Действительно, сам Чакон, по-видимому, позже использует «нижестоящий», чтобы обозначать то же самое, когда говорит о переписывании всех дочерних коммитов удаленного коммита:

Вы должны переписать все коммиты вниз по течению от 6df76, чтобы полностью удалить этот файл из вашей истории Git

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

Совершенно очевидно, что каждый коммит (кроме одного) имеет хотя бы одного родителя, и что родители родителей, таким образом, являются предками; а в другом направлении коммиты имеют детей и потомков. Это принятая терминология, и она однозначно описывает направленность графа, так что это способ говорить, когда вы хотите описать, как коммиты связаны друг с другом в геометрии графа репо. В этой ситуации не используйте свободно вверх или вниз по течению.

[Дополнительное примечание: я размышлял о связи между первым предложением Чакона, которое я цитирую выше, и git-mergeстраницей руководства , и мне приходит в голову, что первое может быть основано на неправильном понимании последнего. Страница man продолжает описывать ситуацию, в которой использование «upstream» является законным: быстрая перемотка часто происходит, когда «вы отслеживаете репозиторий upstream, вы не зафиксировали локальных изменений, и теперь вы хотите перейти на более новую версию». редакция вверх по течению. " Так что, возможно, Чакон использовал «upstream», потому что он видел это здесь на странице руководства. Но на странице руководства есть удаленный репозиторий; в приведенном Чаконе примере быстрой пересылки нет удаленного репозитория, только пара локально созданных веток.]

В основном;

• вверх по течению к источнику
• вниз по течению к раковине или месту назначения

Это относится ко всем древовидным системам, включая системы контроля версий.