在快节奏的环境中从SVN切换到Git

Question

我所属的开发团队由一个快节奏的内部开发环境中的五个成员组成（我们开发基于Web的解决方案，供其他部门使用，即ERP）。我们目前将SVN用于单个项目，该项目具有开发环境和生活环境； 开发环境使我们能够确保功能在发布到实际环境之前能够正常工作。 当满足要求时，我们将更改从开发服务器提交到SVN存储库，并将这些特定更改拉到实时服务器上。

我们对开发人员进行测试，直到代码达到稳定的提交水平。

但是，我们想切换到Git（许多其他项目都放在Git上，并且我们希望它保持一致。）这是一个挑战。 我们希望拥有一个易于使用和跟踪的工作流程。 我建议为live（master）和dev创建两个主要分支，并将每个功能/修复放在自己的分支中。 这使事情更容易跟踪，但又难以放置，因为这需要花费更长的时间，并且我们对代码所做的某些更改需要尽快发布。

另一个建议是只拥有一个开发人员和一个正式分支。 我们将提交到dev分支，确保它们可以正常工作，然后对结果感到满意后，将这些文件合并为活动文件。 唯一的问题是我无法找到一种实现此行为的体面方法。 是否可以快速将特定文件从一个分支合并到另一个分支？

是否还有其他git工作流程更适合我们的环境？

Answer 1

您列出的两个建议都可以使用，但是可以通过以下工作流程改进两个工作流程：

• develop分支：所有开发人员都在该分支上工作。 当更改准备好部署到实时环境中时，开发人员可以将其更改推送到live （ master ）分支。
• 功能/修补程序分支：是开发人员在其本地存储库上的短期生存分支。 例如，如果开发人员想要开发新功能或修复错误，则可以从develop分支创建本地功能/修补程序分支。 完成工作后，将功能部件/修补程序分支合并到develop分支中。
• live / master分支：它是生产/发行版本。 在develop分支上验证代码后，然后develop分支可以合并到live / master分支中。

您列出的两个建议之间的差异：

1. 它也有两个主要分支（ develop和live / master ）作为第一个建议，但是由于live / master分支是生产/发行版本，因此它仅具有feature / hotfix分支来进行develop分支。
2. 该工作流不是直接在develop分支上进行更改。 它适用于功能部件/修补程序分支，然后将更改合并到develop分支中。