이것을 이해하려면 git의 작동 방식에 대해 조금 이해해야합니다. git 저장소는 트리의 노드가 커밋되는 트리 구조입니다. 다음은 매우 간단한 저장소의 예입니다.

마스터 브랜치에 4 개의 커밋이 있고 각 커밋에는 ID (이 경우 a, b, c 및 d)가 있습니다. d가 현재 마스터 브랜치의 최신 커밋 (또는 HEAD)임을 알 수 있습니다.

여기에는 master와 my-branch의 두 가지 분기가 있습니다. master와 my-branch는 모두 커밋 a와 b를 포함하지만 분기하기 시작하는 것을 볼 수 있습니다. master에는 c와 d가 포함되고 my-branch에는 e와 f가 포함됩니다. b는 master와 비교하여 my-branch의 “병합 기반”또는 더 일반적으로 “기본”이라고합니다. 의미가 있습니다. my-branch가 이전 버전의 master를 기반으로한다는 것을 알 수 있습니다.

따라서 my-branch가 오래되어 최신 버전의 master로 업데이트하려고한다고 가정 해 보겠습니다. 다시 말해서 my-branch는 c와 d를 포함해야합니다. 병합을 수행 할 수 있지만 이로 인해 분기에 풀 요청 검토를 훨씬 더 어렵게 만드는 이상한 병합 커밋이 포함됩니다. 대신 리베이스를 수행 할 수 있습니다.

리베이스 할 때 git은 브랜치의베이스 (이 경우 b)를 찾고 해당베이스와 HEAD (이 경우 e와 f) 사이의 모든 커밋을 찾은 다음 브랜치의 HEAD에서 해당 커밋을 재생합니다. 당신은 (이 경우 마스터) 리베이스하고 있습니다. Git은 실제로 master 위에 변경 사항이 어떻게 보이는지 나타내는 새로운 커밋을 생성합니다. 다이어그램에서 이러한 커밋은 e ‘및 f’라고합니다. Git은 이전 커밋을 지우지 않습니다. e와 f는 그대로 유지되며 리베이스에 문제가 발생하면 예전 방식으로 바로 돌아갈 수 있습니다.

많은 다른 사람들이 프로젝트에서 시뮬레이션 작업을하는 경우 풀 요청이 빠르게 부실해질 수 있습니다. “부실한”풀 요청은 더 이상 주요 개발 라인에서 최신 상태가 아니며 프로젝트에 병합하기 전에 업데이트해야합니다. pull 요청이 부실한 가장 일반적인 이유는 충돌 때문입니다. 두 개의 pull 요청이 모두 동일한 파일에서 유사한 줄을 수정하고 하나의 pull 요청이 병합되면 병합되지 않은 pull 요청에 충돌이 발생합니다. 때로는 풀 요청이 충돌없이 부실 할 수 있습니다. 코드베이스의 다른 파일을 변경하려면 새 아키텍처를 준수하기 위해 풀 요청에 상응하는 변경이 필요하거나 실수로 실패한 단위 테스트를 마스터 브랜치. 이유에 관계없이

답변