Gitrebase, '로컬' 및 '원격' 추적

Gitrebase, '로컬' 및 '원격' 추적

Gitbase를 실행할 때, 저는 종종 충돌을 해결할 때 '로컬'과 '리모트'에서 무슨 일이 일어나고 있는지 이해하는 데 어려움을 겪습니다.저는 가끔 그들이 한 약속에서 다른 약속으로 편을 바꾼다는 인상을 받습니다.

이것은 아마 제가 아직 제대로 이해하지 못했기 때문일 것입니다.

기본 재배치 시 누가 '로컬'이고 누가 '리모트'입니까?

(P4Merge를 사용하여 충돌 해결)

TL;DR;

요약하자면 (Benubird가 언급한 바와 같이) 다음과 같은 경우:

git checkout A
git rebase   B    # rebase A on top of B

• local이라B(기준),
• remote이라A

그리고:

git checkout A
git merge    B    # merge B into A

• local이라A(안으로 이동),
• remote이라B

스위치 기본치ours 시작 전 ) 및 (리베이스 시작 전 현재 분기) 및theirs(기본값을 변경할 분기).

---

kutschkem은 GUI 병합 도구 맥락에서 다음과 같이 지적합니다.

• 부분적으로 재조정된 커밋을 로컬 참조: "ours 지점) (상류 지점)
• 원격은 들어오는 변경사항을 말합니다: "theirs 분기. -철근배전현재분기의근▁before▁-분기현재.

이 답변의 마지막 부분에 있는 그림을 참조하십시오.

---

리베이스 시 반전

이러한 혼란은 기본 재배치 및 재설정 중의 반전과 관련이 있을 수 있습니다.
(발췌)

git rebase 맨 페이지:

기본 재배치는 작업 분기의 각 커밋을 위에서 재생함으로써 작동합니다.<upstream>분점.

이로 인해 병합 충돌이 발생할 경우:

• 로 보도된 쪽.ours로 시작하는 지금까지 기반을 바꾼 시리즈입니다.<upstream>,
• discovery'theirs작업 분기입니다.즉, 측면이 서로 바뀝니다.

---

반전 그림

병합 시

x--x--x--x--x(*) <- current branch B ('*'=HEAD)
    \
     \
      \--y--y--y <- other branch to merge

우리는 현재 분기 'B'를 변경하지 않으므로, 우리가 가지고 있는 것은 여전히 우리가 작업하던 것입니다(그리고 우리는 다른 분기에서 병합합니다).

x--x--x--x--x---------o(*)  MERGE, still on branch B
    \       ^        /
     \     ours     /
      \            /
       --y--y--y--/  
               ^
              their

---

기본값:

그러나 리베이스에서 리베이스가 가장 먼저 하는 일은 업스트림 브랜치를 체크아웃하는 것이기 때문에 리베이스 쪽으로 전환합니다! (그 위에서 현재 커밋을 재생하려면)

x--x--x--x--x(*) <- current branch B
    \
     \
      \--y--y--y <- upstream branch

의지가 먼저 변합니다.HEAD에서 지점 B로HEAD 분기와 하여 '

x--x--x--x--x <- former "current" branch, new "theirs"
    \
     \
      \--y--y--y(*) <- upstream branch with B reset on it,  
                       new "ours", to replay x's on it

그런 다음 기본 재배치는 새 '우리' B 브랜치에서 '그들' 커밋을 재생합니다.

x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
    \
     \
      \--y--y--y--x'--x'--x'(*) <-  branch B with HEAD updated ("ours")
               ^
               |
        upstream branch

---

