PHP プロジェクトで git を使用していますが、とても便利だと思います。私がそれを機能させれば素晴らしいことが1つあります。
展開用のブランチを作成しました。構成ファイルやドキュメントが異なるなど、いくつかの違いがあります。
それらを無視することはできません。なぜなら、それらは両方のブランチにとどまり、両方のブランチで異なるものにしたいからです。
問題は、ブランチをマージすると、異なるはずのファイルもマージされることです。
そのようなことを達成するための便利な方法はありますか? これは通常どのように行われますか？
2021 年 2 月更新: Git 自体はまだ適切ではありませんが、GitHub Action 環境が役立つ可能性があります。
2009: Git がこのように使用されることを意図しているかどうかはわかりません。
まず、Linus の簡単なアドバイスです。常に「カラフル」で有益です ;)
Gitは非常に基本的に、ファイルの状態ではなく、プロジェクトの状態を追跡します。つまり、「ファイルをマージ」しようとすることはほとんどできません。これは git では無意味な操作であり、実際、それを可能にする SCM はすべて、完全にたわごと (*) になる運命にあります。
(*) そして、git がそれをしないからといって、そう言っているわけではありません。それよりもはるかに基本的なことです。ファイルごとの分岐とマージを開始すると、基本的に自分自身を台無しにしてしまい、プロジェクトを「プロジェクト全体」として作業することはできなくなります。実際に明確に定義された履歴がなくなります。プロジェクト全体の履歴です。
そこには。
つまり、次のことができます。
このスレッドの他の解決策には、展開サーバーの「サーバー固有の」ブランチでの作業が含まれます
Development Deployment
#origin/master:
x--x $ git clone
# master
x--x
$ git checkout -b deployment origin/master
x--x
\
-- #deployment
$ .... #makes changes for config files
#or other specific deployment files
x--x
\
--d1--d2 # no need to push that branch ever.
#new developments
x--x--x--x
$ git pull --rebase #pull origin/master and
#replay current branch on top of it
x--x--x--x
\
--d1'--d2' #SHA1 rewritten in deployment branch
#not important since this branch
#is not pushed (published)
これは私にとってはうまくいき、デプロイするためにわずかな構成変更のみを行います（構成ファイルに3行）。
GitHubから、またはリポジトリを保持している場所からリポジトリのクローンを作成します。展開したい場所へ。
を実行しますgit checkout -b deployment origin/master。
変更を加えます（必要に応じてプッシュします）。
マスター（またはデプロイを行ったブランチ）にデプロイしたい変更がある場合は、単純にgit pull --rebase。
それは単純な解決策であり、確かに私にとってはうまくいきます。他の人が示唆しているように、これが「たわごと」になるかどうかはわかりませんが、私たちの目的には確かに非常に役立ちます。
私は次のような愚かなトリックを行います。
configconfig.developmentand config.productionbut notを追加configcp config.production configそれは意味がありますか？
それは私にとってはうまくいきます。
簡単な答えは、ブランチをマージしないことです。実際、それらをマージする必要はまったくありません。開発 (別名「マスター」) からデプロイメントにマージして、修正と一般的な変更をマージするだけです。
以前のパッチファイルについて説明しました。私は今これをやめ、代わりにデプロイメントブランチを維持しています。
つまり、「master-deployed」という名前の新しいブランチでマスターを分岐し、ビルドサーバーのテストバージョンにのみ存在する必要があるブランチに変更を加えます（つまり、これがライブバージョンではないという警告を追加します。およびweb.config内の別のdbサーバー）。
最先端バージョンをビルドするときのビルドサーバーは、マスターデプロイをチェックアウトし、通常のビルドを実行する前にオリジン/マスターにリベースします。競合する変更を誰も行っていない場合は、すべて問題ありません。もしそうなら、私は手動の介入なしにこれを処理するシステムを見ることができません。
ブランチ「qa-deployed」を持つqaのヒントについても同じことが言えます。
--ontoフラグを使用して、ブランチ全体が書き換えられた場合に、パッチが古いコミットをすべて取得しないようにします。
したがって、ビルドサーバーでは、qaビルドは次のようになります。
git reset --hard
git clean -xfd
git checkout -f qa-deployed
git rebase --onto qa HEAD^ qa-deployed
build-script
私は自分の状況に対してこれらすべての解決策を考えていましたが、どれも当てはまらないようです。ライブサーバーと開発サーバーの両方で編集しています。そのブランチを再公開する必要がない場合、リベースはうまく機能しますが、展開ブランチに変更を加えて、それらをメイン リポジトリに公開します。サブモジュールの方法は、ファイルが別のサブディレクトリにある場合にのみ機能し、私の構成ファイルはいくつかの場所にあります。私たちのマージ方法は、最初にそのブランチをプルしてから大きなブランチをプルする必要があるため、うまく機能しません。まだマージがあり、必要に応じて適切な構成ブランチを取り込むことができれば、おそらくうまくいくでしょう。今のところ .gitignore は機能しており、ファイルを手動でアップロードするだけです。
さらに調査を行った結果、ライブ サイトに git リポジトリを持たず、ステージング サイトを使用して、ステージング/ライブ構成ファイルを使用してブランチに最新の変更をプルするという解決策を見つけました。次に、git アーカイブでデプロイし、ファイルをライブ サイトに展開します。
チェリーピックはこれでうまくいくようです（ログを少し汚染することを犠牲にして）。
git checkout -b testing 変更を加えてコミット git checkout master git checkout -b deploy 変更を加えてコミット git checkout master
master および git cherry-pick testing または git cherry-pick deploy の下ですべてを実行して、現在のシステムからテストまたは展開バージョンに切り替えるために必要な差分を適用します。
同様の問題があり、これを管理するために config-magic という小さなプロジェクトを作成しました。
Config-magic を使用すると、テンプレート conf ファイルを作成してから、dev/staging/production ごとにデータのプロファイルを作成できます。次に、「cfg dev」を実行して「dev」構成ファイルを生成し、「cfg staging」を実行してステージング構成などを生成します。
次に、これをスクリプトと結び付けて、ステージングにデプロイするときにローカルで「cfg staging」を実行し、git からコードベースを更新した後、すべての構成ファイルに対して scp を実行します。
「実際の」構成ファイルは、git によって無視されるように設定されています。これまでのところ、これは私にとって非常にうまく機能しています。
現在、いくつかのパッチ ファイルがチェックインされており、ビルド サーバーはそれらのパッチを関連するバージョンに適用します。私は今それについて考え直していますが