84

この記事は面白そうですが、図が間違っていると確信しています。 http://guides.beanstalkapp.com/version-control/branching-best-practices.html

DEVELOPMENT> STAGING>ではないPRODUCTIONでしょうか。

マージは、独自のブランチまたは開発で行われた機能修正とバグ修正から、テスト用のステージングまで、一方向にのみ流れる必要があります。テストが完了したら、これらの変更を開発から本番にマージできます。

ここで、私は少し混乱します。では、ステージングをマスターに、またはマスターをステージングにマージしますか?

私は SmartGit というクライアントを使用していますが、この点について混乱しています。通常、機能のブランチを作成し、それにコミットしてから、マスターに切り替えてブランチにマージします (フォワード)。したがって、ステージングとプロダクションを含むこの新しいワークフローでは、これら 2 つの追加のブランチを作成してから、フィーチャー用にマスター (別名 dev) からブランチを作成します。それにコミットしてから、ステージングに切り替えて、機能ブランチにマージ (転送) しますか? その音は正しいですか？

実際、これを非常に混乱させたのは、Beanstalk の人々が非常に非標準的なステージングの使用を支持していることです (図では開発の前に来ており、間違いではありません! https://twitter.com/Beanstalkapp/status/306129447885631488)

Beanstalk を忘れて、Github だけを使用することにしました。

私がこれを投稿して以来、Beanstalk の人々は私のヒントを得て、ステージの名前を変更し、現在は Development を "Stable" と呼んでいます。

4

4 に答える 4

103

ここでの思考プロセスは、ほとんどの時間を で過ごすということですdevelopment。開発中は、featureブランチ ( のオフdevelopment) を作成し、機能を完成させてから にマージしdevelopmentます。これは、 にマージすることにより、最終製品バージョンに追加できますproduction。

このアプローチの詳細については、「成功する Git ブランチ モデル」を参照してください。

于 2013-02-25T17:02:59.250 に答える
5

私たちはそれを別の方法で行います。私見では、より簡単な方法でそれを行いますmaster。つまり、次のメジャー バージョンに取り組んでいます。

より大きな機能はそれぞれ独自のブランチ (マスターから派生) を取得し、開発者によって定期的にマスターの上にリベース (+ 強制プッシュ) されます。リベースは、1 人の開発者がこの機能に取り組んでいる場合にのみうまく機能します。機能が終了すると、新しくマスターにリベースされ、マスターが最新の機能コミットに早送りされます。

リベース/強制プッシュを回避するために、マスターの変更を機能ブランチに定期的にマージし、完了したら機能ブランチをマスターにマージすることもできます (通常のマージまたはスカッシュ マージ)。しかし、私見では、これにより機能ブランチが不明確になり、コミットの並べ替え/クリーンアップがはるかに難しくなります。

新しいリリースが予定されている場合は、master からサイド ブランチを作成します。たとえばrelease-5、バグのみが修正されます。

于 2013-02-25T20:16:17.160 に答える
3

実際、これを非常に混乱させたのは、Beanstalk の人々が非常に非標準的なステージングの使用を支持していることです (彼らの図では開発の前に来ており、それは間違いではありません!

https://twitter.com/Beanstalkapp/status/306129447885631488

于 2013-03-13T19:12:16.390 に答える
2

gitの最も優れた点の 1 つは、自分に最適なワークフローを変更できることです。ニーズに合ったワークフローを使用できます

于 2013-02-28T23:50:47.830 に答える