이전 커밋을 여러 커밋으로 나눕니다.

질문자 :koblas

브랜치를 만들고 새 브랜치에서 펑키한 작업을 많이 하지 않고 로컬 리포지토리에 커밋된 후 단일 커밋을 몇 개의 다른 커밋으로 나눌 수 있습니까?

git rebase -i 내가 할 것입니다.

먼저 깨끗한 작업 디렉토리로 시작하십시오. git status 에는 보류 중인 수정, 삭제 또는 추가가 표시되지 않아야 합니다.

이제 분할할 커밋을 결정해야 합니다.

A) 가장 최근 커밋 분할

가장 최근 커밋을 분리하려면 먼저 다음을 수행하세요.

 $ git reset HEAD~

이제 일반적인 방식으로 조각을 개별적으로 커밋하여 필요한 만큼 커밋을 생성합니다.

B) 커밋을 더 멀리 나눕니다.

이를 위해서는 rebase , 즉 기록을 다시 작성해야 합니다. 올바른 커밋을 지정하려면 다음과 같은 몇 가지 선택 사항이 있습니다.

• 세 번 커밋하면

   $ git rebase -i HEAD~3

  여기서 3 은 얼마나 많은 커밋을 되돌렸는지입니다.

• 계산하려는 것보다 트리에서 더 멀리 떨어져 있는 경우

   $ git rebase -i 123abcd~

  여기서 123abcd 는 분할하려는 커밋의 SHA1입니다.

• master 에 병합하려는 다른 분기(예: 기능 분기)에 있는 경우:

   $ git rebase -i master

