私は、基本的に 1 つのブランチ (マスター) しか持たない大規模な Web アプリケーション プロジェクトを持っています。ただし、バグ修正のために新しいブランチを作成し、そのブランチを master ブランチにマージします。簡単なピージー。
ユーザー インターフェイスの大規模なオーバーホールを行いたいと考えていますが、完了するまでに数週間または数か月かかる場合があります。ただし、この間、途中でバグ修正を行う必要があります。
これがどのように行われるかを論理的に理解しようとしています。「UIUpdate」ブランチを作成し、そこですべての UI 更新を行い、同時にバグ修正ブランチを作成してマージしますか? UI のオーバーホールが完了したら、そのブランチをマスター ブランチにマージして、すべてのバグ修正コードが上書きされないと仮定してもよいですか?
私の脳は、これがどのように可能になるかを理解するのに苦労しています.
ありがとう
はい、まさにそれができます。Git は、複数のブランチが非常に簡単に共存できるように設計されています。次のように新しいブランチを作成します。
# running this operation while on master
git checkout -b this_cool_feature_Im_working_on
ここで重要な部分は、マスターとの同期を維持することですthis_cool_feature_Im_working_onが、必ずしもその逆ではありません。バグ修正を作成し、後でそれをそれにマージするたびに、masterそのバグ修正も行ってマージすることをお勧めしthis_cool_feature_Im_working_onます。これにより、 でまだ発生している変更を確実にthis_cool_feature_Im_working_on把握できmasterます。これにより、マージの競合が発生した場合の処理の難しさが最小限に抑えられるため、これは重要です。で行われた変更は に送信さthis_cool_feature_Im_working_onれるため、 に比較的近くなります。これにより、作業が整理されます。マージの競合が発生するのを防ぐことはできませんが、心配する必要はありません。競合の解決は git のワークフローの一部です。mastermasterthis_cool_feature_Im_working_on
準備ができたら、this_cool_feature_Im_working_onマスターにマージできます。定期的ににマージmasterしていthis_cool_feature_Im_working_onた場合、最終的にこれにマージしthis_cool_feature_Im_working_onて戻すときにmaster、いくつかの小さくて簡単に解決できるマージ競合が生成されるだけで、まったく競合しない可能性があります。この作業パターンにより、あなたが話しているような個別の機能ブランチが存在することができます。また、発生する可能性のある小さなマージ競合をチームが手動で解決する準備ができていることも前提としていますが、もう一度強調しますが、マージ競合の解決は、snv のような CSV よりも git と意図されたワークフローの一部の方が簡単です。
一度マージすると、バグ修正が上書きされることはありませんが、マージがスムーズに進むことは保証されません。たとえば、バグ修正の一環として関数のシグネチャを変更する必要があり、新しい UI コードがその関数を使用している場合、明らかにプロジェクトがクラッシュします。これは簡単なケースです。新しい UI をマージすると、より微妙な修正を修正するのが難しくなります。
より良いアプローチは、各バグ修正の後にマスターから (またはバグ修正ブランチから直接) 修正を新しい UI ブランチにマージすることです。そうすれば、バグ修正はまだ記憶に新しいため、新しい UI が壊れた場合でも、数か月後に UI をマージするよりもはるかに簡単に修正できます。
もう 1 つの重要な利点は、競合が新しい UI コードから解決できない\べきではないことが判明した場合、新しい UI で動作させるためにバグ修正自体を修正する必要がある場合、次のことができることです。新しいコードがそのバグ修正に依存する前に、すぐに（もちろん、新しいUIブランチではなく、バグ修正ブランチで！）実行してください。