Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

В принципе:

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

Вы можете увидеть иллюстрацию на git-rebase странице git-rebase с параграфом "ВОССТАНОВЛЕНИЕ ОТ UPSBREAM REBASE":

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

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

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

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

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

Ответ 3

Восходящий поток (связанный с) Отслеживание

Термин вверх по течению также имеет недвусмысленное значение, поскольку он входит в набор инструментов GIT, особенно относительно отслеживания

Например:

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

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

    >error: No upstream branch found for ''

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

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

   [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

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

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

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

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

   $ 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

теперь попробуйте (при условии, что "восходящий" пульт имеет ветвь "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 to. По умолчанию используется источник, если пульт не настроен. origin также используется, если вы не находитесь в какой-либо отрасли.

Upstream и Push (Gotcha)

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

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

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

Ответ 4

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

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

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

Термины не ограничены репозиториями Git.

Например, Ubuntu является производным Debian, поэтому Debian находится вверх по течению для Ubuntu.

Ответ 5

Входящий вред, вызванный вводом в эксплуатацию

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

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

фиксация, на которую указывает ваша ветка, была напрямую вверх по течению от youre на

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

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

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

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

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

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