it-swarm.com.ru

Определение «вниз по течению» и «вверх по течению»

Я начал играть с Git и столкнулся с терминами "upstream" и "downstream". Я видел это раньше, но никогда не понимал их полностью. Что означают эти термины в контексте SCM ( Software Configuration Management tools) и исходного кода?

812
brendan

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

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

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

630
brian d foy

Когда вы читаете в git tag man page :

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

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

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

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

Обратите внимание на "from" и "for": вы не просто "downstream", вы "downstream from/for ", отсюда и относительный аспект.


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

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

В принципе:

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


Вы можете увидеть иллюстрацию в git-rebase man page с параграфом "ВОССТАНОВЛЕНИЕ ОТ ИСПОЛЬЗОВАНИЯ UPSTREAM":

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

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

Опять же, по аналогии с "потоком данных", в DVCS одна плохая команда "upstream" может иметь " волновой эффект " downstream .


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

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

219
VonC

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

Термин upstream также имеет некоторое недвусмысленное значение, как и набор инструментов 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/configreads:

   [remote "Origin"]
       fetch = +refs/heads/*:refs/remotes/Origin/*
       url = [email protected]:myusername/reponame.git
   [remote "upstream"]
       fetch = +refs/heads/*:refs/remotes/upstream/*
       url = [email protected]:authorname/reponame.git
  • С другой стороны, значение @ {upstream} для GIT уникально:

это "ветвь" (если есть) на "указанный удаленный" , который отслеживает "текущую ветку" в "локальном хранилище" .

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

Допустим, вы хотите установить удаленную ветку Origin/master в качестве ветви отслеживания для локальной ветки 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

Для каждой ветки, которая актуальна или успешно отправлена, добавьте upstream (tracking) ссылку, используемую 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 to. По умолчанию используется Origin, если пульт не настроен. Источник также используется, если вы не находитесь ни на одной ветке.

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

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

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

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

81
Peter Host

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

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

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

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

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

52
hasen

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

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

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

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

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

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

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

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

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

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

48
matt