私自身はこのトピックを本当に理解しておらず、以下に述べる理由でそれを使用したくないので、コメントをお願いします。可能な場合は補足します。
したがって、gitはコミットで動作します。 各コミットは一連の変更です。 各コミットには一意のハッシュがあります。 ブランチがマージとマージする場合:
# git merge "another_branch"
その後、すべてのコミットが保存されます-コミットのコメントが保存され、そのハッシュ+原則として、別の人為的なコミットが追加されます。 同時に、コミットは互い違いになる可能性があります。 これは必ずしも便利ではありません。 あなたのコミットがロールバックすることを決めたとしましょう-あなたのコミットとそうでないあなたがあまり良くない一般的なリストを見るために。 そして一般的に-一般的な話では、「ああ、私はそれを置くのを忘れていた;」ではなく、本当に重要な変更を見たいと思います。 複数のコミットを1つに結合するには、リベースを使用できます。 GitHubインターフェースには「スカッシュ&コミット」ボタンがありますが、これはあるブランチから別のブランチ(通常は作業ブランチからメインブランチ)にプルリクエスト(PR)を作成し、すべての手続きを行った後、「スカッシュ&コミット」をクリックして、コメントと変更を更新できますメインブランチに1つのコミットとして表示されます。
複数のコミットを1つにまとめる他のオプション
私はこれをしていました
次に、IDEで変更を確認し、事前に確認してから、サーバーにコミットしてプッシュしました。
長所から-コード全体を使用して、IDEのすべての変更を確認できます。 GitHubにあるWeb UIよりも便利な場合があります。
# git checkout master && git pull && git branch -b <> && git merge <> --squash
次に、IDEで変更を確認し、事前に確認してから、サーバーにコミットしてプッシュしました。
長所から-コード全体を使用して、IDEのすべての変更を確認できます。 GitHubにあるWeb UIよりも便利な場合があります。
注意rebaseは、特に複数の人が同じブランチで作業している場合、コミットのハッシュを変更してマージの競合を引き起こす可能性があります。
リベースを使用する2つのケースについて書きたいと思います。
- マージからではなく、リベースによって、あるブランチから別のブランチへの変更が含まれる場合:
# git rebase "another_branch"
これにより、「another_branch」ブランチに送信されたすべてのコミットの後にローカルコミットを配信できます。 コミットのハッシュが変更されます。
- いくつかのコミットを手動で編集できる場合-たとえば、コミットをまとめて、コメントを変更します:
# git rebase -i {HEAD~_commit_count_|commit_hash}
注:このコマンドを呼び出す前にgitが使用するエディターを設定する価値があります 。 個人的には、mceditが好きです。
したがって、あなたは居心地の良い小枝ですべてを行い、このコミットを世界と共有することに決めましたが、世界はあなたからのコミットを1つだけ望んでいます。 `git rebase -i`はエディターを起動し、コミットの編集を提案します(gitログとは異なり、コミットの順序は上から下です)。 コミットをそのままにしておくことも、コメントを変更することも、以前のコメントと接着することもできます。 原則として、最初のコミットはそのままにして、残りはすべて変更する必要があります
pick "commit_hash" "comment" → fixup "commit_hash" "comment"
。
この場合、修正コミットに含まれていたすべてのコメントが失われ、最初のコミットからのコメントが使用されます。 コメントがあなたにとって大切だった場合、修正の代わりにスカッシュを使用する必要があります。
しかし、開発プロセスが長い場合、ほとんどの場合、メインブランチのマージを行う必要がありました。 そして、あなたのすべてのコミットは一般的なコミットと混合され、あなたのものではなくあなたのものを接着することは難しいタスクになります。 したがって、「git rebase -i <>」を実行する前に、「git rebase」を実行する必要があります。 git rebaseは、すべてのコミットのリストの最後にすべてのコミットを配置し(gitログを実行することで確認できます)、次にgit rebase -i <HEAD〜Number of your commits>を実行します。最初を除くすべての行で、pick→{fixup |スカッシュ}と出来上がり-コミットが1つあります。
何らかの方法で `git rebase -i <>`コミットを編集するプロセスを台無しにした場合、Control + Cを押してはいけません-終了コードはgitエディターの終了を邪魔しません。 彼はファイルを取得し、その上ですべてを行います。 ファイル内のすべての行を削除するかコメントアウトします。 gitは、あなたが何も欲しくないことを理解します。
リベースを操作した後、-Fオプションでプッシュする必要があります。 これはすべて、コミットの履歴を変更して
# git push -f
Gitリベースの例
私がやったことを書きます。 指定-2つのブランチ-マスターとb1。 その過程で、コミットを行いました。
masterとb1のコミットは独立して行われました。 すべてを実行する順序が明確になるように、1つのリストに書きました。 各ブランチのコミットのリストは次のとおりです。
B1でGitマージマスターを作成する
新しい合成コミットを追加しました
リベースする
ローカルコミットはリストの最後にあり、コミット番号が変更され、合成コミットが消えていることに注意してください。
最後に、コミットを1つに結合します
ファイルは
ファイルは編集後になりました
判明した
そのようなこと
Initial commit - master - 2fbbe67
b1.1 - b1 - 85eac43
master after b1.1 - b505f18
b1.2 - b1 - 2d7d4ea
+1 - master - 8dcef6c
masterとb1のコミットは独立して行われました。 すべてを実行する順序が明確になるように、1つのリストに書きました。 各ブランチのコミットのリストは次のとおりです。
# git checkout master && git log
8dcef6c "+1"
b505f18 "master after b1.1"
2fbbe67 "Initial commit"
# git checkout b1 && git log
2d7d4ea "b1.2"
85eac43 "b1.1"
2fbbe67 "Initial commit"
B1でGitマージマスターを作成する
# git checkout b1 && git merge master && git log
5383781 "Merge branch 'master' into b1"
8dcef6c "+1"
2d7d4ea "b1.2"
b505f18 "master after b1.1"
85eac43 "b1.1"
2fbbe67 "Initial commit"
新しい合成コミットを追加しました
リベースする
# git checkout b1 && git rebase master && git log
7f18e47 "b1.2"
6fb80cb "b1.1"
8dcef6c "+1"
b505f18 "master after b1.1"
2fbbe67 "Initial commit"
ローカルコミットはリストの最後にあり、コミット番号が変更され、合成コミットが消えていることに注意してください。
最後に、コミットを1つに結合します
# git rebase -i HEAD~2
ファイルは
pick 6fb80cb b1.1
pick 7f18e47 b1.2
ファイルは編集後になりました
pick 6fb80cb b1.1
fixup 7f18e47 b1.2
判明した
# git checkout b1 && git log
9062cd7 "b1.1"
8dcef6c "+1"
b505f18 "master after b1.1"
2fbbe67 "Initial commit"
そのようなこと