異なるサーバーの異なるコードベースに対してGitの使用を開始するにはどうすればよいですか？
背景：私は最近、私の会社で一連のプロジェクトを継承しました。それらの処理方法に関するいくつかの基本的な問題を整理しようとしています。つまり、以前の開発者（現在は会社にいない）は、どのような形式のソース管理も使用しておらず、ドキュメントをほとんど作成しておらず、実際に適切な開発プロセスがありませんでした。
そのため、3つのサーバーに相当するプロジェクト（開発、ステージング、本番）を手に入れました。これらのプロジェクトは、ほとんどがWebサイト、アプリケーション、およびSQLスクリプトなどのストアに至るまで、使用するサードパーティのアプリケーションとAPI用に構築されたツールで構成されています。私の最初の考えは、変更と修正が行われる前に、これらすべてをGitに取り込むことでしたが、それを行うための最良の方法を理解するのに苦労しています。
以前の開発の多くは本番サーバーで直接行われており、各サーバーのコードベース間で分割が生じています。すべての違いがどこにあるのかすぐにはわかりません-開発/ステージングに引き継がれないプロダクション側のバグ修正、およびステージング/プロダクションに移行していない開発の新機能が表示されます。
質問：これらを整理してGitに移動するための最良の方法は何ですか？コードの違いに対応するためにリポジトリ/ブランチをどのように構成しますか？
本番サーバーコードのクローンからの開発を継続し、開発/ステージングコードベースを履歴参照として保持することを検討しました。とにかく開発/ステージングコードについて何も知らないので、これは潜在的に最初のポイントでしょうか？各Webサイト、ツール、スクリプトセットなどの本番サーバーのリポジトリを作成し、既存の開発/ステージングコードのブランチを作成するだけで、新しい開発は本番サーバーのコードベースからブランチできます。これは理にかなっていますか？
本番のものを新しいリポジトリのmasterブランチにプッシュします。そこからdevelopブランチを作成し、そこにステージングサーバーをマージします。解決する必要がある競合が発生する可能性があります。それらが解決されたら、developから別のfeature_branchを作成し、開発サーバーをマージします。発生する競合を解決します。
これにより、本番環境、ステージング環境、および開発環境を表す3つのブランチが残ります。本番環境-> master、ステージング-> develop、開発-> feature_branch。したがって、すべての開発はfeature_branchesで行われ、機能が完了し、テストされ、安定したときにのみ、developブランチにマージされます。安定しているため、病期分類として使用できます。リリースの準備ができたらreleaseからdevelopブランチを切り、自由端を結び、それをmasterにマージすると、新しい製品ビルドができます。
この設定を行った後の最初の注文の1つは、feature_branchをdevelop *にマージし、次にdevelopをmasterにマージすることです。 feature_branchにはテストされていないコードと機能が含まれている可能性があるので、それをdevelopにマージしてからmasterにマージするときは注意してください。これが完了すると、すべてのブランチに同じコードが含まれるようになり、本番サーバーで行われた開発はすべて開発「サーバー」に移植されます。
このモデルでは、各プロジェクトは独自のリポジトリにあり、そのリポジトリにはmasterおよびdevelopブランチがあり、実行中の作業にはfeature_branchesがあります。
編集、コメントに対処する：はい、これはGitflowです。
この戦略（または一般にGitflow）は、既存の3レベルのシステム（本番、ステージング、開発）を、開発から本番までの明確なマージパスで維持します。この方法でコードベースをインポートすると、少なくとも、マージをテストできるようになるまで、本番環境で現状を維持しながら、ブランチを同期させることができます。これにより、いくつかの目標が達成されます。コードをソース管理で取得し、さまざまなコードベースを同期してマージします（したがって、本番環境ではバグ修正が行われず、開発では行われません）。今後使用するための素晴らしいプロセス（明確に定義されたプロセス）が提供されますそして多くの人々/チーム/会社によって使用されました）。 OPがGitflowが彼のプロジェクト/チーム/会社に適していないと判断した場合（会社が成長する場合）、後で変更するのは簡単ですが、重要な点は、すべてがソース管理と開発にあるということです。右のブランチで行われます。
*別の機能ブランチを切り取って、明らかな新しい機能を削除し、thatブランチをdevelop（次にmaster）にマージすることもできます。これにより、実行する他のすべてのテストの上に新機能をテストする必要がなくなります。
最初のインポートの最良のベースラインとしてstagingコードをお勧めします。これは、ホットフィックスによりproductionにない変更がstagingにあるためです。ただし、stagingにない変更がproductionにない場合は、はるかに少なくなります。同様に、新機能により、developmentにない変更がstagingにありますが、stagingにない変更がdevelopmentにない場合、はるかに少ない可能性があります。
notを実行することに注意してください。最初のインポート後にstagingをベースラインにしたいとします。これは、以前に追跡されていない変更による一時的な状況です。 addingの場合、ブランチ操作は削除するのではなく、はるかにスムーズに進みます。最初のインポート後、今後の最適な分岐モデルに切り替えます。
したがって、stagingコードをstagingブランチにチェックインしてから、git checkout -b master stagingを使用してmasterブランチを作成し、そこに製品コードをチェックインします。次に、git checkout -b development stagingを使用してdevelopmentブランチを作成し、そこに開発コードをチェックインします。
developmentブランチをチェックして、masterintoをマージします。これにより、実際に何が実際に稼働しているかの記録としてmasterを維持しながら、起こり得る膨大な量のマージ競合を解決できます。 developmentに、すべての環境からのすべての変更が含まれるようになりました。これで、最適な分岐モデルに切り替えることができます。
歴史があるのはいい考えです。最も安定した環境からリポジトリ（または製品ごとに1つ）を作成します。他の人のためにブランチまたは差分を作成します。
高レベルで：
- 新しいレポを作成する
- 本番ベースの作業コピーから：すべて追加、コミット、プッシュ
- マスターを新しいディレクトリにチェックアウトする
- 追加の環境ごとに
XYZ- ブランチを作成
Archive-XYZ - すべてを
XYZソースに置き換えます（.gitを除く） - すべて追加、コミット、プッシュ
- ブランチを作成
または、この値に懐疑的な場合は、git diff > XYZ.diff実際にコミットしてプッシュする代わりに、差分をアーカイブします。
どちらの場合も、各環境で実行しているコードを簡単に比較できる状態で終了する必要があります。これを使用して、各プロジェクトの単一の開始点で解決できます。そして、何かが壊れた場合、理論的には3つの環境のいずれかに対する変更を比較することができます。