2

開発者は、 「ハードコードされたリンクを修正する」と呼ばれる機能の作業を開始します。作業が完了すると、ピアレビューのために別の開発者に渡されます。ピアレビューアはコードの変更に問題がなく、機能ブランチをテストブランチにマージします。「ハードコードされたリンクを修正する」がテストサーバー上にあり、テクニカルテストを待機しています。

testは、別の開発者によってピアレビューされた後stagingに機能ブランチがマージされる場所であり、ピアレビュー、TT、およびUATを通過した後に機能ブランチがマージされるブランチです。

次の開発者は次のカードの作業を開始し、次のようなブランチを作成します。

git checkout test
git checkout -b story/bar

開発者は作業を終了し、ピアレビューに渡します。査読者は、TTとUATに渡されるコードに満足しており、すべてが満足しており、POに渡されます。POは満足しており、機能ブランチをステージングにマージします

git checkout staging
git merge origin/story/bar

そうすることで、特定のカードの修正に添付されたパッチだけでなく、ブランチに付属する履歴全体も適用していることがわかりました。その結果、 「ハードコードされたリンクを修正する」というコミットがステージングされますが、プロセスは完了していません。

  • 私たちのアプローチとそれを改善するための提案に何か問題がありますか？
  • ステージングから機能ブランチを作成する必要がありますか？
4

1 に答える 1

1

feature基本的に、マージワークフロー（ to testto stagingto ...）だけでなく、パブリケーションワークフロー（プッシュ/プル）を考慮する必要があります。このパブリケーションワークフローは、マージワークフローと直交しています。

新しいfeatureブランチは、それを使用する最新の公式バージョンの上に開発する必要がありますfeature。

の場合、それは次stagingのことを意味します。

git fetch
git checkout -b newFeature origin/staging
# hack...

# make sure newFeature still works on top of staging as right now
# since staging might have received other feature 
# during the development of newFeature

git fetch
git rebase origin/staging
# local and/or unit tests...
# push for review
git push -u origin newFeature

featuretotestまたはをマージするときは、上にstagingリベースし、次に上にリベースし、そのときだけマージする必要があります（早送りマージ）。 リベース中に競合が発生すると、機能が拒否されます（開発者は、競合が発生する理由を確認するために、問題の原因に加えて、そのブランチをローカルでフェッチしてからリベースする必要があります）。newFeatureteststagingnewFeature
newFeature

于 2013-03-27T06:49:44.810 に答える