この記事は面白そうですが、図が間違ってるのは間違いないですね。 http://guides.beanstalkapp.com/version-control/branching-best-practices.html
DEVELOPMENT」「STAGING」「PRODUCTION」であるべきではないでしょうか?
マージは一方向にしか流れないようにする: 機能とバグフィックスから 自分のブランチや開発で行った変更を、テストのためにステージングに移す。 テストが終わったら、その変更を開発からステージングにマージします。 制作しています。
ここで少し混乱しました。つまり、StagingをMasterにマージするのか、MasterをStagingにマージするのか?
SmartGitというクライアントを使用しているのですが、この点で戸惑うことがあります。通常、私は機能のためにブランチを作り、それにコミットし、次にmasterに切り替えてブランチにマージします(前進)。しかし、ステージングとプロダクションを使った新しいワークフローでは、この2つの余分なブランチを作成し、次にmaster(別名dev)から自分の機能用のブランチを作成します。そのブランチにコミットし、次にステージングに切り替えて、私の機能ブランチにマージ(フォワード)する?これでいいのでしょうか?
Beanstalkの人たちは、Stagingの使い方が標準的でないことを支持しています(彼らの図では、Stagingは開発より前に来ています! https://twitter.com/Beanstalkapp/status/306129447885631488
Beanstalkのことは忘れて、Githubだけでやっていくことにしました。
この記事を投稿してから、Beanstalkの人たちは私のヒントを得て、ステージの名前を変更し、現在はDevelopment "Stable" と呼んでいます。
ここで考えるのは、あなたはほとんどの時間を development
で過ごしているということです。開発では、(development
から)feature
ブランチを作成し、その機能を完成させ、development
にマージして戻します。その後、production
にマージすることで、最終的な製品版に追加することができます。
この方法の詳細については、A Successful Git Branching Modelを参照してください。
私たちはそれを違う方法で行っています。master`では次のメジャーバージョンに取り組んでいるのです。
大きな機能ごとに(master から派生した)独自のブランチが作成され、開発者によって定期的に master の上にリベース(+強制プッシュ)されることになります。リベースがうまくいくのは、一人の開発者がこの機能を担当する場合だけです。もしその機能が完成したら、master の上に新しくリベースされ、master は最新の機能コミットに早送りされます。
リベースや強制プッシュを避けるために、master の変更を feature branch に定期的にマージして、それが終わったら feature branch を master にマージする方法もあります(通常のマージやスクワッシュマージ)。しかし、IMHOはこの方法だとfeature branchが明確でなくなり、コミットの順序を変えたり掃除したりするのが非常に難しくなると考えています。
新しいリリースが来る場合は、masterからサイドブランチを作成し、例えばrelease-5
のようにバグだけを修正するようにします。
実際、これを非常に混乱させたのは、Beanstalkの人々がStagingの非常に非標準的な使用の後ろに立っていることです(図の開発の前に来て、それは間違いではありません)。!