まず、いくつかの背景として、私たちはすべてのプロジェクトチームをgitを使用するように移行する過程にあり、特定のブランチを継続的に統合するために監視できるようにリポジトリを編成する方法のガイドラインを策定する過程にあります。テストサーバーへの自動展開。現在、2つのモデルが開発されています。
成功した分岐に関するnvie.comの記事 の影響を強く受けて、最も安定したコードを表すマスターブランチ、最先端のEdgeコードの開発ブランチ、QAテストの準備ができているコードの統合ブランチを使用します。
マスターブランチが最先端の開発コード、QAテストの準備ができているコードの統合ブランチ、および展開の準備ができている安定したコードの本番ブランチを表す代替モデル。
この時点で、マスターブランチが何を表すかに関しては、部分的にはセマンティクスの問題ですが、マスターブランチでアクティブな開発を行うことは実際には良い習慣ですか、それともそれほど関連性がないのですか?
master
ブランチの唯一の実際の定義機能は、一部の操作のデフォルトであることです。また、ブランチ名は特定のリポジトリ内でのみ意味があります。たとえば、私のmaster
はあなたのdevelopment
を指すかもしれません。また、master
ブランチは必須ではないので、どのブランチにする必要があるかについて混乱がある場合は、通常、完全に省略することをお勧めします。
しかし、私の意見では、それを考える最良の方法は、プッシュするためのデフォルトとしてです。開発者が読むほとんどすべてのオンラインチュートリアルは、それを前提としています。したがって、master
が最も頻繁にプッシュされるブランチになることは非常に理にかなっています。一部の人々は、これを厳格な精査の後を除いて開発者が手に負えない手付かずのコピーと考えていますが、その方法を使用すると、gitが提供する多くの有用なデフォルトが削除されます。この種の初期のブランチが必要な場合は、一部の人だけが書き込める完全に別のリポジトリに入れます。
いいえ、QAに進む前の最初であっても、お勧めできません。ベストプラクティスとして、開発のパターンは最初から最後まで一貫している必要があります。マスターブランチは空で開始し、開発ブランチを分岐してファイルの追加を開始し、統合ブランチにマージしてから、マスターに続いてください。
開発中にmasterブランチがビルドされないことを誰も気にしないかもしれませんが、それは早い段階で悪い習慣に役立ちます。マスターは常にビルドする必要があり、主要な機能リリースの場合は、メジャービルドのブランチをアーカイブして、必要に応じて安定したリリースポイントに戻すことができるようにしておくことも悪くありません。