rebase 편집 화면이 나타나면 분리하려는 커밋을 찾으십시오. 해당 줄의 시작 부분에서 pick 을 edit ( e 로 바꿉니다. 버퍼를 저장하고 종료합니다. 이제 수정하려는 커밋 직후에 Rebase가 중지됩니다. 그 다음에:

 $ git reset HEAD~

일반적인 방식으로 조각을 개별적으로 커밋하여 필요한 만큼 커밋을 생성합니다.

마지막으로 (A와 B 모두)

 $ git rebase --continue

Wayne Conrad

git-rebase 매뉴얼에서 (SPLITTING COMMITS 섹션)

대화형 모드에서 "편집" 작업으로 커밋을 표시할 수 있습니다. 그러나 이것이 반드시 git rebase가 이 편집의 결과가 정확히 하나의 커밋으로 예상된다는 것을 의미하지는 않습니다. 실제로 커밋을 취소하거나 다른 커밋을 추가할 수 있습니다. 이것은 커밋을 두 개로 분할하는 데 사용할 수 있습니다.

• git rebase -i <commit>^ 으로 대화형 리베이스를 시작합니다. 여기서 <commit> 은 분할하려는 커밋입니다. 사실, 그 커밋을 포함하는 한 모든 커밋 범위는 그렇게 할 것입니다.

• "편집" 작업으로 분할하려는 커밋을 표시합니다.

• 해당 커밋을 편집할 때 git reset HEAD^ 실행하십시오. 그 효과는 HEAD가 1씩 되감기되고 인덱스가 그에 따른다는 것입니다. 그러나 작업 트리는 그대로 유지됩니다.

• 이제 첫 번째 커밋에 포함하려는 인덱스에 변경 사항을 추가합니다. git add (대화식으로 가능) 또는 git gui (또는 둘 다)를 사용하여 이를 수행할 수 있습니다.

• 지금 적절한 커밋 메시지로 현재 인덱스를 커밋합니다.

• 작업 트리가 깨끗해질 때까지 마지막 두 단계를 반복합니다.

• git rebase --continue 리베이스를 계속하십시오.

MBO

이전 답변에서는 git rebase -i 를 사용하여 분할하려는 커밋을 편집하고 부분적으로 커밋하는 방법을 다뤘습니다.

이것은 파일을 다른 커밋으로 분할할 때 잘 작동하지만 개별 파일에 대한 변경 사항을 분리하려는 경우 알아야 할 사항이 더 있습니다.

분할하려는 커밋에 도달하면 rebase -i edit 용으로 표시하면 두 가지 옵션이 있습니다.

1. git reset HEAD~ 사용한 후 git add -p 를 사용하여 개별적으로 패치를 살펴보고 각 커밋에서 원하는 패치를 선택합니다.

2. 원하지 않는 변경 사항을 제거하려면 작업 복사본을 편집하십시오. 그 임시 상태를 커밋합니다. 그런 다음 다음 라운드를 위해 전체 커밋을 풀백합니다.

옵션 2는 중간 버전이 병합의 일부로 제대로 빌드 및 실행되는지 확인할 수 있으므로 대규모 커밋을 분할하는 경우에 유용합니다. 이것은 다음과 같이 진행됩니다.

rebase -i 를 사용하고 커밋을 edit 한 후 다음을 사용하십시오.

 git reset --soft HEAD~

커밋을 취소하지만 커밋된 파일은 인덱스에 남겨둡니다. 초기 커밋이 최종 결과에 얼마나 근접할지에 따라 --soft를 생략하여 혼합 재설정을 수행할 수도 있습니다. 유일한 차이점은 모든 변경 사항을 준비된 상태로 시작하는지 아니면 모두 준비되지 않은 상태로 시작하는지입니다.

이제 들어가서 코드를 수정합니다. 변경 사항을 제거하고 추가된 파일을 삭제하고 찾고 있는 시리즈의 첫 번째 커밋을 구성하기 위해 원하는 모든 작업을 수행할 수 있습니다. 또한 빌드하고 실행하고 일관된 소스 집합이 있는지 확인할 수도 있습니다.

만족스러우면 필요에 따라 파일을 스테이징/언스테이징하고(이 경우 git gui 를 사용하고 싶습니다) UI 또는 명령줄을 통해 변경 사항을 커밋합니다.

 git commit

이것이 첫 번째 커밋입니다. 이제 작업 복사본을 분할 중인 커밋 이후의 상태로 복원하여 다음 커밋에서 더 많은 변경 사항을 적용할 수 있습니다. 편집 중인 커밋의 sha1을 찾으려면 git status 사용하세요. 상태의 처음 몇 줄에는 현재 실행 중인 rebase 명령이 표시되며 여기에서 원래 커밋의 sha1을 찾을 수 있습니다.

 $ git status interactive rebase in progress; onto be83b41 Last commands done (3 commands done): pick 4847406 US135756: add debugging to the file download code e 65dfb6a US135756: write data and download from remote (see more in file .git/rebase-merge/done) ...

이 경우 편집 중인 커밋에는 sha1 65dfb6a 있습니다. 이를 알고 있으면 커밋과 파일 위치를 모두 git checkout 형식을 사용하여 작업 디렉토리에서 해당 커밋의 내용을 확인할 수 있습니다. 여기에서 사용 . 전체 작업 복사본을 대체할 파일 위치로:

 git checkout 65dfb6a .

끝에 있는 점을 놓치지 마세요!

이렇게 하면 편집 중인 커밋 이후의 파일이 체크아웃되고 스테이징되지만 이전 커밋과 관련이 있으므로 이미 커밋한 변경 사항은 커밋에 포함되지 않습니다.

지금 진행하고 있는 그대로 커밋하여 분할을 완료하거나 다시 돌아가서 다른 중간 커밋을 만들기 전에 커밋의 일부를 삭제할 수 있습니다.

하나 이상의 커밋에 대해 원래 커밋 메시지를 재사용하려면 rebase의 작업 파일에서 바로 사용할 수 있습니다.

 git commit --file .git/rebase-merge/message

마지막으로 모든 변경 사항을 커밋하면

 git rebase --continue

계속해서 리베이스 작업을 완료합니다.

Andy Mortimer

git rebase --interactive 를 사용하여 이전 커밋을 편집하고 git reset HEAD~ 실행한 다음 git add -p 를 실행하여 일부를 추가하고 커밋을 수행한 다음 원하는 만큼 더 추가하고 다른 커밋을 수행합니다. 작업이 완료되면 git rebase --continue 실행하면 스택의 초기에 모든 분할 커밋을 갖게 됩니다.

중요 : 원하는 변경 사항을 포함하는 프로젝트의 지점을 찾기 위해 git reflog 를 실행할 수 있기 때문에 원하는 모든 변경 사항을 수행하고 변경할 수 있으며 이전 변경 사항을 잃을 염려가 없습니다. a8c4ab ) 그런 다음 git reset a8c4ab .

다음은 작동 방식을 보여주는 일련의 명령입니다.

mkdir git-test; cd git-test; git init

이제 파일 A

vi A

다음 줄을 추가하십시오.

one

git commit -am one

그런 다음이 줄을 A에 추가하십시오.

two

git commit -am two

그런 다음이 줄을 A에 추가하십시오.

three

