git을 사용하는 사람 중 적어도 절반은 rebase 사용법을 모릅니다(기본 기능에도 불구하고)(이 추정치는 아마도 매우 보수적일 것입니다)
아마도 나머지 절반 중 절반만이 언제 올바르게 리베이스해야 하는지 이해하고 있을 것입니다...
병합이나 리베이스는 둘 중 하나를 선택할 문제가 아닙니다. 현실적으로 이 "특정 상황"은 대부분의 개발자에게 있어서 정말 어려운 일입니다. 팀의 기능은 상대적으로 단순하고 자주 접할 기회가 없기 때문에 여기에서는 모두가 이해하고 준수해야 하는 두 가지 지침만 요약하겠습니다.
원격에서 pull으로 이동할 때는 항상 rebase를 사용하세요(한 가지 예외는 있지만 나중에 설명함)
기능을 완료하고(로컬 브랜치를 별도로 개설했다고 가정) 이를 트렁크 브랜치에 병합할 계획이라면 항상 병합
을 사용하세요.
개발자는 다양한 병합 전략이 최종 코드 결과에 영향을 미치지 않을 수 있지만 git이 제출 내역을 기록하는 방식에 영향을 미친다는 점을 이해해야 합니다(이러한 이해는 개인에게만 도움이 되고 본인에게는 거의 영향을 미치지 않지만). 다른 사람들이 이러한 기록을 사용할 때(예: 코드 검토 중 또는 이등분 중 등) 과거에 수행한 작업으로 인해 극도로 행복하거나 비참하다고 느낄 것입니다.
두 번째 요점은 로컬 브랜치에서 기능 개발의 구체적인 세부 사항을 숨기고 최종 결과를 전체 기록으로 트렁크 브랜치에 병합하는 것입니다.
핵심은 첫 번째 포인트입니다. 대부분의 경우 모든 사람이 기본 pull인 fetch + merge을 선택하므로 커밋 xxx를 xxx로 병합과 같은 간섭 메시지가 트렁크에 지속적으로 표시됩니다. 모두가 편의를 위해 이렇게 한다면 우리는 결코 깨끗하고 아름다운 역사 나무를 가질 수 없을 것입니다.
git을 올바르게 사용하는 프로젝트를 clone하면 위 그림처럼 지저분한 마스터는 절대 볼 수 없습니다. 왜? 대답은 git pull --rebase입니다. 이 명령은 기본 rebase 대신 pull을 사용하여 병합된 기록 트리를 리베이스하므로 빨리 감기가 불가능하여 추가 병합 레코드를 피할 수 있습니다.
이제 대부분의 git 클라이언트에서는 git pull의 기본 동작을 --rebase으로 설정할 수 있으므로 이 트릭을 익히면 대부분의 일상적인 가져오기 작업에 대한 깨끗하고 아름다운 기록 기록을 생성할 수 있지만 이것이 완벽한 결말은 아닙니다. 다음과 같은 예외가 있습니다.
git merge를 사용하여 기능 분기를 트렁크 분기(물론 --no-ff의 분기)로 병합한 후
git fetch을 실행하면 원격 트렁크가 여러 커밋보다 앞서 있음을 알 수 있습니다.
이때 git pull --rebase하면 방금 병합한 기능 브랜치의 기록이 사라진 것을 알 수 있습니다...
rebase가 병합된 레코드를 무시하기 때문에 rebase 명령에는 무시된 병합 레코드를 재구성하는 데 사용되는 --preserve-merges이라는 특수 매개변수가 있습니다. 따라서 git pull --rebase보다 더 나은 해결책은 대신 git fetch + git rebase -p을 사용하는 것입니다.
물론 이는 위에서 언급한 특별한 상황에만 해당됩니다. git이 업그레이드되면 이 문제가 언젠가는 사라질지 확실하지 않습니다. 저는 항상 이렇게 하기 때문에 보통 이런 상황이 발생하지 않습니다.
함수 브랜치 완료 후 병합하지 않고 메인 브랜치로 복귀 git pull --rebase
트렁크가 업데이트되면 업데이트된 콘텐츠를 함수 브랜치로 리베이스하여 다른 사람이 최근 변경한 내용을 추가한 후에도 내 함수가 여전히 괜찮은지 사전 확인합니다(이 과정에서 충돌이 발생할 수 있습니다. 상기시키지 못했다고 탓하지 마세요)
모든 것이 준비되면 git fetch 트렁크를 다시 확인하여 변경 사항이 있는지 확인하고(누군가 두 번째 단계에서 새 변경 사항을 푸시했을 수 있으므로) 변경 사항이 있으면 두 번째 단계를 반복합니다. 그렇지 않다면——
함수 브랜치를 트렁크에 병합하고 밀어서 하루를 호출합니다.
이렇게 하면 위에서 언급한 사고를 피할 수 있지만, 익숙해지면 사실 어렵지 않습니다. 더 중요한 이유는 git rebase -p에 결함이 있다는 것입니다.
은
과 함께 사용할 수 없습니다. 하나의 명령이 두 개로 나누어져 있어 어차피 "잃어버린" 느낌입니다. (스크립트를 작성할 수는 있지만 나중에 해를 끼칠 수 있으므로 사용하지 않는 것이 가장 좋습니다. 익숙해지세요) git pull
은
과 함께 사용할 수 없으므로 리베이스할 대상 브랜치를 지정해야 합니다. 이는 특히 많은 GUI 클라이언트가 git pull를 전혀 지원하지 않는 경우(저는 CLI/스위치 환경을 자주 사용합니다) git을 이용한 GUI 간) git rebase -p
파기됩니다. ORIG_HEAD
은 여러 상황에서 매우 유용합니다. 예를 들어 ORIG_HEAD를 사용하여 최신 병합 등으로 인한 모든 변경 사항을 검토할 수 있습니다. git log -p -reverse ORIG_HEAD 가리켜야 하는 위치를 잃게 되며 먼저 올바른 해시를 찾아서 교체해야 하는데 이는 약간 짜증스러울 수 있습니다. --preserve-merges
위 답변은 마침내 한 가지를 보여줍니다. 초보자라면 현실의 복잡성은 항상 상상을 뛰어넘습니다. Git을 잘 사용하려면 일상 업무를 기반으로 Git의 작동 원리를 이해해야 합니다. , 공식 웹사이트 전자책(중국어 버전)을 읽을 수 있습니다. 거기에 있는 git 내부 섹션을 주의 깊게 읽은 후에는 어떤 명령을 사용해야 하는지 알 수 있습니다.
추가 사항: 팀이 트렁크 브랜치에 있는 중요하지 않은 간섭 커밋 레코드를 많이 신경 쓰지 않는다면 항상 리베이스를 사용할 수 있으므로 최소한 포크가 많지 않고 깔끔해질 수 있습니다. 올바르게 처리되면(그러나 장황함) 트렁크 분기 기록이 표시됩니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
현실은 이렇지 않나 싶습니다.
git을 사용하는 사람 중 적어도 절반은 rebase 사용법을 모릅니다(기본 기능에도 불구하고)(이 추정치는 아마도 매우 보수적일 것입니다)
아마도 나머지 절반 중 절반만이 언제 올바르게 리베이스해야 하는지 이해하고 있을 것입니다...
병합이나 리베이스는 둘 중 하나를 선택할 문제가 아닙니다. 현실적으로 이 "특정 상황"은 대부분의 개발자에게 있어서 정말 어려운 일입니다. 팀의 기능은 상대적으로 단순하고 자주 접할 기회가 없기 때문에 여기에서는 모두가 이해하고 준수해야 하는 두 가지 지침만 요약하겠습니다.
원격에서
pull으로 이동할 때는 항상 rebase를 사용하세요(한 가지 예외는 있지만 나중에 설명함)기능을 완료하고(로컬 브랜치를 별도로 개설했다고 가정) 이를 트렁크 브랜치에 병합할 계획이라면 항상 병합
개발자는 다양한 병합 전략이 최종 코드 결과에 영향을 미치지 않을 수 있지만 git이 제출 내역을 기록하는 방식에 영향을 미친다는 점을 이해해야 합니다(이러한 이해는 개인에게만 도움이 되고 본인에게는 거의 영향을 미치지 않지만). 다른 사람들이 이러한 기록을 사용할 때(예: 코드 검토 중 또는 이등분 중 등) 과거에 수행한 작업으로 인해 극도로 행복하거나 비참하다고 느낄 것입니다.
두 번째 요점은 로컬 브랜치에서 기능 개발의 구체적인 세부 사항을 숨기고 최종 결과를 전체 기록으로 트렁크 브랜치에 병합하는 것입니다.
핵심은 첫 번째 포인트입니다. 대부분의 경우 모든 사람이 기본
pull인fetch + merge을 선택하므로 커밋 xxx를 xxx로 병합과 같은 간섭 메시지가 트렁크에 지속적으로 표시됩니다. 모두가 편의를 위해 이렇게 한다면 우리는 결코 깨끗하고 아름다운 역사 나무를 가질 수 없을 것입니다.git을 올바르게 사용하는 프로젝트를 clone하면 위 그림처럼 지저분한 마스터는 절대 볼 수 없습니다. 왜? 대답은
git pull --rebase입니다. 이 명령은 기본rebase대신pull을 사용하여 병합된 기록 트리를 리베이스하므로 빨리 감기가 불가능하여 추가 병합 레코드를 피할 수 있습니다.이제 대부분의 git 클라이언트에서는
git pull의 기본 동작을--rebase으로 설정할 수 있으므로 이 트릭을 익히면 대부분의 일상적인 가져오기 작업에 대한 깨끗하고 아름다운 기록 기록을 생성할 수 있지만 이것이 완벽한 결말은 아닙니다. 다음과 같은 예외가 있습니다.git merge를 사용하여 기능 분기를 트렁크 분기(물론--no-ff의 분기)로 병합한 후git fetch을 실행하면 원격 트렁크가 여러 커밋보다 앞서 있음을 알 수 있습니다.이때
git pull --rebase하면 방금 병합한 기능 브랜치의 기록이 사라진 것을 알 수 있습니다...rebase가 병합된 레코드를 무시하기 때문에 rebase 명령에는 무시된 병합 레코드를 재구성하는 데 사용되는
--preserve-merges이라는 특수 매개변수가 있습니다. 따라서git pull --rebase보다 더 나은 해결책은 대신git fetch+git rebase -p을 사용하는 것입니다.물론 이는 위에서 언급한 특별한 상황에만 해당됩니다. git이 업그레이드되면 이 문제가 언젠가는 사라질지 확실하지 않습니다. 저는 항상 이렇게 하기 때문에 보통 이런 상황이 발생하지 않습니다.
함수 브랜치 완료 후 병합하지 않고 메인 브랜치로 복귀
git pull --rebase트렁크가 업데이트되면 업데이트된 콘텐츠를 함수 브랜치로 리베이스하여 다른 사람이 최근 변경한 내용을 추가한 후에도 내 함수가 여전히 괜찮은지 사전 확인합니다(이 과정에서 충돌이 발생할 수 있습니다. 상기시키지 못했다고 탓하지 마세요)
모든 것이 준비되면
git fetch트렁크를 다시 확인하여 변경 사항이 있는지 확인하고(누군가 두 번째 단계에서 새 변경 사항을 푸시했을 수 있으므로) 변경 사항이 있으면 두 번째 단계를 반복합니다. 그렇지 않다면——함수 브랜치를 트렁크에 병합하고 밀어서 하루를 호출합니다.
이렇게 하면 위에서 언급한 사고를 피할 수 있지만, 익숙해지면 사실 어렵지 않습니다. 더 중요한 이유는
git rebase -p에 결함이 있다는 것입니다.과 함께 사용할 수 없습니다. 하나의 명령이 두 개로 나누어져 있어 어차피 "잃어버린" 느낌입니다. (스크립트를 작성할 수는 있지만 나중에 해를 끼칠 수 있으므로 사용하지 않는 것이 가장 좋습니다. 익숙해지세요)
git pull과 함께 사용할 수 없으므로 리베이스할 대상 브랜치를 지정해야 합니다. 이는 특히 많은 GUI 클라이언트가
git pull를 전혀 지원하지 않는 경우(저는 CLI/스위치 환경을 자주 사용합니다) git을 이용한 GUI 간)git rebase -p파기됩니다.
ORIG_HEAD은 여러 상황에서 매우 유용합니다. 예를 들어
위 답변은 마침내 한 가지를 보여줍니다. 초보자라면 현실의 복잡성은 항상 상상을 뛰어넘습니다. Git을 잘 사용하려면 일상 업무를 기반으로 Git의 작동 원리를 이해해야 합니다. , 공식 웹사이트 전자책(중국어 버전)을 읽을 수 있습니다. 거기에 있는 git 내부 섹션을 주의 깊게 읽은 후에는 어떤 명령을 사용해야 하는지 알 수 있습니다.ORIG_HEAD를 사용하여 최신 병합 등으로 인한 모든 변경 사항을 검토할 수 있습니다.git log -p -reverse ORIG_HEAD가리켜야 하는 위치를 잃게 되며 먼저 올바른 해시를 찾아서 교체해야 하는데 이는 약간 짜증스러울 수 있습니다.--preserve-merges추가 사항: 팀이 트렁크 브랜치에 있는 중요하지 않은 간섭 커밋 레코드를 많이 신경 쓰지 않는다면 항상 리베이스를 사용할 수 있으므로 최소한 포크가 많지 않고 깔끔해질 수 있습니다. 올바르게 처리되면(그러나 장황함) 트렁크 분기 기록이 표시됩니다.
필수는 아니지만 푸시 후 모든 테스트가 녹색이어야 합니다.
(특별히 긴 지점은 없으며 대부분 2~3일 내에 병합되며 일주일을 넘기는 경우는 거의 없습니다)
보통 모두가 병합의 난이도에 따라 선택합니다. 차이가 없으면 리베이스가 우선적으로 적용됩니다... 더 좋아 보이기 때문입니다.