1

私は行ったり来たりしていて、どちらのワークフローが優れているかを完全に判断することはできません。マスターにマージされたブランチを押しつぶしたい場合。または、それらをマージする必要があります。

私はmerge-squashを好み、一貫して使用しています。

マージの長所--squash：

  1. よりクリーンな歴史。
  2. バイセクトが使いやすい。

merge --squashを使用して、代わりにプレーンな古いマージを使用するべきではない理由はありますか？

4

2 に答える 2

3

早送りマージは、機能しない可能性のあるものを試行するために分岐する場合など、断続的なコミットをすべて保持する場合に役立ちます。作業ブランチをリセットするよりも、一時ブランチを破棄する方が簡単です。ただし、実験が機能する場合は、コミットを作業ブランチに早送りして、実験が続けられていた場合と同じように残すことをお勧めします。

作業中のコミットを、すべての変更をカバーするメッセージを含む単一の包括的なコミットに押しつぶさないことを私が知っている理由はありません。お気づきのとおり、これにより履歴がクリーンになり、操作が簡単になります。私が見てきたことから、それは木をきれいに保つための好ましい方法です。

git merge --squash1つの親とコミットするため、マージされる親への接続は表示されません。

-A---------C  <-- `git merge --squash`
  \
   *--*--B

もう1つのオプションは、git merge --no-ff（早送りなしで）マージコミットを強制することです。このコミットには両方の親があります。利点は、必要に応じて詳細なコミット履歴を保持しながら、ツリーをクリーンに保つことです。

-A---------C  <-- `git merge --no-ff`
  \       /
   *--*--B

両方Cのコミットは同じです。保持する場合は、後で選択しますB。

于 2013-01-15T19:27:37.890 に答える
2

場合によります。

押しつぶすと情報が失われます。押しつぶすかどうかは、その情報が重要かどうかによって異なります。6か月または6年先の誰かにとって、コードの行がそのようになっている理由を理解しようとすることは重要です。これは、ブランチの内容、変更の数、変更のサイズ、およびログメッセージの品質によって異なります。

簡単な経験則？スカッシュの結果を考慮して、「マスターでコーディングしている場合、これをコミットしますか？」と自問してください。答えが「はい」の場合、差分とログを一緒に取得することで、将来、コードの行が変更された理由を理解し、マージを潰すことができます。

答えが「いいえ」の場合、これはマスターへの受け入れ可能なコミットではありません。変更が多すぎるか、絡み合った変更が多すぎる場合は、押しつぶさないでください。おそらくブランチ内のコミットが一緒に潰される可能性があるかどうかを検討した後、それをマージします。

「よりクリーン」で「二分しやすい」押しつぶしについては…それは表面的にしか当てはまらないと思います。本棚にあるすべての本のページを取り出して、1冊の本を心配するだけでよいという点で「よりクリーン」な1つの巨大なカバーにそれらを縫い付けた場合。それらがそれぞれがあなた自身で立つ小説の束であるならば、それは助けにはなりません。それらが年次総会の報告である場合、それらをまとめておく方がおそらく良いでしょう。

ビルドを壊したコミットが発生する可能性が低いという意味で二等分する方が簡単ですが、二等分線が変化の巨大な塊に着地した場合、原因となる可能性のある大量の可能性についてパズルを解く必要があります問題は、二等分線の仕事を難しくしました。

マスターへのコミットに使用するのと同じ基準を使用して、マージをスカッシュするかどうかを決定します。

于 2013-01-16T19:47:14.453 に答える