Git 브랜칭 : 마스터 vs. 오리진 / 마스터 vs. 리모트 / 오리진 / 마스터

Programing

Git 브랜칭 : 마스터 vs. 오리진 / 마스터 vs. 리모트 / 오리진 / 마스터

crosscheck 2020. 5. 15. 20:57

Git 브랜칭 : 마스터 vs. 오리진 / 마스터 vs. 리모트 / 오리진 / 마스터

git의 기본 개념을 이해하기 위해 올바른 길을 가고 있다고 생각합니다.

이미 원격 저장소를 설정하고 복제했습니다. 또한 서버 측 빈 저장소를 작성하고 로컬 저장소를 링크했습니다.

내 문제는 다음의 차이점을 이해하지 못한다는 것입니다.

원산지 / 마스터 대 리모컨 / 원산지 / 마스터

내가 아는 한 master 는 로컬 브랜치이며 remotes / origin / master 는 원격 브랜치 입니다.

그러나 origin / master 는 정확히 무엇 입니까?

원격 저장소의 복제본을 가져 와서 실행하십시오 git branch -a(git이 알고있는 모든 분기를 표시하십시오). 아마도 다음과 같이 보일 것입니다 :

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

여기서, master로컬 저장소에 지점입니다. remotes/origin/master는 master원격에 이름이 지정된 지점 origin입니다. 다음과 같이이 중 하나를 참조 할 수 있습니다 origin/master.

git diff origin/master..master

다음과 같이 참조 할 수도 있습니다 remotes/origin/master.

git diff remotes/origin/master..master

이것들은 똑같은 것을 언급하는 두 가지 다른 방법입니다 (우연히이 두 명령은 "원격 master지사와 지사 사이의 변경 사항을 보여줍니다" master).

remotes/origin/HEAD는 default branch리모컨의 origin입니다. 이를 통해 단순히 origin대신 말할 수 있습니다 origin/master.

나 같은 인형에 대한 짧은 대답 (Torek에서 도난당한) :

원산지 / 마스터 는 "마지막으로 확인했을 때 마스터가있는 위치"입니다.
스승님 은 "내가 한 일을 바탕으로 스승님이 계신 곳입니다"

기술적으로 실제로 "원격"전혀 일이없는 ^한 귀하 힘내의 repo에서이,이 단지 지역의 이름을 해야 다른에 이름, 다른 REPO에 해당합니다. 이름 origin/whatever이 지정된 것은 처음에 복제 한 리포지토리의 이름 과 일치합니다.

git clone ssh://some.where.out.there/some/path/to/repo # or git://some.where...

다른 저장소의 로컬 사본을 만듭니다. 그 길을 따라 그곳에 있던 모든 지점과 그 커밋을 참조하고 이름으로 로컬 리포지토리에 붙 refs/remotes/origin/입니다.

당신이 가기 전에 얼마나 오래 git fetch또는 "그것의 some.where.out.there의 나의 사본"을 업데이트하기 위해 동등한 에 따라 , 그들은 그들의 가지를 변경하고, 새로운 것을 만들고, 일부를 삭제할 수 있습니다. 당신이 할 때 git fetch(또는 git pull실제로 가져 오기 및 병합 인 경우), repo는 새로운 작업의 사본을 만들고 refs/remotes/origin/<name>필요에 따라 모든 항목을 변경 합니다. fetch모든 것이 일치하게되는 것은 바로 그 순간입니다 (물론, 초기 복제본과 일부 복제 push도 기본적으로 Git이 확인할 기회가있을 때마다 아래의 경고를 참조하십시오).

Git은 일반적으로 자신 refs/heads/<name>을 just로 <name>, 원격 것을로 지칭 하며 origin/<name>, 어느 것이 어느 것이 분명하기 때문에 모두 작동합니다. 때로는 명확하지 않은 자체 브랜치 이름을 만들 수도 있지만 그럴 때까지 걱정하지 않아도됩니다. :-) 그냥 Git에게 가장 짧은 이름을 지어 주면, 거기에서 갈 것입니다. origin/master"마지막 내가 확인한 시간 master에 마스터가 어디에 있었는지", "내가 한 일을 바탕으로 마스터가 여기에있었습니다" . git fetch필요에 따라 "마스터가있는 위치"에서 Git을 업데이트하려면 실행하십시오 .

