git에서 가져 오기는 pull과 어떻게 다르며 병합은 rebase와 어떻게 다릅니 까?

나는 이것을 이해할 수 없다. 나는 웹과 책에서 많은 것을 읽었고 뭔가가 내 머리 속에 머물러 있지 않습니다. 누군가 나에게 다음의 더미 버전을 줄 수 있습니까?

• git fetch vs pull
• git merge vs rebase

페치 vs 풀

fetch 원격 * 브랜치에서 변경 사항을 다운로드하여 리포지토리 데이터를 업데이트하지만 로컬 * 브랜치는 변경하지 않습니다.

pull로컬 브랜치에 대한 변경을 fetch추가로 수행합니다 merge.

차이점이 뭐야? pull가져온 분기의 변경 사항으로 로컬 분기를 업데이트합니다. A fetch는 현지 지사를 진출시키지 않습니다.

병합 대 리베이스

다음과 같은 기록이 있습니다.

          C --- D --- E 지역
         /
    A --- B --- F --- G 리모트

merge두 개의 개발 이력을 결합합니다. 원격 브랜치에서 분기 된 후 로컬 브랜치에서 발생한 변경 사항을 재생하고 결과를 새 커밋에 기록합니다. 이 작업은 각 커밋의 조상을 유지합니다.

의 효과 merge는 다음과 같습니다.

          C --- D --- E 지역
         / \
    A --- B --- F --- G --- H 리모트

rebase로컬 브랜치에 존재하는 커밋을 가져 와서 원격 브랜치 위에 다시 적용합니다. 이 작업은 로컬 커밋의 조상을 다시 씁니다.

의 효과 rebase는 다음과 같습니다.

                  C '-D'-E '지역
                 /
    A --- B --- F --- G 리모트

차이점이 뭐야? A merge는 커밋의 조상을 변경하지 않습니다. A rebase 는 지역 커밋의 조상을 다시 작성합니다.

*이 설명은 현재 분기 로컬 지점이라고 가정하고, 분기에 인수로 지정한 fetch, pull, merge, 또는 rebase원격 지점입니다. 이것은 일반적인 경우입니다. pull예를 들어, 지정된 브랜치 에서 변경 사항을 다운로드하고 리포지토리와 현재 브랜치 merge의 변경 사항을 업데이트합니다 .

페치 vs 풀

Git fetch는 repo 데이터를 업데이트하지만 git pull은 기본적으로 페치를 수행 한 다음 가져온 브랜치를 병합합니다.

'git pull'과 'git fetch'의 차이점은 무엇입니까?

병합 대 리베이스

Atlassian SourceTree 블로그, 병합 또는 리베이스에서 :

병합은 각 커밋 히스토리의 조상을 보존하면서 두 개의 개발 라인을 통합합니다.

대조적으로, rebasing은 소스 브랜치의 변경 사항을 다시 작성하여 대상 브랜치의 자식으로 표시되도록 개발 라인을 통합합니다. 이러한 커밋은 대상 브랜치 위에 모두 작성된 것처럼 효과적으로 커밋합니다.

또한 Learn Git Branching을 확인하십시오. 이 게임은 HackerNews에 게시되어 있고 ( post to link ) 많은 분기 및 병합 트릭을 가르치는 멋진 게임입니다 . 이 문제에 큰 도움이 될 것이라고 믿습니다.

풀 대 가져 오기 :

내가 이것을 이해하는 방식 git pull은 단순히 git fetch뒤에옵니다 git merge. 즉, 원격 지점에서 변경 사항을 가져 와서 현재 지점으로 병합합니다.

병합 대 rebase :

명령에 따라 병합이 수행됩니다. 현재 브랜치와 지정된 브랜치 (현재 브랜치)의 차이점을 병합합니다. 즉, 명령 git merge another_branch이 another_branch현재 분기로 병합 됩니다.

리베이스는 약간 다르게 작동하며 멋지다. 명령을 수행한다고 가정 해 봅시다 git rebase another_branch. Git은 먼저 현재 분기와 사이의 최신 공통 버전을 찾습니다 another_branch. 즉, 가지가 분기되기 전의 시점입니다. 그런 다음 git은이 분기점을의 머리로 이동합니다 another_branch. 마지막으로 원래 분기 지점 이후 현재 분기의 모든 커밋은 다음과 같습니다. 이 새로운 분기점에서 재생 됩니다. 이렇게하면 분기와 병합 수가 적은 매우 깨끗한 기록이 만들어집니다.

그러나 함정이없는 것은 아닙니다! 버전 기록은 "다시 작성"되므로 커밋이 로컬 git repo에만 존재하는 경우에만 수행해야합니다. 그건: , 커밋을 원격 리포지토리로 푸시 한 경우이 작업을 수행하지 마십시오 .

주어진 리베이스에 대한 설명 이 온라인 서적에 이해하기 쉬운 그림과 함께 아주 좋습니다.

병합 대신 rebasing으로 당겨

실제로 실제로 rebase를 많이 사용하고 있지만 일반적으로 pull과 함께 사용됩니다.

git pull --rebase

원격 변경 사항을 가져온 다음 병합 대신 리베이스합니다. 즉, 마지막으로 풀을 수행했을 때 모든 로컬 커밋을 재생합니다. 병합을 사용하여 일반 풀을 수행하는 것보다 훨씬 깔끔하다는 것을 알았습니다.

병합 -HEAD 브랜치는 각 커밋 히스토리의 조상을 유지하면서 새로운 커밋을 생성합니다. 동일한 지점에서 동시에 작업하는 여러 사람이 병합 커밋을 수행하면 기록이 오염 될 수 있습니다.

Rebase- 새로운 커밋을 만들지 않고 한 브랜치의 변경 사항을 다른 브랜치에 다시 씁니다. 코드 히스토리는 단순하고 선형 적이며 읽을 수 있지만 다른 변경 사항을 볼 수 없기 때문에 풀 요청에서는 작동하지 않습니다.

내가 사용하는 것이 git merge특징 기반의 워크 플로우를 처리 할 때 또는 내가 REBASE에 익숙하지 않은 생각합니다. 그러나 더 깨끗하고 선형적인 역사를 git rebase원한다면 더 적절합니다. 자세한 내용은 이 병합 또는 리베이스 기사 를 확인 하십시오 .