git commit -am three

이제 파일 A는 다음과 같습니다.

 one two three

그리고 우리의 git log 는 다음과 같습니다. (글쎄요, 저는 git log --pretty=oneline --pretty="%h %cn %cr ---- %s"

 bfb8e46 Rose Perrone 4 seconds ago ---- three 2b613bc Rose Perrone 14 seconds ago ---- two 9aac58f Rose Perrone 24 seconds ago ---- one

two 번째 커밋을 둘로 나누고 싶다고 가정해 봅시다.

git rebase --interactive HEAD~2

그러면 다음과 같은 메시지가 나타납니다.

 pick 2b613bc two pick bfb8e46 three

첫 번째 pick 을 e 로 변경하여 해당 커밋을 편집합니다.

git reset HEAD~

git diff 는 우리가 두 번째 커밋에 대해 수행한 커밋을 스테이지 해제했음을 보여줍니다.

 diff --git a/A b/A index 5626abf..814f4a4 100644 --- a/A +++ b/A @@ -1 +1,2 @@ one +two

A 해당 행에 "and a third"를 추가해 보겠습니다.

git add .

이것은 일반적으로 대화식 리베이스 중에 git rebase --continue 실행하는 지점입니다. 왜냐하면 일반적으로 이전 커밋을 편집하기 위해 커밋 스택으로 돌아가기를 원하기 때문입니다. 하지만 이번에는 새로운 커밋을 만들고 싶습니다. 그래서 우리는 git commit -am 'two and a third' 실행할 것입니다. 이제 파일 A 를 편집하고 라인 two and two thirds 추가합니다.

git add . git commit -am 'two and two thirds' git rebase --continue

three 와 충돌이 있으므로 해결해 보겠습니다.

우리는 바꿀거야

 one <<<<<<< HEAD two and a third two and two thirds ======= two three >>>>>>> bfb8e46... three

에게

 one two and a third two and two thirds three

git add .; git rebase --continue

이제 git log -p 는 다음과 같습니다.

 commit e59ca35bae8360439823d66d459238779e5b4892 Author: Rose Perrone <roseperrone@fake.com> Date: Sun Jul 7 13:57:00 2013 -0700 three diff --git a/A b/A index 5aef867..dd8fb63 100644 --- a/A +++ b/A @@ -1,3 +1,4 @@ one two and a third two and two thirds +three commit 4a283ba9bf83ef664541b467acdd0bb4d770ab8e Author: Rose Perrone <roseperrone@fake.com> Date: Sun Jul 7 14:07:07 2013 -0700 two and two thirds diff --git a/A b/A index 575010a..5aef867 100644 --- a/A +++ b/A @@ -1,2 +1,3 @@ one two and a third +two and two thirds commit 704d323ca1bc7c45ed8b1714d924adcdc83dfa44 Author: Rose Perrone <roseperrone@fake.com> Date: Sun Jul 7 14:06:40 2013 -0700 two and a third diff --git a/A b/A index 5626abf..575010a 100644 --- a/A +++ b/A @@ -1 +1,2 @@ one +two and a third commit 9aac58f3893488ec643fecab3c85f5a2f481586f Author: Rose Perrone <roseperrone@fake.com> Date: Sun Jul 7 13:56:40 2013 -0700 one diff --git a/A b/A new file mode 100644 index 0000000..5626abf --- /dev/null +++ b/A @@ -0,0 +1 @@ +one

Rose Perrone

git rebase --interactive 를 사용하여 커밋을 더 작은 커밋으로 분할할 수 있습니다. rebase의 Git 문서에는 프로세스 분할 - 커밋 분할에 대한 간략한 설명이 있습니다 .

대화형 모드에서 "편집" 작업으로 커밋을 표시할 수 있습니다. git rebase 가 이 편집의 결과가 정확히 하나의 커밋으로 예상된다는 것을 의미하지는 않습니다. 실제로 커밋을 취소하거나 다른 커밋을 추가할 수 있습니다. 이것은 커밋을 두 개로 분할하는 데 사용할 수 있습니다.

• git rebase -i <commit>^ 으로 대화형 리베이스를 시작합니다. 여기서 <commit> 은 분할하려는 커밋입니다. 사실, 그 커밋을 포함하는 한 모든 커밋 범위는 그렇게 할 것입니다.

• "편집" 작업으로 분할하려는 커밋을 표시합니다.

• 해당 커밋을 편집할 때 git reset HEAD^ 실행하십시오. 그 효과는 HEAD가 1씩 되감기되고 인덱스가 그에 따른다는 것입니다. 그러나 작업 트리는 그대로 유지됩니다.

• 이제 첫 번째 커밋에 포함하려는 인덱스에 변경 사항을 추가합니다. git add (대화식으로 가능) 또는 git gui(또는 둘 다)를 사용하여 이를 수행할 수 있습니다.

• 지금 적절한 커밋 메시지로 현재 인덱스를 커밋합니다.

• 작업 트리가 깨끗해질 때까지 마지막 두 단계를 반복합니다.

• git rebase --continue 리베이스를 계속하십시오.

중간 버전의 일관성이 확실하지 않은 경우(컴파일, 테스트 스위트 통과 등) git stash 를 사용하여 각 커밋, 테스트 및 수정 사항이 있는 경우 커밋 수정 후 아직 커밋되지 않은 변경 사항을 숨겨야 합니다. 필요합니다.

user456814

이제 Windows의 최신 TortoiseGit에서 매우 쉽게 수행할 수 있습니다.

rebase 대화 상자를 열고 구성 하고 다음 단계를 수행하십시오.

• 분할하려는 커밋을 마우스 오른쪽 버튼으로 클릭하고 " Edit "(선택, 스쿼시, 삭제 중...)을 선택합니다.
• " Start "을 클릭하여 리베이스를 시작하십시오.
• 분할 커밋에 도달하면 " Edit/Split " 버튼을 선택하고 " Amend "을 직접 클릭합니다. 커밋 대화 상자가 열립니다.
  
• 별도의 커밋에 넣을 파일을 선택 취소합니다.
• 커밋 메시지를 편집한 후 " commit "을 클릭합니다.
• 커밋할 파일이 있을 때까지 커밋 대화 상자가 계속해서 열립니다. 커밋할 파일이 더 이상 없으면 커밋을 하나 더 추가할지 묻는 메시지가 표시됩니다.

TortoiseGit 덕분에 매우 도움이 되었습니다!

Mikaël Mayer

git rebase -i 할 수 있습니다. 매뉴얼 페이지에는 원하는 것이 정확히 있습니다.

http://git-scm.com/docs/git-rebase#_splitting_commits

manojlds

git reset --soft HEAD^ 있습니다. git reset (기본값은 --mixed )과 유사하지만 인덱스 내용을 유지합니다. 따라서 파일을 추가/제거한 경우 이미 색인에 파일이 있습니다.

거대한 커밋의 경우 매우 유용합니다.

lethalman

기본적으로 무엇을 해야 하는지 알고 있지만 항상 올바른 구문을 잊어버리기 때문에 필요한 명령에 대한 빠른 참조:

 git rebase -i <sha1_before_split> # mark the targeted commit with 'edit' git reset HEAD^ git add ... git commit -m "First part" git add ... git commit -m "Second part" git rebase --continue

Emmanuel Bernard의 블로그 게시물에 대한 크레딧 .

Sparkofska

대화식 리베이스 없이 가장 쉬운 일은 분할하려는 커밋 이전에 커밋에서 시작하는 새 브랜치를 만드는 것입니다. 변경 사항을 커밋한 다음 이전 분기와 병합하거나 뒤따른 커밋을 선택합니다. (그런 다음 이전 브랜치 이름을 현재 헤드로 전환합니다.) (아마도 MBO의 조언을 따르고 대화형 리베이스를 수행하는 것이 더 나을 것입니다.)

William Pursell

IntelliJ IDEA , PyCharm , PhpStorm 등에서 하나의 커밋을 분할하는 방법은 다음과 같습니다.

1. 버전 관리 로그 창에서 분할하려는 커밋을 선택하고 마우스 오른쪽 버튼을 클릭 Interactively Rebase from Here

2. 분할하려는 항목을 edit Start Rebasing 클릭하십시오.

3. HEAD가 해당 커밋으로 설정되었음을 의미하는 노란색 태그가 표시되어야 합니다. 해당 커밋을 마우스 오른쪽 버튼으로 클릭하고 커밋 Undo Commit

4. 이제 해당 커밋이 스테이징 영역으로 돌아가므로 별도로 커밋할 수 있습니다. 모든 변경 사항이 커밋되면 이전 커밋이 비활성화됩니다.

bzuo

8년이 넘었지만 누군가는 어쨌든 도움이 될 것입니다. rebase -i 없이 트릭을 수행할 수 있었습니다. git commit 하기 전과 같은 상태로 git을 이끄는 것입니다.

 # first rewind back (mind the dot, # though it can be any valid path, # for instance if you want to apply only a subset of the commit) git reset --hard <previous-commit> . # apply the changes git checkout <commit-you-want-to-split> # we're almost there, but the changes are in the index at the moment, # hence one more step (exactly as git gently suggests): # (use "git reset HEAD <file>..." to unstage) git reset

그런 다음 재설정 후 이 반짝이는 Unstaged changes after reset: 볼 수 있습니다. 저장소는 이 모든 파일을 커밋하려는 상태에 있습니다. 이제부터는 평소처럼 쉽게 다시 커밋할 수 있습니다. 도움이 되기를 바랍니다.

Stanislav E. Govorov

git rebase -i 사용하는 가장 좋은 방법이라고 생각합니다. 커밋 분할 단계를 보여주는 비디오를 만들었습니다. https://www.youtube.com/watch?v=3EzOz7e1ADI

Nguyen Sy Thanh Son

다음이 있는 경우:

 A - B <- mybranch

커밋 B에서 일부 콘텐츠를 커밋한 경우:

 /modules/a/file1 /modules/a/file2 /modules/b/file3 /modules/b/file4

그러나 B를 C - D로 분할하고 다음 결과를 얻으려고 합니다.

 A - C - D <-mybranch

예를 들어 다음과 같이 콘텐츠를 나눌 수 있습니다(다른 커밋의 다른 디렉터리에 있는 콘텐츠)...

분기를 분할하기 전에 커밋으로 다시 재설정합니다.

 git checkout mybranch git reset --hard A

첫 번째 커밋 만들기(C):

 git checkout B /modules/a git add -u git commit -m "content of /modules/a"

두 번째 커밋 만들기(D):

 git checkout B /modules/b git add -u git commit -m "content of /modules/b"

Martin G

기존 커밋에서 무언가를 추출하고 원래 커밋을 유지하려면 다음을 사용할 수 있습니다.

 git reset --patch HEAD^

git reset HEAD^ 대신 . 이 명령을 사용하면 필요한 청크만 재설정할 수 있습니다.

재설정하려는 청크를 선택한 후에는 이전 커밋의 변경 사항을 재설정할 준비된 청크를 갖게 됩니다.

 git commit --amend --no-edit

다음을 통해 별도의 커밋에 추가할 수 있는 준비되지 않은 청크

 git add . git commit -m "new commit"

주제에서 벗어난 사실:

hg split 이 있습니다. hg absorb 후 두 번째 기능은 git에서 보고 싶습니다.

Roman Kovtuh

이 방법은 변경 사항이 대부분 새 콘텐츠를 추가하는 경우에 가장 유용합니다.

때로는 분할 중인 커밋과 관련된 커밋 메시지를 잃고 싶지 않을 때가 있습니다. 분할하려는 일부 변경 사항을 커밋한 경우 다음을 수행할 수 있습니다.

1. 파일에서 제거하려는 변경 사항을 편집합니다(즉, 행을 삭제하거나 첫 번째 커밋에 맞도록 파일을 적절하게 변경). git checkout -p HEAD^ -- path/to/file 조합을 사용하여 일부 변경 사항을 현재 트리로 되돌릴 수 있습니다.
2. git add . ; git commit -m 'removal of things that should be changed later' 와 같은 것을 사용하여 이 편집을 새 커밋으로 커밋합니다. git add . ; git commit -m 'removal of things that should be changed later' , 따라서 기록에 원래 커밋이 있고 변경 사항이 있는 또 다른 커밋이 있으므로 현재 HEAD의 파일이 처음에 원하는 것처럼 보입니다. 분할 후 커밋합니다.

 000aaa Original commit 000bbb removal of things that should be changed later

3. git revert HEAD 편집 내용을 되돌리면 되돌리기 커밋이 생성됩니다. 파일은 원래 커밋에서와 같이 표시되고 기록은 이제 다음과 같이 표시됩니다.

 000aaa Original commit 000bbb removal of things that should be changed later 000ccc Revert "removal of things that should be changed later" (assuming you didn't edit commit message immediately)

4. git rebase -i 하여 처음 두 커밋을 하나로 스쿼시/수정할 수 있으며 이전에 의미 있는 커밋 메시지를 제공하지 않은 경우 선택적으로 커밋 되돌리기를 수정할 수 있습니다. 당신은 남아 있어야합니다

 000ddd Original commit, but without some content that is changed later 000eee Things that should be changed later

Łukasz Daniluk

git rebase -i 또는 이와 유사한 대화형 리베이스 사용을 제안합니다. "대화형" 접근 방식에 대한 공포증이 있고 계단을 내려갈 때 난간을 잡고 싶어하는 저와 같은 사람들을 위한 대안이 있습니다.

히스토리가 … —> P –> Q –> R –> … –> Z = mybranch P –> Q 를 두 개의 커밋으로 분할 P –> Q1 –> Q' –> R' –> … Z' = mybranch , 코드의 상태 위치를 Q' , R' 등은 동일 Q , R 등

시작하기 전에 편집증이 있는 경우 mybranch 백업을 만들어 기록을 잃을 위험이 없습니다.

 git checkout mybranch git checkout -b mybranch-backup

먼저 P (분할할 위치 이전의 커밋)를 확인하고 작업할 새 분기를 만듭니다.

 git checkout P git checkout -b mybranch-splitting

Q 에서 원하는 파일을 체크아웃하고 원하는 대로 편집하여 새 중간 커밋을 만듭니다.

 git checkout Q file1.txt file2.txt […edit, stage commit with “git add”, etc…] git commit -m "Refactored the widgets"

이 커밋의 해시를 Q1 합니다. Q 의 전체 상태를 확인하고 Q1 에서 분리된 HEAD 하고 이것을 커밋하고( Q' 생성) 작업 분기를 해당 지점으로 가져옵니다.

 git checkout Q git reset --soft Q1 git commit -m "Added unit tests for widgets" git branch -f mybranch-splitting

당신은 지금이야 mybranch-splitting 에서 Q' 와 같이 정확하게 동일한 코드 상태를 가지고 있어야 Q 않았다. 이제 원래 분기( Q 에서 Z )를 다음으로 리베이스합니다.

 git rebase --onto HEAD Q mybranch

이제 mybranch 는 원하는 대로 … P -> Q1 –> Q' –> R' –> … Z' 처럼 보일 것입니다. 따라서 모든 것이 올바르게 작동했는지 확인한 후 작업 및 백업 분기를 삭제하고 (해당되는 경우) 다시 작성된 mybranch 업스트림으로 푸시할 수 있습니다. 이미 푸시된 경우 강제로 푸시해야 하며 강제 푸시에 대한 모든 일반적인 주의 사항이 적용됩니다.

 git push --force mybranch git branch -d mybranch-splitting mybranch-backup

PLL

나는 이것을 rebase로 했다. 커밋 편집은 이미 커밋 파일을 선택하고 수정할 수 있기 때문에 작동하지 않지만 일부 파일을 선택할 수 있도록 모든 파일을 추적되지 않은 파일로 추가하고 싶었습니다. 단계는 다음과 같습니다.

1. git rebase -i HEAD~5 (내 기록에서 다섯 번째 마지막 커밋을 분할하고 싶었습니다)
2. 대상 커밋 ID 복사(나중에 필요함)
3. 커밋을 d 하여 삭제합니다. 리베이스 프로세스를 중지하고 나중에 계속하려면 커밋 바로 뒤에 b 라인을 추가하십시오. 이것이 마지막 커밋인 경우에도 git rebase --abort 및 문제가 발생할 경우 모든 것을 재설정할 수 있는 공간이 제공됩니다.
4. 리베이스가 중단점에 도달하면 git cherry-pick -n <COMMIT ID> 하세요. 이렇게 하면 커밋 자체를 선택하지 않고 커밋 변경 사항을 선택하여 추적되지 않은 상태로 둡니다.
5. 첫 번째 커밋에서 원하는 파일을 추가합니다(또는 git add -i 및 patch를 사용하여 특정 청크를 추가할 수 있음).
6. 변경 사항을 커밋합니다.
7. 남은 변경 사항으로 무엇을 할지 결정하십시오. 제 경우에는 히스토리의 마지막에 그것들을 원했고 충돌이 없었으므로 git stash 했지만 그냥 커밋할 수도 있습니다.
8. git rebase --continue 하여 추가 변경 사항 선택

대화형 rebase의 열렬한 팬으로서 이것은 내가 할 수 있는 가장 쉽고 직접적인 단계였습니다. 이 문제에 직면한 사람에게 도움이 되길 바랍니다!

Nicholas Reis

출처 : http:www.stackoverflow.com/questions/6217156/break-a-previous-commit-into-multiple-commits