如何开始将Git用于来自不同服务器的不同代码库？

背景：最近，我在公司继承了一组项目，并且我试图解决一些基本问题，如如何处理。就是说，以前的开发人员（不再在公司工作）没有使用任何形式的源代码控制，只编写了很少的文档，并且实际上并没有任何好的开发过程。

因此，现在我有了三台服务器，这些项目的价值（开发，暂存，生产）由大多数网站和应用程序以及为我们使用的第三方应用程序和API构建的工具组成，直至存储SQL脚本和其他内容。我的第一个想法是在进行更改和修复之前将所有这些信息都放入Git，但是我很难确定最好的方法。

先前的许多开发都是直接在生产服务器上完成的，这在每个服务器的代码库之间造成了鸿沟。目前尚不清楚所有差异在何处-我看到生产方面的错误修复未保留在开发/阶段中，还有开发中尚未转移到阶段/生产中的新功能。

问题：对我来说，组织这些活动并将其移至Git的最佳方法是什么？我将如何构造我的存储库/分支以适应代码中的差异？

我考虑过从生产服务器代码的克隆中继续进行开发，并将开发/登台代码库保留为历史参考。考虑到我对开发/暂存代码一无所知，这可能是一个起点吗？我可以简单地为每个网站，工具，脚本集等创建生产服务器的存储库，为现有的dev / staging代码创建分支，任何新的开发都将从生产服务器的代码库中分支。这有意义吗？

将生产资料推送到master新仓库的分支中。develop从中创建一个分支，然后将登台服务器合并到其中。您可能会遇到需要解决的冲突。解决这些问题后，feature_branch从中创建另一个develop并将开发服务器合并到其中。解决出现的任何冲突。

剩下三个分支，分别代表您的生产，登台和开发环境。生产-> master阶段-> develop开发-> feature_branch。因此，所有开发都在该功能上完成，feature_branches并且仅在develop功能完成，测试并稳定后才合并到分支中。由于它是稳定的，因此可以用作登台。准备发布时，release从其分支中剪切develop出来，绑上任何松散的末端，将其合并到中master，然后您便有了新的生产版本。

进行此设置后，您的首要任务之一就是将feature_branchback 合并为develop*，然后合并develop为master。请记住，feature_branch可能包含未经测试的代码和功能，因此将其合并到developthen中时要格外小心master。一旦完成，所有分支应该包含相同的代码，并且在生产服务器上进行的任何开发现在都将被移植回开发“服务器”。

在此模型中，每个项目都将位于其自己的存储库中，该存储库将具有masterand develop分支，以及feature_branches正在进行的任何工作。

编辑，以解决评论：是的，这是Gitflow。

这种策略（或一般来说称为Gitflow）使现有的3级系统（生产，暂存，开发）保持从开发到生产的清晰合并路径。通过这种方式导入代码库还可以同步分支，同时保持生产中的现状-至少直到可以测试合并为止。这实现了一些目标：在源代码管理中获取代码，同步并合并不同的代码库（因此，生产中不再存在错误修正，而开发中不再存在错误修正），并提供了一个很好的流程来使用（定义明确的流程）并被很多人/团队/公司使用）。如果OP发现Gitflow在他使用/公司成长时不太适合他的项目/团队/公司，那么它就可以了。

*您可能希望削减另一个特性分支，并删除任何明显的新功能，并合并该分支进入develop（再进入master）。这使您不必在要进行的所有其他测试之上测试新功能。

我将推荐staging代码作为您初始导入的最佳基准。那是因为有变化production不在staging，由于热修复，但要少得多，如果在任何改变staging不在production。同样也有在变化development未在staging，由于新功能，但可能会少得多，如果在任何改变staging不在development。

请注意，你不希望staging成为你的基线您最初的导入后。由于先前未跟踪更改，因此这只是暂时情况。如果要添加更改而不是删除更改，则分支操作会更加顺利。首次导入后，最好继续切换到适合您需求的任何分支模型。

因此，将您的staging代码检查到一个staging分支中，然后执行a git checkout -b master staging创建您的master分支，并将生产代码检查到其中。然后执行git checkout -b development staging创建development分支，并在其中检查开发代码。

现在，签出您的development分支并合并master 到其中。这将使您解决可能的大量合并冲突，同时仍保留master实际生产中的记录。 development现在包含来自每个环境的所有更改。现在，您可以切换到最适合您的任何分支模型。

拥有历史是一个好主意。我将在最稳定的环境中创建存储库（或为每个产品创建一个存储库）。为其他人创建分支或差异。

高层次：

1. 创建一个新的仓库
2. 从基于生产的工作副本中：添加全部，提交和推送
3. 结帐母版到新目录
4. 对于每个其他环境 XYZ
   1. 创建分支 Archive-XYZ
   2. 将所有内容替换为XYZ源（.git除外）
   3. 全部添加，提交和推送

或者，如果您对此表示怀疑，则git diff > XYZ.diff不要实际提交和推送并归档差异文件。

无论哪种方式，您都应该以可以轻松比较在每个环境中运行的代码的状态结束，可以将其用于确定每个项目的单个起点。而且，如果出现问题，理论上您将可以将更改与这三种环境中的任何一种进行比较。