"다운 스트림"및 "업스트림"의 정의

"다운 스트림"및 "업스트림"의 정의

---

저는 Git으로 플레이하기 시작했고 "업스트림"과 "다운 스트림"이라는 용어를 접했습니다. 나는 이것을 전에 보았지만 완전히 이해하지 못했습니다. SCM ( 소프트웨어 구성 관리 도구) 및 소스 코드 의 맥락에서 이러한 용어는 무엇을 의미 합니까?

---

소스 제어 측면 에서 저장소에서 복사 (복제, 체크 아웃 등) 할 때 " 다운 스트림 "입니다. 정보는 "다운 스트림"으로 사용자에게 전달되었습니다.

변경 사항을 적용 할 때 일반적으로 " 업스트림 "으로 다시 보내 동일한 소스에서 가져온 모든 사람이 동일한 변경 사항을 모두 적용 할 수 있도록 해당 저장소로 만들도록합니다. 이것은 소스 제어의 기술적 요구 사항이 아니라 모든 사람이 작업을 조정할 수있는 방법에 대한 대부분의 사회적 문제입니다. 주요 프로젝트에 변경 사항을 적용하여 다양한 개발 라인을 추적하지 않으려 고합니다.

때때로 "업스트림"에 변경 사항을 제출하는 것에 대해 이야기하는 패키지 또는 릴리스 관리자 (도구가 아닌 사람)에 대해 읽을 수 있습니다. 이는 일반적으로 시스템 용 패키지를 만들 수 있도록 원본 소스를 조정해야 함을 의미합니다. 그들은 이러한 변경을 계속하고 싶지 않기 때문에 원본 소스에 "업스트림"을 보내면 다음 릴리스에서 동일한 문제를 처리 할 필요가 없습니다.

---

git tag맨 페이지 에서 읽을 때 :

git의 중요한 측면 중 하나는 배포된다는 것입니다. 배포된다는 것은 시스템에 고유 한 "업스트림"또는 "다운 스트림"이 없다는 것을 의미합니다.

, 이는 단순히 절대 업스트림 리포지토리 또는 다운 스트림 리포지토리 가 없음을 의미 합니다. 이러한 개념은 항상 두 저장소간에 상대적이며 데이터 흐름 방식에 따라 다릅니다.

"yourRepo"가 "otherRepo"를 원격으로 선언 한 경우 다음을 수행합니다 .

• 당신이하는 상류에서 당겨 ( "상류"otherRepo ""otherRepo " 에서 당신", 당신은 "다운 스트림 에 대한 otherRepo").
• 업스트림 으로 밀고 있습니다 ( "otherRepo"는 여전히 "업스트림"이며 정보는 이제 다시 돌아갑니다).

"from"과 "for"에 주목하세요 : 당신은 단지 "downstream"이 아니라 "downstream from / for "이기 때문에 상대적인 측면입니다.

---

DVCS (Distributed Version Control System) 트위스트는 다음과 같습니다. 선언 한 원격 리포지토리와 관련된 자신의 리포지토리 외에 다운 스트림이 실제로 무엇인지 알 수 없습니다.

• 업스트림이 무엇인지 알고 있습니다 (끌거나 밀고있는 저장소).
• 당신은 다운 스트림 (다른 REPOS에서 잡아 당기거나에 밀어 구성되어 모르는 당신의 repo ).

원래:

" 데이터 흐름 "이라는 용어로 , 리포지토리는 업스트림 리포지토리에서 오는 ( "풀에서") 업스트림 리포지토리로 돌아가는 (동일하거나 다른) 업스트림 리포지토리 ( "푸시")의 맨 아래 ( "다운 스트림")에 있습니다. ).

---

git-rebase매뉴얼 페이지 에서 "RECOVERING FROM UPSTREAM REBASE"단락이 있는 그림을 볼 수 있습니다 .

그것은 당신이 rebase가 일어난 "upstream"repo에서 당기고 있다는 것을 의미 하고, 당신 ( "downstream"repo)은 그 결과 (많은 중복 커밋이 멈췄습니다. 왜냐하면 브랜치가 당신과 동일한 브랜치의 커밋을 다시 생성했기 때문입니다) 로컬로).

하나의 "업스트림" 리포지토리에 대해 다운 스트림 리포지토리 가 많을 수 있기 때문에 (즉, 리베이스 브랜치를 사용하여 업스트림 리포지토리에서 가져 오는 리포지토리) 모두 잠재적으로 중복 커밋을 처리해야합니다.

