開発者ごとにリモートブランチを持つことは良い習慣ですか？

プロジェクトの個々の開発者ごとにリモートブランチを用意することは良い習慣と考えられますか？

次のブランチでGitを使用しています。

• 主人
• 解放する
• 発展させる

各開発者が独自のブランチを持っている場合、彼らはコードを自分のブランチにプッシュし、他の開発者はこれらの変更を独自のブランチにマージできます。

番号！開発者ごとにリモートブランチ名前空間を用意することをお勧めします。

多くの場合、単一のブランチでは十分ではないため、開発者はそれを何度も巻き戻してしまうか、あまり役に立ちません。あなたはむしろ開発者が彼らの望むものをtheir.nameの下にプッシュできると言いたいです/。他の人にプレビューバージョンを公開するためにそれを使用して、他の誰かがテストしたり、他の誰かが統合するためのバージョンを提供したりできます。

これを使用して、インテグレーターにブランチを提供したり、タスクベースの名前を使用したりできます。通常、タスクベースの名前はインテグレーターにとって追跡が簡単ですが、開発者に名前についてもっと考えさせ、人々は考えたくないのです。どちらが実際にうまくいくかわかりません。特定のチームに依存することさえあるかもしれません。

ブランチを自分で作成および破棄し、ブランチの目的を明確に文書化できる何らかのgithubスタイルのインフラストラクチャがない限り、各開発者に中央サーバー上のブランチを与えないでしょう。一部の開発者は複数のブランチを必要とし、まったく必要ない開発者もいますが、すべての人が整理し、自分自身の管理オーバーヘッドを整理するために混乱を生じています。

代わりに、gitが優れている有機的な共有の種類を奨励します。自分のマシンでベアクローンを作成し、そのフォルダーを他のユーザーがプルできる読み取り専用のSMB共有にするのは非常に簡単です。実際、あなたの開発者の何人かがまだこれをやっていないとしたら、私は非常に驚きます。

それは、開発チームとタスクの編成方法によって異なります。私の意見では、指定したモデルは次の場合に最適に機能します。

1. 各開発者は自分で独立したタスクに取り組みます。
2. すべての開発者が同じタスクに貢献しています。

これがうまく機能しない可能性があるのは、開発中の並行機能プロジェクトがあり、それぞれに複数の開発者が作業している場合です。

各開発者が独自のブランチを提供することは、同じファイルに影響を与える可能性のあるさまざまなことに取り組んでいる場合に役立ちます。それは互いにつま先を踏むことを防ぐのに役立ちますが、それはすべての人が頻繁にマージし、競合を管理するときに責任を負うことを必要とします。これは私のオフィスで行われていることであり、編集したファイルの半分を手動でマージしなければならないというまれな日は別として、かなりうまく機能します。

複数の開発者が同じ機能に取り組んでいる場合は、開発者ではなく、開発中の機能に基づいてブランチを作成する方が良いでしょう。

Gitを使用している場合は、プルリクエストを試す必要があります。

要約すると、最初にmasterブランチを現在の作業ブランチにマージします。マージの競合はローカルブランチにあります。あなたのマスターブランチは決して壊れないので、これは素晴らしいです。あなたが本当に失敗した場合、あなたはあなたが復帰できるローカルコミットを持っています。

マージが完了したら、チームの他の誰かにブランチをレビューしてマスターブランチにマージするよう依頼します。自分のものをマージしないでください！誰もこっそり入って別のプルリクエストを行わない限り、正常にマージされることが保証されます。誰もがプルリクエストを認識しているので、複数の人が同時にマスターにマージすることは避けてください。

このプロセスに慣れたら、できるだけ頻繁にマージするようにしてください。一種の貧乏人の継続的な統合です。衝突の間隔が短いほど良いです。2人が作業を複製しているときに、チームが協力できる時期を特定します。一部の場所は、要件を完了するたびにマージされます。これは数時間ごとになる場合があります。少なくとも週に1回はマージすることをお勧めします。それ以外の場合は、タスクをより適切に分割する必要があります。

通常、タスクごとに1つのブランチを作成します。ローカルコミットとプッシュを区別するため、Gitは優れています。これは、すべての複雑さを伴うことなく、各自が独自のブランチを持つという利点のいくつかを提供します。