考えられる解決策は、ワークフローによって異なります。
オプション 1: 履歴の書き換えブランチをリモート リポジトリにプッシュしない
場合は、 masterブランチが file の共通の開始点であるため、バグ修正をmasterブランチにコミットできます。その直後に、各ブランチをリベースしてこの変更を含めることができます。a.java
オプション 1a: トピック ブランチの履歴のみを書き換える
もう 1 つのワークフローは、規則に基づいています。マスターブランチをプッシュするときに、サーバーにプッシュされるトピック ブランチを持つことができます。規則では、これらのトピック ブランチはマスターにマージされず、履歴の書き換えが許可されます。トピック ブランチは、1 人の開発者に対して非公開にすることも、他の開発者の間で共有することもできます。後者のシナリオでは、グループはリベースが発生する前後に調整する必要があります。トピック ブランチの作業が完了すると、ブランチはマスターに対してリベースされ、早送りブランチを簡単に適用できます。
オプション 2: チェリー ピック
ブランチをリモート リポジトリにプッシュする場合、履歴を書き換えることはお勧めしません。要するに、唯一の選択肢は、各ブランチの上にバグ修正をコミットすることです。同じ仕事を 2 回行うのを避けるためにgit cherry-pick
、推奨されるコマンドです (Adam と Albert によって既に伝えられています)。
オプション 3: master を各トピック ブランチにマージする
これは Adam の回答の git 部分です。影響を受けるファイルの共通の開始点であるmasterブランチでバグ修正をコミットできます。その後、マスターをトピック ブランチに再びマージできます。これは事実上、その間にマスターブランチで発生したすべての変更でトピック ブランチを更新することと同じです。この欠点は、バグ修正のみを選択できないことです。これがgit cherry-pick
可能です (オプション 2 を参照)。
注: 2 つのブランチをマージする予定がない
場合は、実際には、各ブランチの特定の構成に同じファイルを使用できます。database-1.xml
プロジェクトのセットアップ
git を使用するさまざまな方法に加えて、プロジェクトのセットアップを再考し、さまざまな環境を指定できる構成ファイルを作成する必要があるという点で、Adam の回答に完全に同意します。ご存じのように、RubyOnRails プロジェクトのデータベース構成ファイルが良い例です。
// Rails project: config/database.yml
development:
adapter: sqlite3
database: db/development.sqlite3
pool: 5
timeout: 5000
test:
adapter: sqlite3
database: db/test.sqlite3
pool: 5
timeout: 5000
production:
adapter: mysql2
encoding: utf8
reconnect: false
database: myapp_production
pool: 5
username: username
password: password
socket: /var/run/mysqld/mysqld.sock