(TFSを介して)gitブランチのワークフローにGitflowを使用しています。リリースが成功すると、次のことを行います
ステップ1はコミットを作成します(マージされたPR XXX:マスターへのリリースのマージ)
ステップ2はコミットを作成します(マージされたPR YYY:リリースをマージして開発)
私たちのブランチを見ると、開発はマスターの背後にある1つのコミットであると書かれています。これは、コミット(マージされたPR:XXX)が開発中でないためです。
(プルリクエストに変更がない場合でも)マスターから別のプルリクエストを作成して開発する正しい手順はありますか?
これは標準では見られません Gitflowモデル
これはフィクションの長さになるので、ごめんなさい。私が提出している短い答えは、gitフローのリリースが完了すると、develop
がどのようにmaster
のコミットaheadになるかということです。 git flow origniator Vincent Driessen は、独自の git-flowスクリプト を実装しました。
git-flow
での経験についてはわかりませんので、明白なことを言っている場合はご容赦ください。 git-flow
仕様には、使用を簡単にするためのスクリプトのセットがあります。 Gitフロースクリプトは、Git for Windowsに付属して出荷され、TFS参照に基づいて使用していると想定しています。
Git Bash経由で最近のリリースの履歴を確認しましょう
$ git log --oneline --graph --decorate
どの年
上の画像で気づくでしょう
$ git flow release start v2.1.0
を発行しました。release/v2.1.0
を作成しました。このブランチには、1つのコミット(バージョン番号の増加)のみが含まれています。$ git flow release finish -k
を使用して終了しますrelease/v2.1.0
をブランチmaster
にマージしますmaster
をdevelop
にマージして、リリースブランチのすべてのコミットが次のリリースの開発に戻るようにします。ワークフローでTFS PRを使用している場合、リリースPRを完了する準備ができているときに、おそらくこのようなものが表示されます。
私のショップでもPRを使用していますが、$ git flow release finish -k
を使用してローカルでマージし、master
ブランチとdevelop
ブランチをプッシュします。 TFSはリリースブランチが既にマージされていることを認識し、以下に示すようにPRを「完了する」のではなく「閉じる」オプションを提供します。
私はあなたが説明する追加のマージを行ったことはありません(またはそうしたチームに参加したことはありません)。 couldリリースをマージして開発する代わりに、開発者がマージして開発したいと思う-または、少なくとも、問題が発生することは考えられない...しかし、本当にdevelop
が「遅れている」ことの何が問題になっていますか?基本的には、gitflow IMOの通常の状態です。
あなたのシナリオでは、開発ブランチにはマスターの背後に1つのコミットがあり、マスターのコミットが1つある必要があります(マージされたPR YYYのため)。マスターから別のプルリクエストを作成して開発する場合、開発ブランチには別の新しいコミット(マージされたPR ZZZ)があり、マスターに1つのコミットがあります(それでいいですか?)。
リリースから開発へのプルリクエストを作成する代わりに、マスターから開発へマージすることもできます。