Successful Git branchで導入されたワークフローを使用しています。開発ブランチでの構成など、変更を管理する方法について混乱しています。
マスターからマージするとき、作業ツリーをきれいに保つために、変更を隠します。変更をコミットした場合、master をマージする際には細心の注意を払う必要があります。
では、git でプライベートな変更を管理するためのより良い方法はありますか?
Successful Git branchで導入されたワークフローを使用しています。開発ブランチでの構成など、変更を管理する方法について混乱しています。
マスターからマージするとき、作業ツリーをきれいに保つために、変更を隠します。変更をコミットした場合、master をマージする際には細心の注意を払う必要があります。
では、git でプライベートな変更を管理するためのより良い方法はありますか?
いくつかのオプションがあります:
プライベート ファイルをソース管理下に置かないでください。たとえば、config.ini
開発者ごとに非公開の変更が必要な場合config.ini.template
は、リポジトリにサンプル設定を含むファイルを作成し、各開発者はそのコピーを作成して、そのコピーを非公開設定で修正する必要があります。config.ini
を に追加する必要があります.gitignore
。
リポジトリに を追加してconfig.ini
使用git update-index --assume-unchanged config.ini
し、git がファイルのローカル変更を無視してファイルをコミットしようとしないようにします。
、などconfig-robotment.ini
、各環境のリポジトリにいくつかの構成ファイルを追加します。次に、コマンド ライン パラメータや環境変数などを使用して、アプリケーションが使用するファイルを選択できるようにします。config-kan.ini
config-produciton.ini
ポイントは、構成にブランチを使用しないことです。そうしないと、開発中にブランチ/マージするのが常に苦痛になります。
構成ファイルについては、「 Git: 特定のファイルをマージしないでください」で選択肢が再開されます。
環境ごとに (ここではブランチごとに) 異なる値ファイルをバージョン管理することを好みます。そうすれば、マージを処理する必要がなくなります (値ファイル " dev.config
" は、値ファイル " " が使用されるマスター ブランチでは決して変更されませんmaster.config
)。
また、ブランチのチェックアウト時にコンテンツフィルター ドライバーが実際の構成ファイル (非公開のままでバージョンではない) を生成するために、テンプレート ファイルのバージョンも管理します。
別の名前のローカル ブランチを作成して切り替え、必要に応じて上流のマスター ブランチをマージします。