다시 말하지만, DVCS에서 "데이터 흐름"비유를 사용하면 하나의 잘못된 명령 "업스트림"이 다운 스트림 " 파급 효과 "를 가질 수 있습니다 .

---

참고 : 이것은 데이터에 국한되지 않습니다. git 명령 (예 : "도자기"명령)은 종종 내부적으로 다른 git 명령 ( "plumbing"명령)을 호출하므로
매개 변수에도 적용됩니다 . 참조 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에서 저장소를 포크 한 다음 'pull 요청'을 발행하면 가장 확실하게 최소한 두 개가 있습니다. origin(forked repo on github) 및 upstream(당신이 분기 한 github의 저장소). 그것들은 교환 가능한 이름 일 뿐이며 'git @ ...'URL로만 식별됩니다.

당신의 .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

• 반면 에 GIT에 대한 @ {upstream} 의 의미는 고유합니다.

그것은이다 '분기' (있는 경우)에 '원격 말했다 추적하는, '현재의 지점 ' 온 '로컬 저장소를 ' .

It's the branch you fetch/pull from whenever you issue a plain git fetch/git pull, without arguments.

Let's say want to set the remote branch origin/master to be the tracking branch for the local master branch you've checked out. Just issue :

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

This adds 2 parameters in .git/config :

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

now try (provided 'upstream' remote has a 'dev' branch)

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

.git/config now reads:

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

git-push(1) Manual Page :

   -u
   --set-upstream

For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config(1).

git-config(1) Manual Page :

   branch.<name>.merge

Defines, together with branch.<name>.remote, the upstream branch for the given branch. It tells git fetch/git pull/git rebase which branch to merge and can also affect git push (see push.default). \ (...)

   branch.<name>.remote

When in branch < name >, it tells git fetch and git push which remote to fetch from/push to. It defaults to origin if no remote is configured. origin is also used if you are not on any branch.

Upstream and Push (Gotcha)

take a look at git-config(1) Manual Page

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

This is to prevent accidental pushes to branches which you’re not ready to push yet.

---

That's a bit of informal terminology.

As far as Git is concerned, every other repository is just a remote.

Generally speaking, upstream is where you cloned from (the origin). Downstream is any project that integrates your work with other works.

The terms are not restricted to Git repositories.

For instance, Ubuntu is a Debian derivative, so Debian is upstream for Ubuntu.

---

Upstream Called Harmful

There is, alas, another use of "upstream" that the other answers here are not getting at, namely to refer to the parent-child relationship of commits within a repo. Scott Chacon in the Pro Git book is particularly prone to this, and the results are unfortunate. Do not imitate this way of speaking.

For example, he says of a merge resulting a fast-forward that this happens because

the commit pointed to by the branch you merged in was directly upstream of the commit you’re on

He wants to say that commit B is the only child of the only child of ... of the only child of commit A, so to merge B into A it is sufficient to move the ref A to point to commit B. Why this direction should be called "upstream" rather than "downstream", or why the geometry of such a pure straight-line graph should be described "directly upstream", is completely unclear and probably arbitrary. (The man page for git-merge does a far better job of explaining this relationship when it says that "the current branch head is an ancestor of the named commit." That is the sort of thing Chacon should have said.)

Indeed, Chacon himself appears to use "downstream" later to mean exactly the same thing, when he speaks of rewriting all child commits of a deleted commit:

You must rewrite all the commits downstream from 6df76 to fully remove this file from your Git history

Basically he seems not to have any clear idea what he means by "upstream" and "downstream" when referring to the history of commits over time. This use is informal, then, and not to be encouraged, as it is just confusing.

It is perfectly clear that every commit (except one) has at least one parent, and that parents of parents are thus ancestors; and in the other direction, commits have children and descendants. That's accepted terminology, and describes the directionality of the graph unambiguously, so that's the way to talk when you want to describe how commits relate to one another within the graph geometry of a repo. Do not use "upstream" or "downstream" loosely in this situation.

[Additional note: I've been thinking about the relationship between the first Chacon sentence I cite above and the git-merge man page, and it occurs to me that the former may be based on a misunderstanding of the latter. The man page does go on to describe a situation where the use of "upstream" is legitimate: fast-forwarding often happens when "you are tracking an upstream repository, you have committed no local changes, and now you want to update to a newer upstream revision." So perhaps Chacon used "upstream" because he saw it here in the man page. But in the man page there is a remote repository; there is no remote repository in Chacon's cited example of fast-forwarding, just a couple of locally created branches.]

참고URL : https://stackoverflow.com/questions/2739376/definition-of-downstream-and-upstream