異なるサーバーの異なるコードベースでGitを使用するにはどうすればよいですか？

背景：私は最近会社で一連のプロジェクトを継承しており、それらの処理方法に関するいくつかの基本的な問題を整理しようとしています。つまり、以前の開発者（もはや会社にいない）は、いかなる形式のソース管理も使用せず、ほとんどドキュメントを作成せず、実際には適切な開発プロセスもありませんでした。

そのため、私は3つのサーバーに相当するプロジェクト（開発、ステージング、プロダクション）を手に入れました。これらは、主にWebサイト、アプリケーション、および使用するサードパーティアプリケーションとAPI用に構築されたツールから成り立っています。私が最初に考えたのは、変更と修正が行われる前にこれらすべてをGitに取り込むことでしたが、それを行う最善の方法を見つけるのは困難です。

これまでの多くの開発は、運用サーバーで直接行われたため、各サーバーのコードベースに格差が生じました。すべての違いがどこにあるのかすぐにはわかりません-開発/ステージングに引き継がれないバグ修正と、ステージング/プロダクションに移行していない開発の新機能が見られます。

質問：これらを整理してGitに移動する最良の方法は何でしょうか？コードの違いに対応するためにレポジトリ/ブランチをどのように構成しますか？

実稼働サーバーコードのクローンから開発を継続し、開発/ステージングコードベースを履歴参照として保持することを検討しました。とにかく開発/ステージングコードについて何も知らないことを考えると、これは潜在的に最初のポイントになるでしょうか？各Webサイト、ツール、スクリプトセットなどの本番サーバーのリポジトリを作成し、既存の開発/ステージングコードのブランチを作成するだけで、新しい開発は本番サーバーのコードベースから分岐します。これは理にかなっていますか？

運用スタッフをmaster新しいリポジトリのブランチにプッシュします。developそれからブランチを作成し、ステージングサーバーをマージします。解決する必要がある競合が発生する可能性があります。これらが解決されたら、別のものを作成するfeature_branchからdevelop、そこに開発サーバーを統合。発生する競合を解決します。

これにより、実稼働環境、ステージング環境、および開発環境を表す3つのブランチが残ります。生産-> master、ステージング-> develop、開発-> feature_branch。したがって、すべての開発は、機能が実行され、テストされ、安定したときにfeature_branchesのみdevelopブランチで行われ、ブランチにマージされます。安定しているため、ステージングとして使用できます。リリースの準備ができたらreleaseブランチを切り、developゆるい端を結び付けて、それをmasterにマージすると、新しいプロダクションビルドができます。

このセットを取得した後、ビジネスのあなたの最初の注文の一つは、マージするべきであるfeature_branchに背中をdevelop、その後*、およびdevelop背面にmaster。ことを念頭に置いてクマfeature_branchにそれをマージする際に未テストコードと機能、運動注意してが含まれていてもよいdevelop、その後とmaster。それが完了すると、すべてのブランチに同じコードが含まれるようになり、本番サーバーで行われた開発はすべて開発「サーバー」に移植されます。

このモデルでは、各プロジェクトは独自のリポジトリにあり、そのリポジトリにはmasterand developブランチがあり、加えfeature_branchesて実行中の作業があります。

編集、コメントに対処する：はい、これはGitflowです。

この戦略（または一般的なGitflow）は、既存の3レベルシステム（本番、ステージング、開発）を、開発から本番までの明確なマージパスに保ちます。この方法でコードベースをインポートすると、本番環境で現状を維持しながら、少なくともマージをテストできるまで、ブランチを同期できます。これにより、いくつかの目標が達成されます。ソース管理でコードを取得し、さまざまなコードベースを同期してマージします（したがって、本番ではバグ修正がなくなり、開発ではなくなります）。そして、多くの人々/チーム/会社によって使用されます）。OPが、Gitflowが彼のプロジェクト/チーム/会社の使用/会社の成長に適していないと判断した場合、

*あなたは、他の機能ブランチをカットし、任意の明白な新機能を削除し、マージすることを望むかもしれないことに支店をdevelop（し、その後にmaster）。これにより、これから行う他のすべてのテストの上に新しい機能をテストする必要がなくなります。

staging最初のインポートの最適なベースラインとしてコードを推奨します。これproductionはstaging、ホットフィックスにより変更が反映されていないためですが、変更が反映されていない場合ははるかに少ないstagingためですproduction。同様に変更があるdevelopmentではないというstagingの変更ならば、新機能のために、しかし、おそらくはるかに少ないがstagingでませんdevelopment。

最初のインポート後にベースラインになりたくないことに注意してくださいstaging。これは、変更が以前に追跡されていないための一時的な状況です。変更を削除するのではなく追加する場合、ブランチ操作はよりスムーズに進みます。最初のインポート後、ニーズに最も適した分岐モデルに切り替えてください。

したがって、stagingコードをstagingブランチにチェックインしてから、を実行してブランチgit checkout -b master stagingを作成し、masterそこに実動コードをチェックインします。次に、git checkout -b development stagingを実行してdevelopmentブランチを作成し、そこに開発コードをチェックインします。

developmentブランチをチェックアウトして、そこにマージmaster します。これmasterにより、実際に本番環境にあるものの記録として維持しながら、可能性のある膨大な量のマージ競合を解決できます。 development現在、すべての環境からのすべての変更が含まれています。これで、最適な分岐モデルに切り替えることができます。

歴史を持つことは良い考えです。最も安定した環境からリポジトリ（または製品ごとに1つ）を作成します。他のブランチまたはブランチを作成します。

高レベル：

1. 新しいレポを作成する
2. 本番ベースの作業コピーから：すべて追加、コミット、プッシュ
3. マスターを新しいディレクトリにチェックアウトする
4. 追加の環境ごとに XYZ
   1. ブランチを作成 Archive-XYZ
   2. すべてをXYZソースに置き換えます（.gitを除く）
   3. すべて追加、コミット、プッシュ

また、git diff > XYZ.diff実際にコミットしてプッシュする代わりに、この値に懐疑的である場合は、差分をアーカイブします。

どちらの場合でも、各環境で実行しているコードを簡単に比較できる状態で終了する必要があります。この状態を使用して、各プロジェクトの単一の開始点を決定できます。そして、何かが壊れた場合、理論的には3つの環境のいずれかに対して変更を比較することができます。