@Mark Longairは彼の答えでここに釘付けにしましたが、もう少し洞察を加えたいと思います。
大規模なプルリクエスト（PR）を分割する方法に関する質問への回答。特に、masterがfeature_branchに1つ以上マージされているため、コミットを破棄することが実用的でない場合
私の状況：30回のコミットで
ビッグを作成し、feature_branchGitHubでプルリクエスト（PR）を開いてにマージしましたmaster。ブランチmasterは私の下でトンを変え、私のfeature_branch持っていなかった200のコミットを受け取りました。解決の競合に私がやったgit checkout feature_branchとgit merge masterマージするmaster私にの変更をfeature_branch。私は最新のマスターmergeではなく選択したrebaseので、潜在的に30回ではなく1回だけ競合を解決する必要があります（コミットごとに1回）。最初に30のコミットを1に押しつぶし、次に最新のものにリベースしたくありませんでしたmasterこれは、PRのGitHubレビューコメント履歴を消去する可能性があるためです。そこで、masterを機能ブランチにマージし、競合を1回解決しました。すべてが順調でした。しかし、私のPRは大きすぎて同僚がレビューするには大きすぎました。分割する必要がありました。私は30のコミットとOH NO！彼らはどこにいる？それらはすべて混在にしているmaster私がマージされているため、今の200回の最近のコミットmaster私にfeature_branch！私は何をしますか？
git cherrygit cherry-pick個々のコミットを試したい場合の使用法：
git cherry 救助に（一種）！
あるすべてのコミットを参照するにfeature_branchはありませんでmaster、私が行うことができますが。
git checkout feature_branch
git cherry master
または、feature_branch次のgit cherry [upstream_branch] [feature_branch]ようにすることで、最初にオンになっていることを確認せずに、任意のブランチからのコミットをチェックできます。繰り返しますが、これは、どのコミットfeature_branchが含まれているのかupstream_branch（masterこの場合は含まれていないのか）を確認します。
git cherry master feature_branch
追加する-vと、コミットメッセージの件名も表示されます。
git cherry -v master
「word count」「-lines」（wc -l）へのパイプは、コミットの数をカウントします。
git cherry master | wc -l
この数をGithHub PRに表示されるコミット数と比較して、実際に機能していることをよりよく理解できますgit cherry。gitハッシュを1つずつ比較して、git cherryとGitHubが一致することを確認することもできます。注git cherryあなたがマージされた任意のマージコミットはカウントされませんmasterにしfeature_branchますが、GitHubのWILL。したがって、カウントにわずかな不一致が見られる場合は、GitHub PRコミットページで「マージ」という単語を検索すると、おそらくそれがに表示されていない原因であることがわかりますgit cherry。例：「Merge branch 'master' into feature_branch」というタイトルのコミットはGitHub PRに表示されますが、を実行すると表示されませんgit cherry master feature_branch。これで問題ありません。
だから、今私はこの差分を分割するために新しい機能ブランチにチェリーピックしたいかもしれないdiffを見つける手段を持っています：git cherry master feature_branchローカルで使うか、GitHub PRでコミットを見ることができます。
スカッシュがどのように役立つか-スカッシュできた場合のみ：
ただし、私の大きな差分を分割する別の方法は、30のコミットすべてを1つにまとめ、新しい機能ブランチにパッチを適用し、パッチコミットをソフトリセットしてgit guiから、ピースをファイルごとに、チャンクごとに追加するか、または1行ずつ。サブ機能を1つ取得したら、追加した内容をコミットし、新しいブランチをチェックアウトし、さらに追加し、コミットし、新しいブランチをチェックアウトするなどして、大きな機能をいくつかのサブ機能に分割します。 。問題は、私の30回のコミットが原因私に他の人から他の200のコミットと混在していることであるgit merge master私にfeature_branch、私は再注文に230回のコミットを取捨選択し、私の30回のコミットをつぶす必要があるだろうと、そうリベースは、したがって、非現実的です。
スカッシュのはるかに簡単な置き換えとしてパッチファイルを使用する方法：
回避策は、30のコミットすべての「スカッシュ相当」を含むパッチファイルを取得し、それをmaster（新しいサブ機能ブランチ）の新しいフォークにパッチして、そこから次のように作業することです。
git checkout feature_branch
# ensure I have the latest changes from master merged into feature_branch
git merge master
# Obtain a patch file, which is the equivalent of a squash of my 30 commits into 1 commit:
git diff master..feature_branch > ~/mypatch.patch
git checkout master
# Create a new, sub-feature branch
git checkout -b feature_branch2
# Patch the 30 commit patch file onto it:
git apply ~/mypatch.patch
これで、30コミットパッチがすべてローカルに適用されましたが、ステージングもコミットもされていません。
git guiファイル、チャンク、および/または行を追加し、大きなPRまたは「差分」を分割するために使用します。
がない場合はgit gui、Ubuntuに簡単にインストールできますsudo apt install git-gui。
git gui（git GUIプログラムで右クリックして）ファイル、チャンク、および/または行を実行して追加を開始し、上記のように30のコミット機能ブランチをサブブランチに分割し、繰り返し追加、コミット、フォークすることができます。すべての変更がサブ機能ブランチに追加され、30コミット機能が3つまたは4つのサブ機能に正常に分割されるまで、新しい機能ブランチとこのサイクルを繰り返します。ここで、これらのサブ機能ごとに個別のPRを開くことができます。これにより、私のチームが簡単に確認できるようになります。
参照：
- gitリポジトリからパッチまたはdiffファイルを作成し、別の異なるgitリポジトリに適用します