11

本番コードに git を使い始めたばかりですが、ワークフローでわずかな問題が発生しています。機能の作業中に発生する一般的なコードの改善/技術的負債の修正を処理する方法を理解する必要があります。

私たちが採用したワークフローは、「開発」をメインの統合ブランチとして使用し、「開発」から離れた機能ブランチですべての機能を開発することです。機能が完成すると、開発者はプル リクエストを作成し、全員がそれをレビューしてコメントを提供してから、開発にマージします。これは非常にうまく機能しているようです。

私たちが抱えている問題は、機能の日常的な開発中に、開発者がシステムを改善したり、技術的負債をクリーンアップしたりするために、一般的なコードを変更/リファクタリングしたくなる場合があることです。この変更は価値がありますが、開発中の機能とは直接関係ありません。

私たちのワークフローに基づいて、開発に入る前に独自のプル リクエストとコード レビューを通過する別のブランチで実際に実行する必要があります。ただし、これを実行してもらう場合、完全なコード レビューが行われ、コードが開発にマージされるのを待っている間に、変更を機能ブランチに戻すにはどうすればよいでしょうか。

私たちが持っているアイデアは次のとおりです。

1) 「refactorX」ブランチから機能ブランチへの変更をチェリーピックします。開発を続けて、リファクタリング ブランチからの変更が既にあることを開発にマージするときに、git に (できれば) 理解させます。

2) 「refactorX」ブランチを機能ブランチにマージし、開発を続けます。(注: 「refactorX」の開発の分岐は開発の歴史の後半にある可能性があるため、これには問題があると考えられます)

3) まだわかっていない他のよりスマートなオプション。:)

私たちが探しているのは、ワークフローのこの部分を処理する方法に関するベスト プラクティス ガイダンスです。それについてもっと話し合った後、それが頻繁に発生することを知っており、ワークフローでそれを処理するためのスムーズで効率的な方法を見つけたいと考えています.

推奨事項はありますか？

4

2 に答える 2

4

3 番目のオプションは、開発者がすべてのフィーチャー ブランチをリファクタリングされたブランチにリベースすることです (したがって、リファクタリングの変更がすべての作業に組み込まれます)。次に、リファクタリング ブランチが最初にレビューされていることを確認し、それを開発ブランチにマージします。すべての機能ブランチは開発に基づいており、通常どおりにマージできます (つまり、1 つをマージし、他のものを開発にリベースし、繰り返します)。

ASCII アートでは、リファクタリングを確認する前に:

--- development
               \
                --- refactoring
                               \
                                --- feature1
                                --- feature2

そしてその後：

------ development|refactoring
                              \
                               --- feature1
                               --- feature2

次に、feature1 を終了してマージすると、次のようになります。

------ refactoring --- development|feature1
                  \
                   --- feature2

feature2 を development にリベースします。

------ refactoring --- development|feature1
                                           \
                                            --- feature2

そして、通常どおり feature2 をマージできます。

------ refactoring --- feature1 --- development|feature2
于 2011-12-22T16:43:35.750 に答える
2

開発ブランチを機能ブランチにマージすることを避けようとしているようです。この手順を回避することは有益ですが、特にこのような状況では必要になる場合があります。

私たちが使い始めているテクニックも ですgit rebase --onto。開発ブランチを機能ブランチにマージする代わりに、機能ブランチを開発ブランチの最後に移動して、新しい機能を取得できます。

中央リポジトリを使用している場合、おそらく新しいフィーチャー ブランチ名を作成するのが最も便利です。たとえば、新しいブランチ名に -v2 を追加します。

典型的な移動プロセスは次のようになります。

git checkout feature
git branch -m feature-v2
git rebase --onto develop develop
git push -u origin feature-v2

これで、機能ブランチに新しいコードができましたが、develop ブランチを機能ブランチにマージしていません。

于 2011-12-22T17:11:38.793 に答える