我是我们网络开发公司的团队领导，我想在我们的团队中实现 Git 工作流程。阅读文档和文章后，我发现以下结构对我们很有用:
我们在 Bitbucket 中有一个存储库。 Master 分支被认为只包含稳定的代码。每个开发人员都必须创建自己的分支并在他的自己的 分支中实现功能/错误修复。一旦他决定，他的代码已经准备好了，他就会创建一个很好的分支历史记录(使用 rebase、amend、cherry-pick 等)并将其推送到 Bitbucket，在 Bitbucket 中创建一个对 master 分支的 pull 请求。 QA 验证功能并批准(或不批准)它，然后我验证代码，如果没问题，我将他的工作 merge 到 master 中(通过快进或 rebase 以获得更好的提交历史)。
但是这种方案只适用于单个开发人员在一个分支上工作的情况。在我们的案例中，我们几乎总是有两个开发人员负责一个分支，因为一个开发人员在服务器端 (PHP) 工作，而另一个 - 客户端 (HTML/CSS/JS)。这两者应该如何以某种方式协作，使 master 中的提交历史保持干净？
Server dev创建HTML文件的基本结构，client dev需要获取这个结构。从逻辑上讲，服务器开发人员将创建一个分支，而客户端开发人员将基于服务器开发分支创建自己的分支。但这意味着，服务器开发人员需要在 Bitbucket 中发布他的分支，这将使他不可能对已经发布的提交进行 rebase 或更改。
另一种选择是等待，直到服务器开发人员完成他的工作，发布具有良好提交历史的分支并忘记它，并且只有在客户端开发人员开始在该分支中工作之后，但这会导致时间延迟，甚至更糟。
您如何处理工作流程中的此类协作？
最佳答案
我无法真正说明您帖子中描述的方法的优点，但我可以描述我们如何解决工作流程中的协作编码问题。
我们使用的工作流程是众多分支之一。因此我们的结构是:
师父是金；只有 merge 大师会接触它(稍后会详细介绍)。
有一个 dev 分支，最初来自 master，所有开发人员都在该分支上工作。我们没有为每个开发人员创建一个分支，而是从开发人员创建功能或票证分支。
对于每个谨慎的功能(错误、增强等)，都会从 dev 中创建一个新的本地分支。开发人员不必在同一个分支上工作，因为每个功能分支的范围仅限于单个开发人员正在处理的内容。这就是 git 的廉价分支派上用场的地方。
功能准备就绪后，它会在本地 merge 回开发人员并推送到云端(Bitbucket、Github 等)。每个人都通过经常 pull 开发人员来保持同步。
我们采用每周发布计划，因此每周，在 QA 批准开发分支后，都会创建一个发布分支，名称中包含日期。这是用于生产的分支，取代了上周的发布分支。
一旦发布分支在生产中通过 QA 验证，发布分支将 merge 回 master(和 dev，只是为了安全)。这是我们唯一一次接触 master，确保它尽可能干净。
这对我们 12 人的团队来说效果很好。希望它有所帮助。祝你好运!
关于git - 多个开发人员处理同一任务的正确 git 工作流方案，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14865283/