私たちのプロジェクトでは、アップストリーム ソフトウェア (U-Boot) の上に機能を実装しています。1 年または 2 年に 1 回、新しいハードウェアの開発が開始され、アップストリーム ソフトウェアの新しいバージョンがベースとなります。以前に実装された機能の一部は、ほとんど変更せずに、ほとんどそのままで新しいプロジェクトに適しています。
したがって、特定の機能の範囲内で行われた作業を追跡して再利用できるワークフローが必要です。コード ベース全体から削り取る必要はありません。頻繁に必要とされるわけではないので、完璧であってはなりませんが、苦痛であってはなりません。
主な問題は、最初の実装から数週間/数か月後に機能が修正/調整される場合があり、これが数回繰り返される場合があるため、バニラの「機能ブランチ ワークフロー」がそのまま機能しないことです。
チームとコード ベースはどちらも比較的小規模です (それぞれ最大 5 人、アップストリーム コードの上に最大 15 の LoC)。通常、一度に特定の機能に取り組むのは 1 人だけです。
ここでは、考えつくことができた 2 つのオプションを示します。複雑さの唯一の原因であるため、上記の問題のあるシナリオの処理についてのみ説明します。
方法 A
初期状態: 機能の最初/前のバージョンはブランチ X にあり、最後に変更されたのは数か月前であり、マスターにマージされています
git checkout X; git merge --no-ff master- 変更を加えてコミットする
git checkout master; git pull; git merge --no-ff X; git push
次にgit log --first-parent --no-merges、このブランチで最初から行われたコミットのリストを表示します。
このアプローチの主な問題は、脆弱で制限があることです。
- 誰かがステップ 1 で早送りを使用してマージした場合、履歴を取得するための上記の方法はその後機能しません。AFAIK --no-ff はリポジトリレベルで強制できますが、誰もがそれを行う必要があり、忘れないでください。
- ステップ 3 の rebase-and-then-merge も歴史を壊すものであり、多くの人がこのアプローチとリベース全般を好んでいます。リベースを完全に禁止する方がおそらく安全ですが、強制する方法がわかりません。
方法 B
誰かが機能 X の作業に戻るたびに、新しい X_fix_this、X_change_that などを作成します。
欠点: 見苦しく乱雑なブランチ リスト、これからコミットのリストを作成するために必要なスクリプト。
現在、パッチのセットをキルトに保管しています。これは上記の問題を完全に解決しますが、他の点では非常に醜いです。
（より良い）アイデアはありますか？