Git을 사용하여 브랜치를 통합할 때 더 일반적으로 사용되는 작업은 rebase 작업(git rebase)과 병합 작업(git merge) 중 어느 것이 더 좋다고 생각하시나요?

Question

git에서 브랜치를 통합하는 방법은 일반적으로 git rebase와 git merge 두 가지가 있습니다. 그런데 실제 팀 개발에서는 어떤 방법을 가장 많이 사용하시나요? 아니면 어떤 방법이 더 좋다고 생각하시나요?

Answer 1

현실은 이렇지 않나 싶습니다.

1. git을 사용하는 사람 중 적어도 절반은 rebase 사용법을 모릅니다(기본 기능에도 불구하고)(이 추정치는 아마도 매우 보수적일 것입니다)

2. 아마도 나머지 절반 중 절반만이 언제 올바르게 리베이스해야 하는지 이해하고 있을 것입니다...

병합이나 리베이스는 둘 중 하나를 선택할 문제가 아닙니다. 현실적으로 이 "특정 상황"은 대부분의 개발자에게 있어서 정말 어려운 일입니다. 팀의 기능은 상대적으로 단순하고 자주 접할 기회가 없기 때문에 여기에서는 모두가 이해하고 준수해야 하는 두 가지 지침만 요약하겠습니다.

1. 원격에서 pull으로 이동할 때는 항상 rebase를 사용하세요(한 가지 예외는 있지만 나중에 설명함)

2. 기능을 완료하고(로컬 브랜치를 별도로 개설했다고 가정) 이를 트렁크 브랜치에 병합할 계획이라면 항상 병합

을 사용하세요.

개발자는 다양한 병합 전략이 최종 코드 결과에 영향을 미치지 않을 수 있지만 git이 제출 내역을 기록하는 방식에 영향을 미친다는 점을 이해해야 합니다(이러한 이해는 개인에게만 도움이 되고 본인에게는 거의 영향을 미치지 않지만). 다른 사람들이 이러한 기록을 사용할 때(예: 코드 검토 중 또는 이등분 중 등) 과거에 수행한 작업으로 인해 극도로 행복하거나 비참하다고 느낄 것입니다.

두 번째 요점은 로컬 브랜치에서 기능 개발의 구체적인 세부 사항을 숨기고 최종 결과를 전체 기록으로 트렁크 브랜치에 병합하는 것입니다.

핵심은 첫 번째 포인트입니다. 대부분의 경우 모든 사람이 기본 pull인 fetch + merge을 선택하므로 커밋 xxx를 xxx로 병합과 같은 간섭 메시지가 트렁크에 지속적으로 표시됩니다. 모두가 편의를 위해 이렇게 한다면 우리는 결코 깨끗하고 아름다운 역사 나무를 가질 수 없을 것입니다.

git을 올바르게 사용하는 프로젝트를 clone하면 위 그림처럼 지저분한 마스터는 절대 볼 수 없습니다. 왜? 대답은 git pull --rebase입니다. 이 명령은 기본 rebase 대신 pull을 사용하여 병합된 기록 트리를 리베이스하므로 빨리 감기가 불가능하여 추가 병합 레코드를 피할 수 있습니다.

이제 대부분의 git 클라이언트에서는 git pull의 기본 동작을 --rebase으로 설정할 수 있으므로 이 트릭을 익히면 대부분의 일상적인 가져오기 작업에 대한 깨끗하고 아름다운 기록 기록을 생성할 수 있지만 이것이 완벽한 결말은 아닙니다. 다음과 같은 예외가 있습니다.

1. git merge를 사용하여 기능 분기를 트렁크 분기(물론 --no-ff의 분기)로 병합한 후

2. git fetch을 실행하면 원격 트렁크가 여러 커밋보다 앞서 있음을 알 수 있습니다.

3. 이때 git pull --rebase하면 방금 병합한 기능 브랜치의 기록이 사라진 것을 알 수 있습니다...

