Git 학습을 위한 리베이스 예시에 대한 자세한 설명

이 글은 Git에 대한 관련 지식을 제공하며, 주로 리베이스와 관련된 문제를 소개합니다. 리베이스와 리베이스는 베이스 변경으로 직접적으로 이해할 수 있습니다. 기능 브랜치는 마스터 브랜치의 B를 기반으로 한 브랜치입니다. 모든 분들께 도움이 되었으면 좋겠습니다.

추천 학습: "Git 학습 튜토리얼"

이 기사에서는 가장 간단한 예를 사용하여 rebase의 원리와 사용법을 빠르게 익히는 데 도움을 줍니다

1. 노드 다이어그램 제출

먼저 간단한 예제를 통해 Rebase를 경험해 보세요. 노드 다이어그램 제출 무엇을 하고 계시나요

마스터와 기능 두 개의 브랜치, 여기서 기능은 커밋 지점 B의 마스터에서 가져온 브랜치입니다

마스터에는 새로운 커밋 M이 있고 기능에는 두 개의 새로운 커밋 C와 D가 있습니다

이는 기능 브랜치로 전환하고 다음 명령을 실행합니다. 이는 마스터 브랜치를 기능 브랜치에 병합하는 것과 같습니다(이 단계의 시나리오는 우리가 일정 기간 동안 자체 브랜치 기능을 개발해 왔다는 사실과 비교할 수 있습니다) 시간이 지났고 메인 마스터 브랜치에서 가져올 준비가 되었습니다.) 최신 변경 사항을 확인하세요.

git checkout featuregit rebase master

//这两条命令等价于git rebase master feature

아래 그림은 리베이스 후 커밋 노드 다이어그램을 보여줍니다. 작동 원리를 설명하세요.

• 기능: 리베이스할 브랜치입니다. , 현재 브랜치
• master: 기본 브랜치, 대상 브랜치

공식 설명 (이해가 안 되면 다음 문단을 직접 읽어도 됩니다.): rebase 작업을 수행할 때 git은 브랜치의 수정 사항을 추출합니다. 두 브랜치의 공통 조상에서 리베이스하고, 리베이스할 브랜치를 베이스의 최신 커밋으로 지정하고, 마지막으로 방금 추출한 변경 사항을 기본 브랜치의 최신 커밋 뒤에 적용합니다.

예제 설명: 기능 브랜치에서 git rebase master를 실행하면 git은 master와 featuer의 공통 조상 B부터 시작하여 기능 브랜치의 수정 사항을 추출합니다. 즉, 두 커밋 C와 D가 먼저 추출됩니다. . 그런 다음 기능 분기를 마스터 분기의 최신 커밋인 M으로 지정합니다. 마지막으로 추출된 C, D가 M에 연결되는데 이 과정은 원본 C, D를 삭제하고 새로운 C', D'를 생성하는 과정으로, 제출 내용은 동일하지만 커밋 ID가 다릅니다. 당연히 특성은 결국 D'를 가리킵니다.

잘 알려진 설명(중요!!): 리베이스는 베이스를 변경하는 것으로 직접적으로 이해될 수 있습니다. 기능 브랜치는 마스터 브랜치의 B에서 가져온 브랜치이며 기능의 기본은 B입니다. 그리고 마스터가 B 이후에 새 커밋을 갖는 경우 마스터의 새 커밋을 기능 분기의 새 기반으로 사용하는 것과 같습니다. 실제 작업은 B 이후의 기능 제출을 저장한 다음 원래 제출을 삭제하고 마스터의 최신 제출 위치를 찾은 다음 저장된 제출(새 커밋 ID가 있는 새 노드)을 연결하여 기본 제출을 수행하는 것입니다. 기능 분기는 원래 B 대신 Yu가 M이 되었습니다. (B 이후 마스터에 새로운 커밋이 없으면 원래 B는 계속 기본으로 사용됩니다. 리베이스 작업은 잘못된 작업과 동일합니다. 이때 기본적으로 git merge와 차이가 없습니다. 유일한 차이점은 git merge에 병합 작업 제출 레코드가 하나 더 있다는 점입니다)

위의 예는 다음과 같은 실제 작업 시나리오로 추상화될 수 있습니다. Zhang San은 개발을 위해 B에서 코드를 가져와 지금까지 두 번 제출했으며, Li Si도 B에서 가져와 개발한 후 M에 제출한 다음 메인 트렁크에 병합했습니다. 이때 Zhang San은 최신 코드를 풀다운하고 싶어서 기능 브랜치에서 git rebase master를 실행했습니다. 즉, 마스터 브랜치를 리베이스한 것입니다. Li Si가 이전에 트렁크를 개발하고 병합했기 때문에 이는 Zhang San과 동일합니다. Li Si의 최신 제출물을 기반으로 M이 개발되었습니다.

---

2. 실제 git 제출 예

제출 레코드는 위 다이어그램에 따라 아래 그림과 같이 구성됩니다. (ABM은 마스터 분기 라인, ABCD는 기능 분기 라인입니다. 여기서 마스터 색상은 이는 이해에 영향을 미치지 않습니다. 두 개의 분기와 두 개의 줄을 의미한다는 점만 알아두세요!)

이때 기능 분기에서 git rebase master를 실행하세요

리베이스가 완료된 후 ABCD는 원래 기능 분기 라인, ABMC'D' 새로운 기능 분기 라인이고 ABM이 마스터 분기 라인입니다(변경 없음)

---

3. 권장 사용 시나리오

할 일이 너무 많지만 이것 실제로 가장 중요한 것입니다. 회사마다, 상황마다 사용 시나리오가 다르지만 대부분의 경우 권장 사항은 다음과 같습니다.

1. 공용 브랜치에서 최신 코드를 가져올 때 rebase, 즉 git pull -r 또는 git pull --rebase를 사용하세요. 하지만 한 가지 단점은 리베이스 후에는 현재 브랜치가 어떤 브랜치를 처음으로 가져왔는지 알 수 없다는 것입니다. 에서. 베이스가 변경되었기 때문입니다. (이 때문에 실제로 대부분의 회사에서는 rebase를 사용하지 않고 기본적으로 merge를 사용합니다. "Merge...to..."라는 의미 없는 제출 기록이 남겠지만, 적어도 누가 무엇을 했는지는 알 수 있습니다.)
2. 코드를 퍼블릭으로 병합할 때 분기, 병합을 사용하세요. (리베이스를 사용하면 다른 개발자가 메인 브랜치의 히스토리를 보려 해도 원래 히스토리가 아닙니다. 히스토리는 귀하에 의해 조작되었습니다. 예를 들어 Zhang San과 Li Si는 공통 브랜치에서 개발을 가져왔습니다. Zhang San은 먼저 개발을 완료하고 2개를 제출한 다음 병합이 진행되고 Li Si는 나중에 개발 및 리베이스됩니다(Li Si는 메인 브랜치로 전환한 다음 git rebase를 실행하고 원격 끝으로 git pull을 실행해야 함). , 그러면 Li Si의 새 제출물이 Zhang San의 새 제출물이 됩니다. 새 기반이 제출되었습니다. Li Si의 제출물은 원래 최신 제출물이었지만 최신 제출물은 대신 Zhang San의 제출물이었고 모든 것이 잘못되었음을 보여주었습니다.)

추천 학습: "Git Tutorial "

위 내용은 Git 학습을 위한 리베이스 예시에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!