주의 사항 : 1.8.4 이전의 Git 버전 git fetch에는 "마스터가있는 위치"를 업데이트하지 않는 일부 모드 (더 정확하게는 원격 추적 분기를 업데이트하지 않는 모드)가 있습니다. 실행 git fetch origin하거나 git fetch --all, 또는 단지 git fetch, 않습니다 업데이 트를. 실행 git fetch origin master 하지 않습니다 . 불행하게도,이 "업데이트하지 않음"모드는 일반에 의해 트리거됩니다 git pull. (이것은 주로 사소한 성가심이며 Git 1.8.4 이상에서 수정되었습니다.)

¹ 음,되는 한 가지가있다 라고 는 "원격". 그러나 그것은 또한 지역적입니다! 이름 origin은 Git이 "원격"이라고 부르는 것입니다. 기본적으로 복제를 수행 할 때 사용한 URL의 짧은 이름입니다. 또한 origin안으로 origin/master오는 곳이기도합니다 . 이 이름을 원격 추적 분기origin/master 라고하며 , 특히 이전 또는보다 비공식적 인 문서에서 "원격 분기"로 단축되는 경우가 있습니다.

초보자를 위해 @ErichBSchulz의 답변을 더 단순하게 만들려고합니다.

origin / master 는 원격 저장소의 마스터 브랜치 상태입니다.
master 는 로컬 저장소의 마스터 브랜치 상태입니다.

origin- 원격을 가리키는 사용자 지정 및 가장 일반적인 이름입니다.

$ git remote add origin https://github.com/git/git.git---이 명령을 실행하여 github 프로젝트를 원점에 연결합니다. 여기서 원점은 사용자 정의입니다. 이름을 바꿀 수 있습니다$ git remote rename old-name new-name

master -Git의 기본 브랜치 이름은 master입니다. 원격 및 로컬 컴퓨터 용.

origin / master-원격 저장소에서 마스터 분기를 참조하기위한 포인터 일뿐입니다. 원점이 원격을 가리켰다는 것을 기억하십시오.

$ git fetch origin-원격 저장소에서 로컬 컴퓨터로 [origin / master] 개체 및 참조를 다운로드합니다. 즉,를 사용하여 병합하지 않으면 로컬 마스터 분기에 영향을 미치지 않습니다 $ git merge origin/master. 이 명령을 실행하기 전에 병합해야하는 올바른 분기를 체크 아웃해야합니다.

참고 : 페치 된 컨텐츠는 원격 브랜치로 표시됩니다. Fetch를 사용하면 변경 사항을 프로젝트 사본에 통합하기 전에 검토 할 수 있습니다. 귀하와 리모컨 사이의 변경 사항을 표시하려면$git diff master..origin/master

한 가지 설명 (그리고 나를 혼란스럽게 한 요점) :

"원격 / 원산지 / HEAD가 기본 분기입니다"는 실제로 올바르지 않습니다.

remotes / origin / master는 원격 저장소의 기본 분기였습니다 (마지막으로 확인한 시간). HEAD는 분기가 아니라 단지 분기를 가리 킵니다.

HEAD를 작업 공간으로 생각하십시오. 이 방법으로 생각하면 'git checkout branchname'은 작업 영역 파일을 특정 브랜치의 파일로 변경하는 것과 관련이 있습니다. 분기 파일을 작업 영역으로 "체크 아웃"합니다. 모든 실제적인 목적을위한 HEAD는 작업 영역에서 볼 수있는 것입니다.

이 git 슬래시 표기법은 아마도 .git폴더 내부를 보면 가장 잘 이해 될 것입니다 .

예를 들어, 다음은 LibreOffice 소스 기반에 대한 다소 간결한 내 .git 트리입니다.

