「製品」ブランチとは別に「開発」ブランチを用意する必要がありますか？
最近、Herokuにステージングサーバーと本番サーバーの環境をセットアップしましたが、すべてがうまく機能しています。 Herokuを使用すると、Gitブランチからデプロイできます。 masterまたはmy-feature。これは私に考えさせました-devブランチが必要ですか？
devブランチは基本的に、developmentの現在のステージとして機能します。ブランチ my-featureが完了すると、devにマージされます。次に、devをstaging環境にデプロイし、すべてがチェックアウトされたら、devをmasterにマージし、masterをproductionにデプロイします。
一見すると、これはワークフローとして理にかなっています。ブランチを見ると、開発中のものと生産中のものはすぐにわかります。通常のmasterブランチが活発に開発およびデプロイされているため、タイムスタンプやSHAコミットハッシュを確認せずに一目で線を引くことは困難です。
私が見ることができる唯一の欠点は、私のコミットログには基本的に、本番環境へのデプロイごとに、devと/-マージされたmasterコミットがあるということです。個人的に私はこれを大きな問題としては見ていません。なぜなら、それは行を定義するのに役立ちますどのコードが本番で使用されているのですか？ 。
このように使用する場合、devブランチを持つことは意味がありますか？
PS-私はこのプロジェクトで一人で働いています。これが開発者向けの一般的なワークフローとして理にかなっているのかどうか、私は興味があります。
これは、1人のWebアプリケーションで作業する1人にとってはやり過ぎだと思います。
私はtagsを使用して、運用サーバーにリリースするバージョンにバージョン番号を付けます。ステージングサーバーはマスターで最新のコミットを使用できますが、プロダクションはタグを使用します。
新しいリリース番号でファイルを更新してコミットする「リリース」スクリプトを用意し、コミットにそのリリース番号のタグを付けます。
はい、これは一般的なワークフローです。たとえば、人気のある gitflowワークフロー には、別個の開発ブランチがあります。
異なるチームは異なるワークフローを使用します。これは異なるチーム構成に由来します。多数の外部の寄稿者がいるオープンソースプロジェクトで機能するワークフローは、必ずしも社内のプロジェクトや個人のプロジェクトで機能するとは限りません。誰にとっても効果的なワークフローはありません。