多个开发人员处理同一任务的正确git工作流方案

我是我们web开发公司的团队负责人，我想在我们的团队中实现Git工作流。阅读文档和文章后，我发现以下结构对我们有好处：

我们在Bitbucket中有一个存储库Master分支被认为只包含稳定代码。每个开发人员都必须创建自己的分支，并在自己的分支中实现特性/错误修复。一旦他确定他的代码准备好了，他就会创建一个很好的分支历史记录（使用rebase、amend、cherry pick等），并将其推送到Bitbucket，在那里创建一个到主分支的pull请求。QA验证功能并批准（或不批准），然后我验证代码，如果可以，我将他的工作合并到master中（通过快进或重定基来更好地提交历史记录）

但只有在单个开发人员在分支上工作的情况下，此方案才是好的。在我们的例子中，一个分支几乎总是有两个开发人员，因为一个开发人员在服务器端（PHP）工作，另一个开发人员在客户端（HTML/CSS/JS）工作。这两个人应该如何合作，在《大师》中交代历史，保持清白

---

服务器开发人员创建HTML文件的基本结构，而客户端开发人员需要获得此结构。从逻辑上讲，服务器开发人员可以创建一个分支，客户端开发人员可以基于服务器开发人员分支创建自己的分支。但这意味着，服务器开发人员需要在Bitbucket中发布他的分支，这将使他无法重新设置已发布的提交的基础或更改提交

另一种选择是等待，直到服务器开发人员完成他的工作，发布具有尼斯提交历史记录的分支并忘记它，并且只有在客户端开发人员开始在该分支中工作之后，但这将导致时间延迟，更糟糕的是

您如何在您的工作流中处理此类协作

---

这将使他无法重新设定或更改承诺，即 已经出版了

这取决于你的听众。“服务器开发人员”可以将“基本结构”推送到Bitbucket，以便“客户端开发人员”可以访问它是这可能意味着其他人将有权访问这些“临时”提交

但是，只有在这些提交重新设置基础之前，另一个用户从其中一个提交分支时，这才是一个问题。在一个较小的项目/较小的用户群上，这些临时提交可能在重基发生之前就永远不会被注意到，因此消除了风险

如果有人从这些临时提交中分支的风险太大，则由您决定。如果是这样，那么您可能需要为这些私有更改创建第二个私有Bitbucket回购。另一个选择是这样做

---

不是重定基址，但这也不理想。

我不能真正说明你文章中描述的方法的优点，但我可以描述我们如何解决工作流程中的协作编码问题

我们使用的工作流是许多分支之一。因此，我们的结构是：

主人是金的；只有合并母版才会接触到它（稍后将对此进行详细介绍）

有一个开发分支，最初来自master，所有开发人员都可以使用它。我们没有为每个开发人员提供分支，而是从开发人员创建特性或票据分支

对于每个谨慎的特性（bug、增强等），开发人员会创建一个新的本地分支。开发人员不必在同一个分支上工作，因为每个特性分支的范围仅限于单个开发人员正在处理的内容。这就是git廉价的分支派上用场的地方

一旦该功能准备就绪，它就会在本地合并回dev并推送到云端（Bitbucket、Github等）。每个人都通过经常拉dev来保持同步

我们有一个每周发布的时间表，所以在QA批准开发分支后，每周都会在名称中添加发布分支的日期。这是生产中使用的分支，取代了上周发布的分支

一旦发布分支在生产中被QA验证，发布分支将被合并回master（和dev，为了安全起见）。这是我们唯一一次触摸master，确保它尽可能干净

这对我们12人的团队来说非常有效。希望这会有所帮助。祝你好运

您可能会发现这可能会对您有所帮助

---

我认为仍然没有人真正回答了如何在主题分支中协作以保持干净历史的原始问题

正确的答案是抱歉，你不能把这些都放在一起。你只能整理你的私人地方历史，在你为别人发表一些东西之后，你应该在上面工作

---

在服务器开发人员不关心客户机开发人员更改的特定情况下，您所能做的最好的事情是在本地从开发人员/功能人员分支出客户机分支，并在完成功能之前在服务器工作之上重新设置该部分的基础-或者像您所做的那样，放松约束并切换到不同的工作流；）

让我告诉你，当多个开发人员在同一个项目上工作时（甚至有时在同一个控制器/模型/视图上工作），我们在这里做什么

首先，我们的团队负责人创建了带有两个分支的git项目

大师（它是受保护的，除了队长外，任何人都不能推到这里）

开发（所有开发人员都可以在此推送）

他们告诉我们在本地环境中工作，并在我们完成一项指定任务时创建提交

现在在晚上（或者说关门时间-离开），我们会这样做：

吉特拉力

每个在同一个项目上工作的开发人员都会将当前的开发分支拉到他们的本地（早上做同样的事情——当一天开始的时候）

然后，团队负责人告诉开发人员提交所有代码，然后一个接一个地推送，然后再拉

例如

• dev1创建提交并推送到服务器
• dev2再次拉入并创建提交和推送
• dev3再次拉取并创建提交和

  <<< HEAD
  New lines from server that you don't have is here shown
  =====
  Your current changes....
  >>> [commit id]
  

   New lines from server that you don't have is here shown
   Your current changes
  

  git co master
  git co -b feature-splash
  git push origin feature-splash
  

  git co master
  git pull
  git co feature-splash
  git co -b my-feature-splash  // they can name their branch whatever