3

私は小さなチームで「マージ ワークフロー」を使用して作業してきましたが、最近、Sandofsky の記事に従って「リベース ワークフロー」に切り替えました。

現在のワークフロー:

  1. git checkout マスター、git pull オリジン マスター
  2. git checkout -b feature_branch、いくつかの作業を行い、git commit -am "msg for feature branch"
  3. git チェックアウト マスター、git プル元マスター、git リベース マスター feature_branch
  4. git チェックアウト マスター、git マージ --squash
  5. git commit -am "マスターブランチのメッセージ", git push origin master

フィーチャー ブランチをリベースした後、マスターにスカッシュ マージします。代わりに --no-ff を使用するとどうなるでしょうか? git merge --squashとはどう違いgit merge --no-ffますか？

4

3 に答える 3

4

--squashマージのすべての変更を含む単一のコミットを作成します (マージされたブランチの履歴全体を 1 つのコミットに押しつぶします) 。--no-ffまた、ブランチにマージし、マージ コミットを作成して、マージされたブランチの履歴全体を保持します。

于 2013-08-22T19:28:56.347 に答える
4

git merge --squash通常の で適用するすべての変更を適用する単一のコミットを作成しますmerge。したがって、ブランチに持ち込むすべてのコミットを 1 つのコミットに統合します。

git merge --no-ff早送り (ソースとターゲットが分岐していない場合に、ブランチ ポインターを新しいコミットに移動する操作) を防ぎます。したがって、--no-ffあなたを使用すると、親が現在HEADのfeature_branchヘッドである新しいコミットが作成されることが保証されます。

両方のシナリオを使用すると、最初のシナリオでは、それぞれがダイジェストlogである 1 行のコミットが表示されますが、2 番目のシナリオでは、多数の分岐が表示され、それぞれに 1 つずつ、すべてが再度結合されます。feature_branch feature_branchmaster

それらgit merge --squashに基づいて新しいコミットを生成するとfeature_branch、それらは異なるコミットであるため、feature_branch単独で公開すると問題が発生する可能性があります-たとえば、理解git merge --squash feature_branchせずに何度も公開できgitますが、競合が発生します.

于 2013-08-22T19:29:25.603 に答える