さまざまな分岐戦略について説明しているgitに関するこのブログ投稿を読んでいました。この記事では、長期間有効な機能ブランチの場合、機能ブランチをマスターにマージして、機能ブランチをマスターと同期させて、機能ブランチがマスターにマージされても問題が発生しないようにすることをお勧めします。この戦略は私には明らかです。コメントで濱野純雄はgitmainterが言っています。
「分岐して同期することが多い」というのは避けるべき病気であることに注意する必要があります。特定の目標を達成するために分岐しました（たとえば、「この機能を追加する」、「このバグを修正する」）。そのタスク専用の分岐を持つことのポイントは、その 特定の分岐の履歴を読みやすく理解しやすくすることです。バグ。ブランチでの作業がまだ準備できていない時点で「マスター」からランダムにマージバックすると、別のブランチを使用するポイントが無効になります。「マスター」で行われたことは、追加の特定の目標に影響しません。機能またはバグの修正。
病気を回避するための標準的な推奨事項は、以前にフォークされたブランチで行っている時間のかかる作業が、他の人が行ったランダムな作業でもうまく機能することを確認しながら、使い捨ての「テスト」を行うことです。コードベースドリフトをチェックするためにトピックブランチとマスターブランチからマージするブランチ。
私の質問は、使い捨てテストブランチ戦略はどのように機能しますか、それはマスターとの最終的な統合をどのように容易にしますか？誰かがより詳細な例/より理解しやすい説明を提供できますか？