참고: "업스트림" 개념은 데이터를 읽거나 새 데이터를 추가/생성하는 참조 데이터 집합(예: 모든 보고서(여기서는 로컬 분기일 수 있음)

---

'localdiscovery'remote 'vs.'minediscovery'theirs'

판다우드는 논평에 다음과 같이 덧붙입니다.

나에게, "로컬"과 "원격"이 누구인지에 대한 질문은 여전히 남아 있습니다("우리"와 "그들"이라는 용어는 비트를 다시 기초할 때 사용되지 않기 때문에, 그것들을 참조하면 답변을 더 혼란스럽게 만드는 것 같습니다).

GUI git merge 도구

kutschkem은 다음과 같이 덧붙입니다.

충돌을 해결할 때 git는 다음과 같은 말을 합니다.

local: modified file and remote: modified file. 

저는 이 질문이 현 시점에서 로컬과 원격의 정의를 목표로 한다고 확신합니다.그 시점에서, 제 경험으로 볼 때, 다음과 같이 보입니다.

• 부분적으로 재조정된 커밋을 로컬 참조: "ours 지점) (상류 지점)
• 원격은 들어오는 변경사항을 말합니다: "theirs 분기. -철근배전현재분기의근▁before▁-분기현재.

git mergetool 실제로 'local' 및 'remote'를 언급합니다.

Merging:
f.txt

Normal merge conflict for 'f.txt':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (kdiff3):

예를 들어, KDIf3는 병합 해상도를 다음과 같이 표시합니다.

Meld도 표시합니다.

다음을 표시하는 VimDiff도 마찬가지입니다.

Gitmergetool -tgvimdiff가 있는 병합 도구로 Vimdiff를 호출합니다.최근 버전의 Git는 다음 창 레이아웃을 사용하여 Vimdiff를 호출합니다.

+--------------------------------+
| LOCAL  |     BASE     | REMOTE |
+--------------------------------+
|             MERGED             |
+--------------------------------+

• LOCAL:
  현재 분기의 파일 내용을 포함하는 임시 파일입니다.
• BASE:
  병합에 대한 공통 기준을 포함하는 임시 파일입니다.
• REMOTE:
  병합할 파일의 내용을 포함하는 임시 파일입니다.
• MERGED:
  충돌 마커가 들어 있는 파일입니다.

Git는 가능한 한 많은 자동 충돌 해결을 수행했으며 이 파일의 상태는 두 가지 모두의 조합입니다.LOCAL그리고.REMOTEGit가 스스로 해결할 수 없는 모든 것을 둘러싼 갈등 마커로.
그mergetool해결 결과를 이 파일에 기록해야 합니다.

결론은

기트베이스

• LOCAL = 기본값을 변경하는 기준
• REMOTE = 상위로 이동하는 커밋

git merge

• LOCAL = 병합할 원래 분기
• REMOTE = 병합할 커밋의 다른 분기

즉, LOCAL은 항상 원본이며 REMOTE는 항상 이전에 커밋이 없었던 사용자입니다. 커밋이 상위에 병합되거나 기반이 바뀌기 때문입니다.

증명해 보세요!

물론입니다.내 말을 믿지 마!여기 여러분이 직접 볼 수 있는 쉬운 실험이 있습니다.

먼저 Gitmerge 도구가 올바르게 구성되어 있는지 확인합니다. 그렇지 않았다면 이 질문을 읽지 않았을 것입니다.그런 다음 작업할 디렉터리를 찾습니다.

리포지토리 설정:

md LocalRemoteTest
cd LocalRemoteTest

초기 커밋을 만듭니다(빈 파일 포함).

git init
notepad file.txt  (use the text editor of your choice)
  (save the file as an empty file)
git add -A
git commit -m "Initial commit."

마스터가 아닌 분기에 커밋 만들기:

git checkout -b notmaster
notepad file.txt
  (add the text: notmaster)
  (save and exit)
git commit -a -m "Add notmaster text."

마스터 분기에 커밋을 만듭니다.

git checkout master
notepad file.txt
  (add the text: master)
  (save and exit)
git commit -a -m "Add master text."

gitk --all

이 시점에서 저장소는 다음과 같습니다.

이제 기본 재배치 테스트의 경우:

git checkout notmaster
git rebase master
  (you'll get a conflict message)
git mergetool
  LOCAL: master
  REMOTE: notmaster

이제 병합 테스트입니다.변경 내용을 저장하지 않고 병합 도구를 닫은 다음 기본 재배치를 취소합니다.

git rebase --abort

그러면:

git checkout master
git merge notmaster
git mergetool
  LOCAL: master
  REMOTE: notmaster
git reset --hard  (cancels the merge)

결과는 위에 표시된 것과 같아야 합니다.

저도 오랫동안 혼란스러웠고, 종종 잘못된 결정을 내려 다시 시작해야 했습니다.

고지 사항:저는 git 전문가가 아니라서 여기서 틀린 부분이 있으면 고쳐주세요!

저는 제가 혼란스러웠던 이유가 많은 사람들이 그리는 것과 다른 기반을 상상했기 때문이라는 것을 깨달았다고 생각합니다.다음은 기본 재배치를 설명하는 데 일반적으로 사용되는 두 개의 도면입니다.

--1--2--3--4--5\6--7--8

그리고 나서.

--1--2--3--4--5--6--7--8

물론 그것은 그것을 그리는 한 가지 방법이지만, 저는 리베이스에서 무슨 일이 일어나고 있는지에 대해 다음과 같이 말이죠.

--1--2--3--4--5\6--7--8

물론 어느 것이 정확히 똑같습니다.하지만 "우리/그들"의 관점에서 보면 다릅니다.두 번째 경우에는 "우리"가 여전히 분기("6-7-8") 위에 있는 것처럼 느껴지며 "마스터"로부터 변경 사항을 수집하고 싶습니다.그래서 이 세상에서 "우리"는 여전히 "가지"입니다.그리고 이것이 저를 혼란스럽게 했던 것입니다.

하지만 Git의 견해인 첫 번째 "월드 뷰"에서 우리는 마스터(기본으로 삼고자 하는 커밋)로 이동하고 거기서 분기의 각 커밋을 차례로 선택하여 적용합니다.그래서 "우리"는 처음에 "주인"이 됩니다.5.끝나고6성공적으로 적용되었습니다. "우리"는6하지만 사실은.6'그것은 마스터의 "위에" 있습니다.

--1--2--3--4--5--6'\6--7--8

그리고 "7"도 마찬가지입니다.

그래서 병합에서 당신은 "온"입니다.8그리고 그 둘을 새로운 커밋으로 결합하지만, 기본적으로 당신은 다음으로 이동합니다.5분기에 있는 커밋의 차이를 새 커밋으로 적용합니다.

따라서 기본 재배치의 최종 결과에 대한 "진정한" 그림은 다음과 같습니다.

--1--2--3--4--5--6'--7'--8'\6--7--8

그리고 당신이 있는 리베이스 후에.8'그리고 당신의 지점도 마찬가지입니다. (제 생각에는!)그리고 이것은 (내 마음속에서) 다음과 같이 시각화될 수 있습니다.

--1--2--3--4--5\           \6--7--8     6'--7'--8'

저는 당신의 문제를 정확히 이해하지 못했지만, 아래 그림이 당신의 문제를 해결해 줄 것이라고 생각합니다.(기본값 : 원격 리포지토리 ---> 작업영역)

출처: My Git 워크플로우

언급URL : https://stackoverflow.com/questions/3051461/git-rebase-keeping-track-of-local-and-remote