マスターにマージする前にコミットをスクラッシュする方法は？

Question

私はmasterから分岐し、新しいbranch branchAで働いていました。私はbranchAでいくつかのコミットを行い、今度はmasterをmergeしてbranchAに入れて、最新の変更で更新してください。今私はマスターに合併する前に私のコミットを1つのコミットにスカッシュしたいのですが、どうすればいいですか？私はgit merge --squashがコミットを押しつぶすことができることを知っています。しかし、私はコードレビューの承認を待っているので、今はマージしたくありません。 masterをbranchAにマージしたので、リベースも使うのは良いことではありません。コミットをスムーズにする良い方法があるのだろうかと思っています。ありがとう！

Answer 1

更新：追加されましたコメントbranchだからあなたが持っている

を押された場合についての終わりに

X --- X --- X --- X --- X <--(master) 
     \   \ 
     A --- B --- M1 --- C <--(branch) 

それはあなたが完了したらのように聞こえるあなたは欲しい

X --- X --- X --- X --- X --- ABC <--(master) 

ABCをmasterブランチに配置する準備ができていません。

私はA,B,M1およびCが一度も押されていないと仮定します。この仮定が偽であれば、私はそれらをどのような方法でも潰さないでしょう。

私の最初の考えは、コードレビューを待ってから、その後にスカッシュマージを行うことです。 A ... Cが破棄されることになっている場合、どのような違いがありますか？

しかし、あなたはいくつかの理由でそれを好きではないとが本当にがどのようにこれを目指しについて、-スカッシュを事前にしたい場合は：これに取得するには、いくつかの方法があります

X --- X --- X --- X --- X <--(master) 
         \ 
          ABC <--(branch) 

。ここでは一つだ：

git checkout master 
git checkout -b temp 
git merge --squash branch 
git branch -f branch 
git checkout branch 
git branch -d temp 

しかし、コメント欄での議論に基づいて、それは今A、Bのように聞こえる、とCコミットはプッシュされています。それが本当であれば、のいずれかを押しつぶす方法には欠点があります。

その場合の私のベストアドバイスは、そのままマージし、マージコミットに良いコミットメッセージを書いて、ヒストリを見るとgit log --first-parentを使用することです。この場合、ブランチ上の個々のコミットはログ出力に表示されず、ブランチ全体を表す単一のコミット（マージ自体）がsquashedされたコミットのように見えます。

しかし、あなたがそのアドバイスに従うことを望まない場合、本当に変更を盛り込む必要がある場合、ここでは対処が必要です。branchで作業を続ける人は問題があります。そして、 "誰もそれをしてはいけない"と言うことができます。もしあなたのチームが誰もそれをしないと同意すれば、それはうまくいくでしょう。しかし、branchが共有リポジトリに存在するため、何も起こりません。 最高であなたは面倒な紛争解決に対処しなければならないでしょう。

上記の手順を実行したとします。何本当にを持っていることは、あなたがbranchをプッシュしようとした場合（origin/branchがbranchから到達可能ではないので）、それは失敗します

X --- X --- X --- X --- X <--(master) 
     \   \  \ 
     \   \  ABC <--(branch) 
     \   \ 
      A --- B --- M1 --- C <--(origin/branch) 

です。プッシュを強制することができますし、できるだけ早くCを指すローカルのbranch参照を持つ人は問題が発生します。彼らは訂正することはできませんが、特に誰かが間違った方法で "修正"した場合、面倒になる可能性があります。

branchを強制的に押すことを避けることができます。 branchのバージョンをマスターにマージしてから、masterを押してローカルのbranchを削除してください。

X --- X --- X --- X --- X --- ABC <--(master) 
     \   \ 
     A --- B --- M1 --- C <--(origin/branch) 

は今、あなたがリモートorigin/branch参照の削除を強制しても、他の開発者はまだはローカルbranch参照がCで指摘している可能性があります。そしてその履歴はmasterにマージされていないので（ABCはマージされていない単一のマージでマスタを更新するために作成されたものです）、branchをmasterにマージするとさらに問題になります。

"ours"という戦略を使ってフォローアップマージを行うと、branchが祖先であるmasterというGitを表示することができますが、その時点で通常のマージバック通常のマージの場合と同じように、A、B、およびCがデフォルトのログ履歴にmasterというように表示されます（除外する場合は--first-parentとなります）。

この場合も、これはすべてです。を管理してください。それは不必要な面倒です。なぜなら、ベストプラクティスは、コミットが共有されると、それを履歴の一部にすることができるからです。