問題タブ [branching-strategy]

git を使用してベスト プラクティスを学び、開発しようとしています。ブランチに関しては、git flow ブランチの練習を読んでいます。この慣行に基づいて、私のブランチは

ローカル リポジトリを使用してローカル マシンで開発しています。プッシュ先の 2 つのリモート ベア リポジトリがあります。1 つは TEST サーバーで、2 番目は LIVE プロダクション サーバーです。これらのリモート リポジトリの両方に、post-receive フックが配置されています。

マスター ブランチは、最終的な製品コード用に予約されていると想定されています。では、どのブランチを TEST サーバーにプッシュすればよいのでしょうか? 現在、開発をマスターにマージしてから、ローカル マスターを TEST にプッシュする必要があります。しかし、そのプッシュの後に何か編集を加えると、マスターは変更されており、実際にはプロダクションの準備ができていませんでした。開発ブランチを TEST サーバーにプッシュする必要がありますか? そして、最終承認後、マスターにマージ開発し、マスターを LIVE サーバーにプッシュしますか?

なぜ私はこれにとても混乱しているのかわかりませんか？私は間違いを犯すことを恐れていると思います。

バックグラウンド

そのため、先月の大部分を、MSDeploy、SSDT、およびTeamCityを使用してWebとDBの展開を自動化することに費やしました。唯一の問題は、デモンストレーションの目的で、私はトランクブランチからしか作業していないということです。言うまでもなく、このアプローチは、並行して開発作業を行う必要があると考えるとすぐに失敗します（SVNのブランチによって分離されます）。これは私が立ち往生していて、いくつかの助けを見つけることを望んでいるところです。

私たちの状況

• ソフトウェアの複数の同時バージョンをサポートする必要はありません
• 顧客は常に現在のバージョンを使用しています

私が思いついたもの（これまでのところ）

私が見ているように、ソース管理には実際には2つのブランチしか必要ありません。

1. 現在：トランク-展開元
2. 次へ：現在のイテレーションの開発ブランチ

新しい反復の開始時に、Currentは分岐します（その分岐をNextと呼びます）。そのイテレーションのすべての開発はNextにコミットされ、同時に、現在のバージョンに必要なバグ修正はCurrentにコミットされます。ある時点で、Nextは「完了」し、したがってCurrentにマージされます。

展開

デプロイメントに関する限り、Nextはどの環境にもデプロイされません。ただし、 Currentは、定期的な間隔（コミットごと、夜間など）でTeamCityによって内部環境に自動的にパッケージ化/デプロイされます。ある時点で、これらのパッケージの1つは「十分に優れている」と見なされ、したがって、（ステージング、本番環境を通じて）デプロイメントストリームをプッシュダウンします。

警告

前述のプロセスを考えると、NextをCurrentにマージすると、 Currentでの「コードのフリーズ」が保証されます。その間、新しいバグ修正をクライアントにリリースすることはできません。このバグフリーズは、 Currentがクライアントにリリースするのに「十分」であると見なされるまで続き、その時点でCurrentにタグが付けられ、プロセス全体が最初からやり直されます。

質問

1. このアプローチ/考え方は合理的ですか？
2. このアプローチはどこに当てはまりますか？
3. これについてもっと良い方法はありますか？

洞察/文書化は大歓迎です。

たとえば、マスターから分岐して、アプリケーションの「新機能 #101」を作成するとします。現在、この機能は、今から X か月 (3 か月とします) までマスターにプッシュされません。その 3 か月の間に、マスターにプッシュされた他の機能を分岐させたり、いくつかのバグ修正をマスターに直接送信したりします。「新機能 #101」以降、14 件以上のコミットを含むマスター ブランチができました。では、「新機能 #101」をプッシュするのに +3 か月と時間がかかるとします。それを master にマージする最良の方法は何ですか? マスターに直接マージしますか、「新機能 #101」をリベースしますか? 正しい方法は何ですか？

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

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

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

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

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

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

ここで、clearcase のタスクごとの分岐戦略に問題があります。
スナップショット ビューを使用しています。さまざまなタスク ブランチと統合ブランチがあります。
そのため、テストのためにブランチを統合にマージします。

ここで、統合ブランチにマージされるファイルで作業していてBR1、このファイルが統合ブランチにマージされていないが、2 番目のファイルが統合ブランチにマージされている別のファイルを参照しているとしBR2ます。

したがって、2番目のファイルはファイルのエディションを指していBR2ますが、これらの変更は望んでいませんでしたが、統合ブランチから他のすべてのコードを取得しているため、そのバージョンを取得しています。

これは私の構成仕様です:

解決する方法はありますか？私が考えることができる1つの方法は、ラベルを付けることです。構成仕様を変更して、最新の統合ブランチからではなく、そのラベルから選択しますが、タスクブランチで作業が進行するにつれてラベルを変更する必要があります。他の方法はありますか?私たちはこれを行うことができますか？

A と B の 2 つのブランチがあり、どちらにもファイル X があります。これらのブランチは 1 つのコード ベースから始まりましたが、その後、プロジェクトのさまざまな実装のためにブランチされているため、マージが互いに織り込まれています。X は A と B で更新されました。(デフォルトの再帰戦略を使用して) git merge を実行すると、(B を A にマージするか、A を B にマージするかに関係なく) A のバージョンのファイルにあるマージの競合が発生します。が追加され、B のバージョンのファイルは削除されました。

gitバージョン1.8.2を使用してシェル（Mac）でこれをテストしました。