変更を元に戻すことなくコミットを取り除く

Question

こんにちは、私はgithubを初めて使っています。私はちょうどグループプロジェクトのためにいくつかの友人とプライベートレポジトリに取り掛かりました。私はコードを整理したり、フォルダを追加したり、物事を動かすなどのコミットをしなければなりませんでした。しかし、これはコミットの混乱を引き起こしました。私はそれが雑然と見えないものがコミットに写真の括弧内のコミットのすべてを組み合わせたい：

私はgit rebase -i HEAD~20を使用し、以前のスレッドを作って、このテキストファイルがポップアップし、しかし、ときに私pickから 'squash'に変更された括弧内のすべてを変更します。エラーが発生する：error: cannot 'squash' without a previous commit

ご協力いただきまして誠にありがとうございます。また、私はgithubを初めて使ったので、あまり知らないです。

Answer 1

問題はgit rebase -i HEAD~20があなたのプロジェクトの間違った線形履歴を表示しています。 GitとGithubはこれを行うのが悪い癖があり、混乱の原因になります。実際、Gitは（コンピュータサイエンスの意味では）グラフです。

ここではgit log --decorate --onelineによって生成され、Githubによって残念なことに使用される偽の線形履歴です。

1ff521a (HEAD -> master, origin/master, origin/HEAD) Revert "Boulder code + minor changes" 
85cb9fa Merge remote-tracking branch 'origin/master' 
47d93ec Boulder code + minor changes 
e6bb627 Recommit actor and sw 
c6a48cc Add files via upload 
1f005ec Create readme.txt 
33f251b Added missing files, reuploading project 
0b520fd Boulder code + minor changes 
4068bca Recommit actor and sw 
9b2aa1c Add files via upload 
f7ed4ad Create readme.txt 
14a6d35 Add files via upload 
244e6d9 Create readme.txt 
ce33d87 Add files via upload 
86ae9a2 Add files via upload 
8bec858 Add files via upload 
f001fb0 Create readme.txt 
d8dbf27 Create readme.txt 
9ef59fc Delete Debug 
64bfb3e Create Debug 
aab055b Created DiggerMan folder (organization) 
deb834b Added Debug Items 
f219ae5 Create readme.txt 
9da61f0 Added missing files, reuploading project 
d6459cb added missing dll files, no other major change 
42b500d Merged and organized code from last commit. 
0a87678 Merge remote-tracking branch 'origin/master' 
81f93fb Created new base class for objects that can be picked up 
67e6369 HUD now displayed and partially implemented 
4da4bff DiggerMan can now dig! 

ここにはgit log --graph --decorate --onelineからの現実があります。コミットの真の関係を示します。

* 1ff521a (HEAD -> master, origin/master, origin/HEAD) Revert "Boulder code + minor changes" 
* 85cb9fa Merge remote-tracking branch 'origin/master' 
|\ 
| * 0b520fd Boulder code + minor changes 
| * 4068bca Recommit actor and sw 
| * 9b2aa1c Add files via upload 
| * f7ed4ad Create readme.txt 
| * 14a6d35 Add files via upload 
| * 244e6d9 Create readme.txt 
| * ce33d87 Add files via upload 
| * 86ae9a2 Add files via upload 
| * 8bec858 Add files via upload 
| * f001fb0 Create readme.txt 
| * d8dbf27 Create readme.txt 
| * 9ef59fc Delete Debug 
| * 64bfb3e Create Debug 
| * aab055b Created DiggerMan folder (organization) 
| * deb834b Added Debug Items 
| * f219ae5 Create readme.txt 
| * 9da61f0 Added missing files, reuploading project 
* | 47d93ec Boulder code + minor changes 
* | e6bb627 Recommit actor and sw 
* | c6a48cc Add files via upload 
* | 1f005ec Create readme.txt 
* | 33f251b Added missing files, reuploading project 
|/ 
* d6459cb added missing dll files, no other major change 
* 42b500d Merged and organized code from last commit. 
* 0a87678 Merge remote-tracking branch 'origin/master' 
|\ 
| * 67e6369 HUD now displayed and partially implemented 
* | 81f93fb Created new base class for objects that can be picked up 
|/ 
* 4da4bff DiggerMan can now dig! 

ブランチのように見えるものはブランチです。 Gitブランチはコミットの単なるラベルです。 git branch -dの場合は、ラベルを削除するだけです。 実際のブランチは、マージ後に保存されます。これは「トポロジカルオーダー」と呼ばれ、Gitで何が起こっているのかを理解する必要があります。トポロジカルな順序は重要です。

git rebase -i HEAD~20は、すべてのコミットを一緒にスムーズにすることができるように、偽の線形履歴を示しました。その代わりに、地形を見て、各支店を別々にスクアッシュする必要があります。

---

これはあまりにも複雑なようです。よりシンプルな方法があります。

最も簡単なのはコミットが多すぎることを心配しないでくださいです。一般的に、小さすぎるコミットが少なすぎる場合に比べて小さなコミットが多すぎる方が良いです。バージョン管理、特にコミットメッセージの目的の1つは、なぜに変更が加えられたかを知ることです。小さなコミットにより、変更を理由と関連付けるのが容易になります。一緒にコミットをマージすると、すべての理由が一緒にマージされます。スカッシュ・マージについて多くのアドバイスがありますが、しないでください。

コミットの数とそのサイズは意味のある数値ではありませんです。代わりに、適切なコミットを行うと、コードを理解しやすくなり、将来の見直しが容易になります。たとえば、直前のコミットで入力ミスを修正したコミットは、Create Debugの後にDelete Debugなどの意味がありません。 fixupを使用して削除するか、両方のコミットを完全に削除するか、直前のコミットを直ちにgit commit --amendに書き換えてください。同様に、 "readme.txtを作成する"が4回ありますが、これはおそらく間違いです。OTOH Created DiggerMan folder (organization)はおそらく意味のあるコミットです。最後に

、 はそれらをマージする前に、あなたの枝をクリーンアップします。これは今問題のような問題を回避します。マージする前に、 git rebase -i masterは現在のブランチのコミットだけを選択し、トポロジカルな問題はありません。コラボレーションプロジェクトで作業し、ブランチをレビューする必要がある場合は、慣れておくことも良い習慣です。レビューのために提出する前にブランチを整理したいと思うでしょう。

Answer 2

最初にスカッシュしたいコミットは4eb500dです。

Githubには表示されていませんが、コミットメッセージ（ "Merged and organized ..."）は、このコミットが押しつぶされない理由を示しています。

スカッシュは、スカッシュされたコミットによって導入された変更が、親のコミットに結合されることを意味します。しかし、マージコミットは通常のコミットではありません。 2つ以上の親コミットがあります。

git rebaseがコミットをスカッシュしてスカッシュにするのは明らかではありません。さらに、親の1つにスクラッシュすると、マージ操作が削除されます。そして、これはおそらくGitがマージコミットを抑制するのを許さないのには良い理由です。

グラフィカルGitクライアントを使用して、コミットが互いにどのように関連しているかを確認し、各ブランチを個別に編集します。その後、マージコミットを再作成し、最終的には保持したくない現在のコミットを破棄することができます。