生産ブランチを持っているか、マスターを使用していますか？

16

私は、Railsアプリケーションに関して他のリモート開発者と小さなチームで仕事をしています。gitワークフローの変更を開始しています。以下のような分岐構造について考えました。

(dev) -> (qa) -> (stag) -> (master)

しかし、一部の開発者は、masterで自動的に本番環境にプッシュする可能性のある新しい開発者にとって混乱が少ないと考えています。代わりに、全員がマスターで作業し、本番用に別のブランチを作成すると考えました。

(master) -> (qa) -> (stag) -> (prod)

マスターを展開可能な状態に保ち、開発として使用したくないことを教えられました。また、私がマスターをしていた以前の場所からは、常に本番環境に展開できるようになっています。

マスターが開発に積極的に使用され、別のprodブランチがデプロイメントに使用されるブランチ構造を使用する場合の欠点は何ですか？

git

私の経験では、人々が自由にコミットできる1つの場所（毎日のチェックインなど）があれば、それは成果を上げます。「常にコンパイル」する必要はありません。それがなければ、人々はチェックインを遅らせ、事故（たとえば、ディスクのクラッシュ）でコードを失うリスクを負います。その後、そこから意味のあるバージョンを伝達し、統合ストリームに向けて「リリース」するのは彼ら次第です。私の好みのステージのセットは（dev）->（units）->（integration）->（test）->（production）

— -BitTickler

2

このサイトで説明されているgitワークフローは、いくつかの違いはありますが正常に使用されています。nvie.com/posts/a-successful-git-branching-model唯一の違いは、「1コミット1つの問題」私たちはクリーンhistoriをmantainとロジックを追跡するために、1つの開発にローカルブランチの押しつぶしを好むということです

— Jepessen

通常、「stag」ブランチでは何が起こりますか？

— simgineer

より明確なCI / CDを推奨します。masterブランチは誤解される可能性があるため使用されません。{develop}-{unit}-{integration}-{staging}-{production}。青/緑では、生産が継続的に構築>アクティブスライス、ステージング>非アクティブスライス。HEAD>機能が分岐するブランチを開発します。統合とステージングに進むユニットに向けてビルドをトリガーするwebhookを開発します（統合に合格したときに適切なタグを使用）開発+本番に向けたホットフィックス（まれですが、発生します）。より複雑ですが、一般的なアイデア。

— ジミーMGリム

16

このアプローチには長所も短所もありません。私がこれを言う理由は簡単です：Gitにとって、masterから開発する場合でもmasterからリリースする場合でも違いはありません。ブランチをリリースする必要さえありません。代わりに、任意のコミットにタグを付けてリリースできます。

ここでの本当の問題は、プロセスと手順の1つです。ある方法でそれを行うことを心配するより上級の開発者は、新しい開発者がリリースモデルとは何か、なぜそのようになっているのかを説明する時間を費やす準備が必要であることを混乱させます。

マスターが開発用であり、他の任意のブランチがリリース用であり、これを維持する作業が完了していることを誰もが理解している限り、このアプローチに問題はありません。

— まこと
ソース

1

私は本当にあなたが良い点を打ったと思います。フィードバックをお寄せいただきありがとうございます。

コミットのタグ付けに+1。私はほとんどの時間を自分で仕事をしていますが、2つの理由でリリースにタグを付けています。1）ビジュアルgit履歴ツールと連携して、どのコミットが実際に運用されているかを表示します。2）タグ付きコミットをチェックアウトし、使用するためにzipファイルにパックすることにより、リリースバージョンをパッケージ化できるGitHubなどのツールで最適に動作します。

— nbering

9

あなたのジレンマを見ることができます。私も、マスターについていつも思っていたことを学ぶまで、それを持っていました。

マスターを展開可能な状態に保ち、開発として使用したくないことを教えられました。また、私がマスターをしていた以前の場所からは、常に本番環境に展開できるようになっています。

Gitのドキュメント/本から-Gitの分岐

Gitの「マスター」ブランチは特別なブランチではありません。他のブランチとまったく同じです。ほとんどすべてのリポジトリに1つのリポジトリがあるのは、デフォルトでgit initコマンドが作成するため、ほとんどの人が変更を気にしないからです。

したがって、優先するワークフローがあり、チームの異なる開発者がについて異なるアイデアを持っているため、それを使用するのが難しい場合master。次のようなワークフローを使用して名前masterを変更することを検討することもprodできます-

(dev) -> (qa) -> (stag) -> (prod)

マスターブランチ名を変更する方法は次のとおりです。

masterブランチ名を変更する必要があると言っているわけではありません。ただし、優先するワークフローがあり、masterブランチ名の変更に役立つ場合は、必ずそれを行ってください:-)

— スミート・パリーク
ソース

それは非常に良い点です。それを実現してくれてありがとう。名前を変更するのかどうかはわかりませんが、gitはmasterを特別な方法で処理しないことを知っているのは良いことです。ありがとう！

6

この場合、規約よりもチェックを優先します。すべてのチームには、新機能を開始するのが得意なメンバーと、リリースのために物事を安定させるのが得意な人が含まれています。

後者がない場合は、コードレビューが役立ちます（多くの場合、規律のある人はコードレビューを必要とします）。

そのため、特定の人だけがプルリクエストをマージでき、各開発者がメインリポジトリのプライベートフォークを取得できるようにGitリポジトリを構成します（Gitlabを使用しています）。

これにより、2つの問題が解決されます。

新しい開発者は間違ったブランチを変更できません（メインリポジトリに作業を直接プッシュできないため）。彼らはmaster自分のレポジトリにプッシュするかもしれませんが、プルリクエストが来たら修正されます。
各コミットは、少なくとも自分の意見と知識を持っている別の人によってチェックされるため、コード規約はチーム全体に急速に広まりました。

— アーロン・ディグラ
ソース

1

それはすべて、ソフトウェア開発プロセス全体に依存します。構成管理と新しいバージョンがどのようになるかは、プロセス全体を知らないと定義できません。

「常に最初にコミットする作業領域」を選択する「アジャイル」ファクションがあります。彼らは自動化されたビルドおよびテスト施設をそのエリアに対して絶えず実行し、「常時」動作するシステムを持つことを試みます。

彼らは（マスター）->（リリース）を、おそらく1,2の中間ステップの編成で有益だと見なすでしょう。

次に、より多くの「クラシック」ファクションがあります。これは、マイルストーンに向けた計画および計画された統合ステップによって駆動されるプロセスを持ちます。そして、次の計画されたマイルストーンに適合すると思われます」。そこでは、計画は「作業単位」のバージョン管理で構成され、通常、機能と修正の観点から次の計画された製品リリースがどのように見えるかを定義するために長くなります。計画のために、開発者がリリースするものが「適切」であり、作業単位をコミットするという意識的な行為であることを知りたいと考えています。

その古典的なアプローチは、必ずしも完全な製品ビルドが利用できない時間が長いことを意味するわけではありません。

したがって、「クラシック」ワークフローは次のようになります：（dev）->（unit）->（integration）->（test / qa）->（production）。

インテグレーターの役割は、リリースされたユニットを「受け入れる/購入する」か、次のリリースのニーズに合わない場合は拒否することです。

補足として、これら2つの基本的なアプローチを適切な方法で混在させることもできます。

私の経験（主に「クラシック」アプローチを使用する分野にありました）から、「クラシック」アプローチはチームの約4〜50人のプロジェクトでうまく機能しました。

— BitTickler
ソース