Я почав грати з Git і натрапив на терміни "upstream" та "downstream". Я бачив їх раніше, але ніколи не розумів їх повністю. Що означають ці терміни в контексті SCM ( інструментів управління конфігурацією програмного забезпечення ) та вихідного коду?

Що стосується контролю над джерелами, ви перебуваєте " нижче за течією ", коли копіюєте (клонуєте, отримуєте заявку тощо) із сховища. Інформація надходила до вас "за течією".

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

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

Коли ви читаєте на git tagсторінці man :

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

, це просто означає, що немає абсолютного репо або вище за течією.
Ці поняття завжди відносні між двома репортажами і залежать від способу потоку даних:

Якщо "yourRepo" оголосив "otherRepo" як віддалений, тоді :

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

Зауважте "від" і "за": ви не просто "нижче за течією", ви "нижче за / за ", отже, відносний аспект.

Поворот DVCS (розподіленої системи управління версіями) полягає в тому, що ви не маєте поняття, що насправді знаходиться за течією, поряд із вашим власним репо, відносно віддалених репостів, про які ви заявили.

• ви знаєте, що таке вище (за репост, з якого ви тягнете або підштовхуєте)
• ви не знаєте, з чого складається з нижньої течії (інші репости тягнуться до вашого репо або натискають на нього ).

В основному:

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

Ілюстрацію ви можете побачити на git-rebaseсторінці чоловіка з абзацом "ВІДНОВЛЕННЯ З ВИПУСКУВАННЯ":

Це означає, що ви витягуєте з репо-версії "вище за течією", де відбулася база даних , і ви ("репо" вниз за течією) застрягли з наслідком (багато дублікатів комітетів, тому що гілка, яка перезавантажена вгору за течією, відтворила комісії тієї ж гілки, яку ви мати місцево).

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

Знову ж таки, за аналогією "потік даних" у DVCS одна погана команда "вище за течією" може мати " ефект пульсації " вниз за течією.

Примітка. Це не обмежується даними.
Це стосується також параметрів , оскільки команди git (як "порцелянові") часто викликають внутрішньо інші команди git ("сантехнічні"). Переглянути rev-parseсторінку чоловіка :

Багато порцелянових команд git містять суміш прапорів (тобто параметрів, які починаються з тире ' -') та параметрів, призначених для основної 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 віддаленої гілки як гілку відстеження для локальної гілки 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

Коли в гілці <ім'я>, вона повідомляє git fetch та git push, який віддалений для отримання / push для. За замовчуванням він походить за замовчуванням, якщо не налаштований пульт. Походження також використовується, якщо ви не перебуваєте на жодній гілці.

Вгору і поштовх (Gotcha)

подивіться на git-config(1)сторінку вручну

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

Це запобігає випадковим натисканням на гілки, які ви ще не готові штовхати.

Це трохи неформальної термінології.

Що стосується Git, то кожен інший сховище - лише віддалений.

Взагалі, вище за течією - це те, звідки ви клонувались (походження). Нижче за течією - будь-який проект, який інтегрує вашу роботу з іншими роботами.

Умови не обмежуються лише сховищами Git.

Наприклад, Ubuntu є похідною Debian, тому Debian є вище для Ubuntu.

Вище називається шкідливим

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

Наприклад, він говорить про злиття, що призводить до швидкого перемоги вперед, що це відбувається тому, що

комісія, на яку вказує філія, в яку ви злилися, знаходилася безпосередньо над потоком комітету, на який ви працюєте

Він хоче сказати, що команда B є єдиною дитиною єдиної дитини ... єдиної дитини, яка здійснила A, тому для злиття B в A достатньо перемістити ref A в точку, щоб здійснити B. Чому цей напрямок слід називати "вище за течією", а не "вниз за течією", або чому геометрію такого чистого прямолінійного графіка слід описати "безпосередньо вгору за течією", є абсолютно незрозумілим і, ймовірно, довільним. (Сторінка людини для git-mergeробить набагато кращу роботу з пояснення цього взаємозв'язку, коли йдеться про те, що "нинішній керівник відділення є родоначальником названого комітету". Це те, що повинен був сказати Шакон.)

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

Щоб повністю видалити цей файл із історії Git, ви повинні переписати всі зобов’язання нижче за темою 6df76

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

Цілком зрозуміло, що кожен вчинок (крім одного) має принаймні одного з батьків, і що батьки батьків, таким чином, є предками; а в іншому напрямку коміти мають дітей та нащадків. Це прийнята термінологія і однозначно описує спрямованість графа, тому це спосіб розмови, коли ви хочете описати, як коміти ставляться один до одного в межах геометрії графіка репо. У цій ситуації не використовуйте вільно "вище" або "за течією".

[Додаткова примітка: Я думав про взаємозв'язок між першим реченням Шакона, яке я цитую вище, та git-mergeсторінкою man, і мені здається, що перше може базуватися на нерозумінні другого. Сторінка "man" продовжує описувати ситуацію, коли використання "upstream" є законним: швидке переадресація часто трапляється, коли "ви відстежуєте сховище висхідного потоку, ви не ввели місцевих змін, і тепер ви хочете оновити до новішого. перегляд вище за течією. " Тож, можливо, Чакон використовував "вище за течією", тому що він бачив це тут, на сторінці людини. Але на сторінці man є віддалене сховище; у наведеному прикладі швидкого переадресації Chacon немає віддаленого сховища, лише кілька локально створених гілок.]