리눅스 에서는 sudo apt-get install tree이것을 보는 것이 유용합니다. Windows
에서는 명령이 여전히 작동 할 수 있다고 생각합니다 .tree

아래로 스크롤하여 하단 근처의 참조 (일명 '참조')를 봅니다.

$ tree  
.  
├── branches  
├── config  
├── description  
├── FETCH_HEAD  
├── gitk.cache  
├── HEAD  
├── hooks  
│   ├── applypatch-msg.sample  
    ...
├── index  
├── info  
│   └── exclude  
├── logs  
│   ├── HEAD  
│   └── refs  
│       ├── heads  
│       │   ├── master  
│       │   └── remotes  
│       │       └── origin  
│       └── remotes  
│           └── origin  
│               ├── distro  
│               │   ├── cib  
│               │   │   └── libreoffice-6-0  
│               │   ├── collabora  
│               │   │   └── cp-6.0  
│               │   └── lhm  
│               │       └── libreoffice-5-2+backports  
│               ├── HEAD  
│               ├── libreoffice-6-2  
│               ├── master  
│               └── private  
│                   └── mst  
│                       └── sw_redlinehide_4a  
├── objects  
│   ├── info  
│   └── pack  
│       ├── pack-b80087dc57e2b3315f449ca0f1aaa91987bf0c5e.idx  
│       ├── pack-b80087dc57e2b3315f449ca0f1aaa91987bf0c5e.pack  
│       ├── pack-eb4e6808029e712d8d9c2671accbbd98aaeb9a04.idx  
│       └── pack-eb4e6808029e712d8d9c2671accbbd98aaeb9a04.pack  
├── ORIG_HEAD  
├── packed-refs  
└── refs  
    ├── heads  
    │   ├── master  
    │   └── remotes  
    │       └── origin  
    ├── remotes  
    │   └── origin  
    │       ├── distro  
    │       │   ├── cib  
    │       │   │   └── libreoffice-6-0  
    │       │   ├── collabora  
    │       │   │   └── cp-6.0  
    │       │   └── lhm  
    │       │       └── libreoffice-5-2+backports  
    │       ├── HEAD  
    │       ├── libreoffice-6-2  
    │       ├── master  
    │       └── private  
    │           └── mst  
    │               └── sw_redlinehide_4a  
    └── tags  
        └── libreoffice-6-2-branch-point  

32 directories, 45 files

다음과 같이 배치하면 혼란스럽지 않았을 수도 있지만 그렇지 않았습니다.

repositories (i.e. independent trees)
├──local
│  └──master
│
└──origin1
│  └──master
└──origin2
   └──master

heads , remotes 및 tags 세 가지 기본 참조 유형이 있습니다.

.git / refs / heads 는 로컬 마스터를 보유합니다 .
.git/refs/remotes can hold a number of remotes, although at the moment we only have origin in it.
.git/refs/tags (is discussed elsewhere).

origin thus, is our one and only remote. It holds origin/master.

We find that we have 2 HEADS (pointers to current branches), one local, and one remote:

$ cat .git/HEAD                        #         local:  HEAD -> master
ref: refs/heads/master

$ cat .git/refs/remotes/origin/HEAD    # remote origin:  HEAD -> master
ref: refs/remotes/origin/master

If you list your branches:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/aoo/aw080
  remotes/origin/aoo/trunk
  remotes/origin/distro/capgemini/cg-4.1
  remotes/origin/distro/cib/libreoffice-5-0
  remotes/origin/distro/cib/libreoffice-5-1
  remotes/origin/distro/cib/libreoffice-5-2
  ...

The first branch listed (master) is the only one which is not a remote. So in this case we have one local branch. This is where we'll start our own work from, for our own new branches and subsequent commits.

Next, you may have many remote tracking branches, and we do here. You know these are remote tracking branches because they are prefixed with 'remotes/'. The ones shown here are for the remote named origin.

