源代码发生重大变化，用 git 分支或分叉来处理？
Big changes on source code, handle this with git branching or forking?
我有一个关于 git 和 git-flow 的问题。
我正在从事一个更大的软件开发项目，我正在使用 git（使用 git-flow）进行版本控制。一切正常...
但是，在下个月我们必须处理更大的迁移到另一个应用程序服务器，因此我们必须在我们的源代码中做 很多 应用程序服务器特定的更改.
迁移过程将花费更长的时间，因此我需要有可能维护（修补程序，...）两个应用程序服务器的源代码。
示例（日常业务）：
- 今天：返工有关新服务器的源代码
- 明天：当前服务器的修补程序
- 一天后：当前服务器的小功能请求
- 等等...
现在，我不知道处理这个问题的最佳策略是什么？ 分支或分叉或其他？
我会创建一个新分支，仍然使用 "old" 分支作为您的主要 "to be released" 分支（直到最新的工作完成）。
对于那些需要保持独立的更改，我会对新分支进行新的更改，但如果我需要进行任何修补程序，我会修复主分支，然后 cherry-pick 将这些更改添加到新分支分支.
新分支完成后，我将合并回主分支并从那里继续。
抱歉，如果这太含糊，我没有你项目的全貌。
分叉会产生一个新的存储库，我认为您不想在这里做。
如果您打算继续使用 gitflow，那么您将需要遵循创建修补程序的过程。
https://danielkummer.github.io/git-flow-cheatsheet/#hotfixes
如果您要继续对当前服务器提出功能请求，您可能会发现为新服务器使用单独的分支可能会更好。只需确保它与您对当前服务器所做的更改保持同步即可。
Git-flow 和多个并行版本
经过进一步调查，我找到了使用 git-flow 和多个并行版本的完美解决方案（感谢作者）：
If you want to fix bugs for older releases or do any other develop
there, you will fork a support branch from the appropriate commit in
master (you will have all versions ever created there)...
Git-flow and master with multiple parallel release-branches
其他一些有用的链接：
Following git-flow how should you handle a hotfix of an earlier release?
https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
这是我未来情景的一个例子：
我的 git-flow 存储库状态：
develop（新应用程序服务器正在进行中）master（最后一个稳定版本）v3.0.0（旧生产服务器的最终版本）
如果报告旧生产服务器中的错误，我必须执行以下操作：
使用此 git 命令将 hotfix 添加到早期版本：
git flow support start 3.x 3.0
git flow hotfix start 3.0.1 support/3.x
现在进行更改，然后完成：
git flow hotfix finish 3.0.1
If it is necessary to port a hotfix to your main development line
(represented by master and develop), just start a hotfix,
cherry-pick your changes and finish the hotfix.
就是这样...:)
感谢所有提到的贡献者。
我有一个关于 git 和 git-flow 的问题。
我正在从事一个更大的软件开发项目，我正在使用 git（使用 git-flow）进行版本控制。一切正常...
但是，在下个月我们必须处理更大的迁移到另一个应用程序服务器，因此我们必须在我们的源代码中做 很多 应用程序服务器特定的更改.
迁移过程将花费更长的时间，因此我需要有可能维护（修补程序，...）两个应用程序服务器的源代码。
示例（日常业务）：
- 今天：返工有关新服务器的源代码
- 明天：当前服务器的修补程序
- 一天后：当前服务器的小功能请求
- 等等...
现在，我不知道处理这个问题的最佳策略是什么？ 分支或分叉或其他？
我会创建一个新分支，仍然使用 "old" 分支作为您的主要 "to be released" 分支（直到最新的工作完成）。
对于那些需要保持独立的更改，我会对新分支进行新的更改，但如果我需要进行任何修补程序，我会修复主分支，然后 cherry-pick 将这些更改添加到新分支分支.
新分支完成后，我将合并回主分支并从那里继续。
抱歉，如果这太含糊，我没有你项目的全貌。
分叉会产生一个新的存储库，我认为您不想在这里做。
如果您打算继续使用 gitflow，那么您将需要遵循创建修补程序的过程。 https://danielkummer.github.io/git-flow-cheatsheet/#hotfixes
如果您要继续对当前服务器提出功能请求，您可能会发现为新服务器使用单独的分支可能会更好。只需确保它与您对当前服务器所做的更改保持同步即可。
Git-flow 和多个并行版本
经过进一步调查，我找到了使用 git-flow 和多个并行版本的完美解决方案（感谢作者）：
If you want to fix bugs for older releases or do any other develop there, you will fork a support branch from the appropriate commit in master (you will have all versions ever created there)...
Git-flow and master with multiple parallel release-branches
其他一些有用的链接：
Following git-flow how should you handle a hotfix of an earlier release?
https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J
这是我未来情景的一个例子：
我的 git-flow 存储库状态：
develop（新应用程序服务器正在进行中）master（最后一个稳定版本）v3.0.0（旧生产服务器的最终版本）
如果报告旧生产服务器中的错误，我必须执行以下操作：
使用此 git 命令将 hotfix 添加到早期版本：
git flow support start 3.x 3.0
git flow hotfix start 3.0.1 support/3.x
现在进行更改，然后完成：
git flow hotfix finish 3.0.1
If it is necessary to port a hotfix to your main development line (represented by
masteranddevelop), just start a hotfix, cherry-pick your changes and finish the hotfix.
就是这样...:)
感谢所有提到的贡献者。