0

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

master
develop
hotfix
feature

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

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

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

4

2 に答える 2

0

私は同様のアーキテクチャを持っています：マスター、ホットフィックス、開発。

開発する新しい機能があると想像してください。私の手順は何ですか：

各新機能には新しいブランチがあります。

git checkout -b issue1234
<make some updates...>
git commit -a -m 'mensagem'
git push origin issue1234

開発ブランチとマージして、他の開発とどのように機能するかを確認し、テスト ケースを実行できます。

git checkout dev
git merge issue1234
git push

人々はいくつかのテストを行い、それを編集して、デプロイする準備ができていると判断します!

git checkout master
git merge issue1234
git push

masterとdevelopを決してマージしないことに注意してください。機能がマージされるだけです。

これが最善のアプローチかどうかはわかりませんが、作成された機能/問題ごとにどのコードが変更されたかを常に知ることができます。

于 2012-12-11T21:48:26.937 に答える
0

実際には非常に簡単です。テスト サーバーに必要なものをすべてテスト サーバーにプッシュします。コードをマスターにマージする準備ができていない場合は、まだマージしないでください。開発ブランチまたはトピック ブランチをプッシュしてください。害はありません。実際、裸のリポジトリに多くのブランチがあるのは普通のことです。

実際、継続的インテグレーションのビルドとテストを開始するコミット フックがある場合は、現在テストしているすべてのブランチがそこにある必要があります。

于 2012-12-11T21:11:24.603 に答える