1

私はgitを使用しています。現在、私たちは 2 人のチーム メンバーでプロジェクトに取り組んでいます。現在のところ、どちらの作業もわずかに独立しており、一方は UI に焦点を当て、もう一方は API に焦点を当てています。1 日に何度もチェックインするのが好きです。私の典型的なワークフローは次のとおりです。

http://amiridis.net/posts/13

そのため、機能ブランチを作成して作業し、メインにマージしてからプッシュします。ブランチを削除し、同じブランチを再作成します。

製品はまだ最初のバージョンであり、継続的インテグレーション ビルド サーバーのセットアップがあります。プッシュの主な目的は、スーパーバイザーへの増分更新を取得することです。

私の質問は、

  • 機能を完全に完成させていない場合、メイン ブランチのメイン サーバーがまだバージョン 1 であれば、コンパイル可能な変更の小さな単位をメイン サーバーにプッシュすることをお勧めしますか?
  • ブランチを作成し、メインにマージしてプッシュし、ローカル ブランチを削除してから再作成することをお勧めしますか?
4

1 に答える 1

3

質問1

機能を完全に完成させていない場合、メイン ブランチのメイン サーバーがまだバージョン 1 であれば、コンパイル可能な変更の小さな単位をメイン サーバーにプッシュすることをお勧めしますか?

いいえ。通常、未完成のコードをメイン ブランチに導入することはお勧めできません。本番コードの状態を模倣するブランチを常に用意する必要があります。ほとんどの人にとって、そのブランチは と呼ばれmasterます。

これが重要である理由の一例は、本番環境でのバグの場合です。未完成の作業をメイン ブランチにすでに導入している場合、リリースする修正には未完成の作業も含まれます。また、他の開発者がそのブランチからプルしており、テストされていないコードを追加した場合、開発が複雑になる可能性があります。

コードがまだリリースされていない場合でも、完全にテストされた動作中のコードのみを含むブランチが必要になります。一般的に言えば、可能な限り機能を分解し、小さな変更をテストするようにしてください。これらは、すでに機能している他のものに悪影響を及ぼさない場合、メイン ブランチにマージできます。

どのように作業しても、ある程度の「権限」を持つブランチ (いくつかの基準を満たした後にのみマージされるブランチ) を維持するようにしてください。その基準が何であるかは、あなた次第です。

新しいバージョンがリリースされたときだけ変更されるマスター ブランチを保持することにするかもしれません。代わりに、作業がテストされたらすぐにメイン ブランチにマージできると判断しました。これをどのように行うかは、多くの場合、リリース戦略とより広範なワークフローに依存します。

質問2

ブランチを作成し、メインにマージしてプッシュし、ローカル ブランチを削除してから再作成することをお勧めしますか?

はい/いいえでは答えられません。チームがコードのバージョン管理、メンバー間のコラボレーション、およびリリース サイクルをどのように処理するかについては、多くの戦略があります。

一般的に言えば、ブランチがメイン ブランチにマージされたらすぐにブランチを削除することをお勧めします。通常は、同じブランチ (一般に「寿命が長い」ブランチと呼ばれます) を使用し続けることは避け、削除することをお勧めします。個々の開発タスクでは、ほとんどの状況で存続期間の短いブランチが好まれますが、チームの好みや選択によって変わる可能性があります。

ワークフローの問題

あなたのチームは小規模で、コードはまだ公開されていません。2 人だけなので、プレッシャーが軽減され、ソリューションがより簡単になります。ただし、製品が世に出ると、バグを解決するというプレッシャーが高まります。おそらく、ホットフィックスやパッチをリリースする必要性が生じるでしょう。リリース サイクルは、ますます同時開発によって複雑になります。バージョン管理のさまざまなレベルの理解を持つ開発者をチームに追加するにつれて、コラボレーションはより混乱し、エラーが発生しやすくなります。

そこで、ワークフローを決定する際に心に留めておくことをお勧めするいくつかの点を以下に示します。

  • ホットフィックス/パッチ - バージョン 2 ですでに半分は完了しているが、1.0 に重大なバグが見つかった場合、2.0 の不完全な作業を含めずに v1.1 をリリースするのはどれほど簡単か
  • ロールバック - 途中でバグが発生した場合、バグのあるバージョンから簡単に元に戻せますか?
  • 区画化 - 壊れたコードやテストされていないコードを、特に同じことに取り組んでいないチーム メンバーと共有しないようにしてください。開発中にテストされていないコードを常に取り込むと、エラーの原因が私にあるのか、それとも別のチーム メンバーによってコードの他の場所で変更が加えられたのかを判断するのが難しくなります。テストと検証が完了したら、他の人のコードを取り込む必要があります。ブランチの存続期間を短くし、簡単にテストできる小さな変更を加えることで、テスト済みの更新がチーム メンバーにより早く届き、バグがより早く発見されるようになります。
  • コラボレーション - 自分の作業を継続するために、実際にお互いのコードが必要になることがあります。だからこそ、短期間の小さな変化が重要なのです。ただし、2 人のユーザーが文字通りまったく同じ作業を行っている場合があります。つまり、同じ機能で共同作業を行っている場合があります。この場合、同じリモート ブランチで作業するのが合理的です。ただし、git-reset、git-rebase、強制プッシュの実行、またはリモートでコミットを変更する何かを行うと、チーム メイトに多大な損害を与えることに注意してください。ブランチを共有するときは、そのブランチの履歴に注意してください。
  • 複雑さ - チーム メンバーは、バージョン管理全般と git に関するさまざまなレベルの理解を持っています。全員が git の専門家であっても、通常はシンプルであることが最善です。何かをテストしたり、何かを正式なブランチにマージしたり、他の開発者とコードを共有したりするために 1 人が実行しなければならない手順の数は、できるだけ少なくする必要があります。誰もが1日に何度も行うことです。複雑なプロセスは開発者の時間を浪費するだけでなく、誰もがエラーを起こしやすくなりますが、経験の浅い人はより頻繁にエラーを起こしやすくなります。これらのエラーは、他の人が問題を解明しようとしているため、さらに遅れる可能性があります。他の考慮事項は、複雑なレイヤーを追加することを意味する傾向があるため、通常、他の考慮事項とは反対に機能します。その複雑さを抑えることを忘れないでください。

一般的なワークフローは「git flow 」として知られており、関連する手順を自動化するのに役立つコマンド ライン ツールさえあります。小規模なチームの場合、複雑すぎると感じるかもしれませんが、イテレーション ベースのリリース サイクルを使用している場合は、これが最低限の作業であることをお勧めします。

私は実際には git-flow の大ファンではありませんが、実際にはあまりにも単純で二次元的であると感じているからです。(私は「分散型だが集中型」のファンではなく、実際に分散されたワークフローを好みます)。

ただし、リリース サイクルのペースが非常に速い場合は、github 自体が使用するモデルを採用することをお勧めします。それらのモデルは、単にマスターにマージするという点であなたのモデルに似ていますが、コードがいくつかの自動テストに合格した後にのみマージします。github が行うことの重要なポイントは、ほとんどのチームが行うようなリリース サイクルではなく、1 日に何度もデプロイするという事実です。これにより、本番環境に移行するバグはほとんどの場合、最近導入されます。これはより単純な戦略ですが、すべての人に当てはまるわけではありません。特に、より一般的なリリース サイクルを使用している場合は、上記の箇条書きに注意してください。

于 2013-04-03T00:06:52.437 に答える