プロジェクト (PHP アプリケーション) がありますが、各クライアントのインストールはさまざまで、ほとんどない場合もあれば、それ以上の場合もあります。それでも、ソース コードの大部分は共通です。特定のインストールをマスター ブランチへの並列ブランチとして管理し、変更をマスターから他のブランチに転送する必要があります。Gitで同じ状況が解決されました: わずかな違いで (ほとんど) 並列ブランチを維持するにはどうすればよいですか? 最も投票された解決策は、次の方法でブランチ間で変更を転送することでした。
git pull
git checkout local
git rebase master
ソリューションで述べたように、リベース後に非早送りプッシュが作成されますが、これは非常に不快な複雑さです。私の質問は-代わりにやらない理由：
git pull
git checkout local
git merge master
それは、ブランチで何をしたいかによって異なります。はい、ローカルをリベースすると、リベース後に非早送りプッシュが作成されます。一方で、今後も個別の変更のセットを維持することになり、ブランチにあるものは、マスターの最新のヘッドに対して行われたかのように一連の変更になります。
代わりに、マスターをローカルにマージすると、ローカルはマスターに合わせて前進し続け、発生した履歴が記録されます。過去のローカルの状態を再構築できるようにする必要がある場合は、これを行う必要があります。歴史は変わることはありません。ただし、より複雑な履歴を処理する必要があります。
あなたの他の質問に対するグレッグの答えは、さまざまなブランチを特定のインストールに対してローカルのままであり、他のリポジトリにプッシュされていないと見なしているようです(強調を追加):
システムに対してローカルである場合は、そのシステムの「ローカル」ブランチにコミットします。それ以外の場合は、「マスター」にコミットして共通リポジトリにプッシュします。
ほとんどの場合、共有リポジトリ内のブランチへの早送りプッシュが必要になります。git rebaseドキュメンテーションは、アップストリームのリベース (つまり、git rebaseその後) から回復する方法を説明していますがgit push -f、関係者にとって楽しいものではありません。
別のアプローチについては、決してマージバックしないを参照してください。
決してマージバックしないという意図で一度フォークした有効なケースがありますが、一般的には、そのようなフォークでの変更を最小限に抑えるように非常に努力する必要があります。
著者は、同じリポジトリ内のさまざまなカスタマー リリースの分岐ポリシーについて説明します。