나는 Git과 함께 연주하기 시작했고 "upstream"과 "downstream"이라는 용어를 접했다. 나는 이것들을 전에 보았지만 완전히 이해하지 못했습니다. SCM ( 소프트웨어 구성 관리 도구) 및 소스 코드와 관련하여 이러한 용어의 의미는 무엇입니까 ?

소스 제어 측면 에서 저장소에서 복제 (복제, 체크 아웃 등) 할 때 " 다운 스트림 "상태가됩니다. 정보가 "다운 스트림"으로 전달되었습니다.

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

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

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

git의 중요한 측면 중 하나는 분산되어 있으며 분산되어 있다는 것은 시스템에 고유 한 "업스트림"또는 "다운 스트림"이 없다는 것을 의미합니다.

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

"yourRepo"가 "otherRepo"를 원격으로 선언 한 경우 :

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

"from"과 "for"를 주목하십시오 : 당신은 단지 "다운 스트림"이 아니고, "다운 스트림 에서 / "로, 따라서 상대적인 측면입니다.

DVCS (Distributed Version Control System) 트위스트는 다음과 같습니다. 선언 한 원격 저장소와 관련하여 자신의 저장소 외에 실제로 다운 스트림이 무엇인지 전혀 모릅니다.

• 업스트림이 무엇인지 알고있다
• 다운 스트림이 무엇인지 알 수 없습니다 (다른 저장소는 저장소 에서 당기거나 밀어 넣기 ).

원래:

" 데이터 흐름 "의 용어로 , 리포지토리는 업스트림 리포지토리 ( "풀에서")에서 나오는 플로우의 맨 아래 ( "다운 스트림")에 있으며 (동일 또는 다른) 업스트림 리포지토리 ( "푸시")로 돌아갑니다. ).

git-rebase맨 페이지 에서 "UPSTREAM REBASE에서 복구"단락이 있는 그림을 볼 수 있습니다 .

즉 , 리베이스가 발생한 "업스트림"리포지토리에서 가져 오고 있고, "다운 스트림"리포지토리는 결과와 멈춰 있습니다. 로컬로).

하나의 "업스트림" 리포지토리 에는 많은 다운 스트림 리포지토리 (즉, 리베이스 브랜치가있는 업스트림 리포지토리에서 가져 오는 리포지토리) 가있을 수 있으므로 모두 중복 커밋을 처리해야 하기 때문에 좋지 않습니다 .

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

참고 : 이것은 데이터에만 국한되지 않습니다. git 명령 (예 : "porcelain"명령)이 내부적으로 다른 git 명령 ( "배관 식"명령)을 호출
하기 때문에 parameters에도 적용됩니다 . 참조 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(당신의 갈래의 repo에 github) 및 upstream(당신이 포크 한 github의 repo). 그것들은 단지 상호 교환 가능한 이름이며 '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} 의 의미는 독특합니다.

이것은 ' 원격 저장소' 의 ' 지점' (있는 경우) 이며 '로컬 저장소' 의 '현재 지점' 을 추적합니다 .

인수없이 일반 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에게 어느 원격에서 페치 / 푸시할지 알려줍니다. 원격이 구성되지 않은 경우 기본적으로 출발지입니다. 분기가없는 경우에도 origin이 사용됩니다.

업스트림 및 푸시 (Gotcha)

한 번 봐 걸릴 git-config(1)매뉴얼 페이지를

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

이것은 아직 푸시 할 준비가되지 않은 지점에 실수로 푸시하는 것을 방지하기위한 것입니다.

그것은 약간의 비공식적 인 용어입니다.

Git에 관한 한, 다른 모든 저장소는 단지 원격입니다.

일반적으로 업스트림은 (원점)에서 복제 한 곳입니다. 다운 스트림은 작업을 다른 작업과 통합하는 모든 프로젝트입니다.

이 용어는 Git 리포지토리로 제한되지 않습니다.

예를 들어, 우분투는 데비안 파생물이므로 데비안은 우분투 업스트림입니다.

상류층에 유해 함

아아, 여기에 다른 답변이 얻지 못하는 "업스트림"의 또 다른 사용이 있습니다. 즉, 레포 내에서 커밋의 부모-자식 관계를 나타냅니다. Pro Git 책 의 Scott Chacon 은 특히 ​​이런 경향이 있으며 결과는 불행합니다. 이 말을 흉내 내지 마십시오.

예를 들어, 그는 합병으로 인해이 문제가 빨리 발생한다고 말합니다.

병합 한 브랜치가 가리키는 커밋은 현재 커밋의 업스트림입니다.

그는 커밋 B가 커밋 A의 유일한 자식 중 유일한 자식의 유일한 자식이라고 말하고 싶습니다. 따라서 B를 A로 병합하기 위해서는 심판 A가 B를 커밋하도록 이동하는 것으로 충분합니다. "하류"라기보다는 "상류"라 칭해야하거나, 그러한 순수한 직선 그래프의 기하학적 구조가 "직접 상류"로 설명되어야하는 이유가 완전히 불분명하고 임의적 일 수있다. (맨 페이지 git-merge는 "현재 브랜치 헤드가 커밋의 조상"이라고 말할 때이 관계를 훨씬 잘 설명합니다. 이것이 Chacon이 말한 것입니다.)

실제로, Chacon 자신은 삭제 된 커밋에 대한 모든 자식 커밋을 다시 작성할 때 "다운 스트림"을 사용하여 동일한 것을 의미합니다.

Git 히스토리에서이 파일을 완전히 제거하려면 6df76부터 다운 스트림의 모든 커밋을 다시 작성해야합니다.

기본적으로 그는 시간이 지남에 따른 커밋의 역사를 언급 할 때 "업스트림"과 "다운 스트림"이 무엇을 의미하는지에 대한 명확한 아이디어를 가지고 있지 않은 것 같습니다. 이 사용은 비공식적이며 혼란 스럽기 때문에 권장하지 않습니다.

모든 커밋 (하나를 제외하고)에는 적어도 하나의 부모가 있으며, 따라서 부모의 부모는 조상이라는 것이 완벽합니다. 다른 방향으로, 커밋에는 자녀와 자손이 있습니다. 그것은 용어로 받아 들여지고, 그래프의 방향성을 모호하지 않게 설명하므로, repo의 그래프 지오메트리 내에서 커밋이 서로 어떻게 관련되는지 설명하려고 할 때 이야기하는 방법입니다. 이 상황에서 "업스트림"또는 "다운 스트림"을 느슨하게 사용하지 마십시오.

[추가 정보 : 위에서 언급 한 첫 번째 Chacon 문장과 git-merge맨 페이지 사이의 관계에 대해 생각 하고 있는데, 전자가 후자의 오해에 기초한 것일 수 있습니다. 맨 페이지는 "업스트림"사용이 합법적 인 상황을 설명하기 위해 계속 진행됩니다. "업스트림 저장소를 추적하고 로컬 변경 사항을 커밋하지 않았으며 이제 새로운 버전으로 업데이트하려고 할 때 빨리 감기가 종종 발생합니다. 업스트림 개정. " 아마도 Chacon은 맨 페이지에서 "업스트림"을 보았을 것입니다. 그러나 매뉴얼 페이지에는 원격 저장소가 있습니다. Chacon의 빠른 전달에 대한 예에는 원격 저장소가 없으며, 로컬로 생성 된 지점 몇 개만 있습니다.]