rebase가 병합된 레코드를 무시하기 때문에 rebase 명령에는 무시된 병합 레코드를 재구성하는 데 사용되는 --preserve-merges이라는 특수 매개변수가 있습니다. 따라서 git pull --rebase보다 더 나은 해결책은 대신 git fetch + git rebase -p을 사용하는 것입니다.

물론 이는 위에서 언급한 특별한 상황에만 해당됩니다. git이 업그레이드되면 이 문제가 언젠가는 사라질지 확실하지 않습니다. 저는 항상 이렇게 하기 때문에 보통 이런 상황이 발생하지 않습니다.

1. 함수 브랜치 완료 후 병합하지 않고 메인 브랜치로 복귀 git pull --rebase

2. 트렁크가 업데이트되면 업데이트된 콘텐츠를 함수 브랜치로 리베이스하여 다른 사람이 최근 변경한 내용을 추가한 후에도 내 함수가 여전히 괜찮은지 사전 확인합니다(이 과정에서 충돌이 발생할 수 있습니다. 상기시키지 못했다고 탓하지 마세요)

3. 모든 것이 준비되면 git fetch 트렁크를 다시 확인하여 변경 사항이 있는지 확인하고(누군가 두 번째 단계에서 새 변경 사항을 푸시했을 수 있으므로) 변경 사항이 있으면 두 번째 단계를 반복합니다. 그렇지 않다면——

4. 함수 브랜치를 트렁크에 병합하고 밀어서 하루를 호출합니다.

이렇게 하면 위에서 언급한 사고를 피할 수 있지만, 익숙해지면 사실 어렵지 않습니다. 더 중요한 이유는 git rebase -p에 결함이 있다는 것입니다.

1. 은

   과 함께 사용할 수 없습니다. 하나의 명령이 두 개로 나누어져 있어 어차피 "잃어버린" 느낌입니다. (스크립트를 작성할 수는 있지만 나중에 해를 끼칠 수 있으므로 사용하지 않는 것이 가장 좋습니다. 익숙해지세요) git pull

2. 은

   과 함께 사용할 수 없으므로 리베이스할 대상 브랜치를 지정해야 합니다. 이는 특히 많은 GUI 클라이언트가 git pull를 전혀 지원하지 않는 경우(저는 CLI/스위치 환경을 자주 사용합니다) git을 이용한 GUI 간) git rebase -p

3. 파기됩니다. ORIG_HEAD

은 여러 상황에서 매우 유용합니다. 예를 들어 ORIG_HEAD를 사용하여 최신 병합 등으로 인한 모든 변경 사항을 검토할 수 있습니다. git log -p -reverse ORIG_HEAD 가리켜야 하는 위치를 잃게 되며 먼저 올바른 해시를 찾아서 교체해야 하는데 이는 약간 짜증스러울 수 있습니다. --preserve-merges

위 답변은 마침내 한 가지를 보여줍니다. 초보자라면 현실의 복잡성은 항상 상상을 뛰어넘습니다. Git을 잘 사용하려면 일상 업무를 기반으로 Git의 작동 원리를 이해해야 합니다. , 공식 웹사이트 전자책(중국어 버전)을 읽을 수 있습니다. 거기에 있는 git 내부 섹션을 주의 깊게 읽은 후에는 어떤 명령을 사용해야 하는지 알 수 있습니다.

---

추가 사항: 팀이 트렁크 브랜치에 있는 중요하지 않은 간섭 커밋 레코드를 많이 신경 쓰지 않는다면 항상 리베이스를 사용할 수 있으므로 최소한 포크가 많지 않고 깔끔해질 수 있습니다. 올바르게 처리되면(그러나 장황함) 트렁크 분기 기록이 표시됩니다.

Answer 2

필수는 아니지만 푸시 후 모든 테스트가 녹색이어야 합니다.

(특별히 긴 지점은 없으며 대부분 2~3일 내에 병합되며 일주일을 넘기는 경우는 거의 없습니다)

보통 모두가 병합의 난이도에 따라 선택합니다. 차이가 없으면 리베이스가 우선적으로 적용됩니다... 더 좋아 보이기 때문입니다.