내가 커밋 등의 역사를 가진 자식의 REPO가 있다고 커밋합니다. 또한, 내가 프로젝트의 역사를 다시 쓸 수있는 완전한 자유가 있다고 가정 해 봅시다 (아마도 저는 프로젝트에서만 작업하고 있습니다).자식 : B를 저지른와 C가 완전히 결함이 불필요한 것을, A-B-C-D-E</p> <p>을 이제 갑자기 실현 : 나쁜 일련의 도입 제거 변경
커밋 B와 C를 가리키는 다른 분기가 있으므로 문제가되지 않습니다. 만약 내가 실제로 그 변화가 필요하다면, 나는 그 지점을 체크 아웃하고 그들을 볼 수있다.
그러나 마스터 브랜치의 경우 D와 E가 수정 된 부모 목록을 가질뿐만 아니라 도입 된 변경 사항을 포함하지 않는 A-D'-E '가되도록 내역을 강요하고 싶습니다. B와 C를 커밋합니다.
이 작업을 수행 할 수 있습니까? 그렇다면 어떻게?
git rebase -i HEAD~5
그런 다음, 통신의 목록에서 원하지 않는 커밋을 제거 그것의
5 가지 커밋이 있다고 가정합니다.
하는 경우 당신은 할 수 있습니다 :
git rebase -i HEAD~5
는 그런 다음
마지막으로 B와 C를 커밋에 관한이 줄을 제거합니다, 당신은 할 수 있습니다 :
git rebase --continue
rebase --continue는 rebase가 사용자 입력을 위해 멈추어야 할 경우에만 필요하며,이 경우에는'B' 다음에'D'가 적용될 때 충돌이 발생하지 않는다. 및 'C'는 제거되었습니다. – Cascabel
git rebase --onto $commit_A$commit_C$commit_E이것은 "C 후에 커밋을 모두 취하고 E를 포함해서 A 위에 재생"합니다.
당신이 말하는 커밋에 대해 어떤 표기법이라도 사용할 수 있습니다. 예 : master가 E에 있고 당신이 C 가리키는 지점이있는 경우, backup 말, 당신은 또한이 말을 할 수
git rebase --onto $commit_A backup master이 차례로 더욱 편리 HEAD는 master에서 지적 당신이 남아있을 것 같은, 그리고 master 다시 쓰여진 것을 가리킨다.
니스! 나는 이전에 리베이스 (rebase)를 사용 해본 적이 없지만 단순한 필사자 (필자 자신처럼)에게는 리베이스가 가능할 것으로 보인다. 나는이 문제가 rebase로 해결할 수있을 것이라고 생각했다. 왜 내가 "git-rebase"라고 태그를 붙 였는지, rebasing은 (적어도 나를 위해) 당신의 머리를 감싸는 일은 어렵다. 말할 것도없이 쉽게 레포 역사를 망칠 수 있습니다. 하지만 - i는 정말 쉬워 보입니다. – Kipras