So the second line is origin's current branch pointer. Remotes/origin: HEAD --points to--> master. This shows that in the remote repository, the current branch is their branch named master, (not to be confused with our local branch named master).
The remaining branches aren't found in your .git/refs/ tree, but rather you'll find them in .git/packed-refs.

When we git fetch we download changes from the remote repository, into our remote tracking repository.

When we git merge we merge the changes in this local, remote tracking repository into our working local branch or branches, in this case into our master branch.

(When we git pull we do both of these two steps in one operation.)

It's also interesting to note these local and remote UUIDs for master currently point to the same node (aka 'commit'):

$ cat refs/heads/master                   # local         master
1ca409292272632f443733450313de5a82c54a9c

$ cat refs/remotes/origin/master          # remote origin master
1ca409292272632f443733450313de5a82c54a9c

So our local master points to the same place as the remote's origin master:

[local] master = [remote] origin master

Finally, I think it's also useful to take a look at .git/packed-refs

$ cat packed-refs 
# pack-refs with: peeled fully-peeled 
3c1d4742e649fe9c8aed8c2817fe3e1f3364f298 refs/remotes/origin/aoo/aw080
e87c8b7922e9a73e0abb7f9a7a47c9ac3374a826 refs/remotes/origin/aoo/trunk
b70fdffb041c12f124dcc0822b61bf3450e53137 refs/remotes/origin/distro/capgemini/cg-4.1
5dbc3f1754809b9489faaf380b1a4bdbcfbb6205 refs/remotes/origin/distro/cib/libreoffice-5-0
cfdbc96ca47d68d6785fd21829a8d61f49d6e591 refs/remotes/origin/distro/cib/libreoffice-5-1
5189c8c47461ef09739086e55512fc6a10245273 refs/remotes/origin/distro/cib/libreoffice-5-2
3bee5917569ca8e6ee3b086458f5b1a917b88ca1 refs/remotes/origin/distro/cib/libreoffice-5-3
92fbe703f9ca480d3a2b8610d87e991c729edf77 refs/remotes/origin/distro/cib/libreoffice-5-4
05c0a5df66cc69d75280f05b804cf82f3387d42b refs/remotes/origin/distro/cib/libreoffice-6-0
7fe193e759b24b90852e6e327115b77114d7b119 refs/remotes/origin/distro/cib/libreoffice-6-1
8187f7aa413e7ef7b377eea2b057d336bf256867 refs/remotes/origin/distro/collabora/cd-5.3
7a6b608591e21ef61dc05cff9fc58da531035755 refs/remotes/origin/distro/collabora/cd-5.3-3.1
....

No doubt this leaves more questions than answers, but I think it can start to help you answer your own questions about what's what.

참고URL : https://stackoverflow.com/questions/10588291/git-branching-master-vs-origin-master-vs-remotes-origin-master

저작자표시

'Programing' 카테고리의 다른 글

문자열에 단일 문자가 나타나는지 어떻게 확인할 수 있습니까? (0)	2020.05.16
힘내 비난 : 통계 (0)	2020.05.15
SQL : WHERE 절 내의 IF 절 (0)	2020.05.15
다운로드하지 않고 브라우저에서 파일을 강제로 열려면 어떻게합니까 (PDF)? (0)	2020.05.15
삭제와 삭제의 차이점 (0)	2020.05.15

현재글Git 브랜칭 : 마스터 vs. 오리진 / 마스터 vs. 리모트 / 오리진 / 마스터

crosscheck

Git 브랜칭 : 마스터 vs. 오리진 / 마스터 vs. 리모트 / 오리진 / 마스터

Git 브랜칭 : 마스터 vs. 오리진 / 마스터 vs. 리모트 / 오리진 / 마스터

'Programing' 카테고리의 다른 글

'Programing'의 다른글

티스토리툴바

Git 브랜칭 : 마스터 vs. 오리진 / 마스터 vs. 리모트 / 오리진 / 마스터

Git 브랜칭 : 마스터 vs. 오리진 / 마스터 vs. 리모트 / 오리진 / 마스터

'Programing' 카테고리의 다른 글

'Programing'의 다른글

관련글

티스토리툴바