问多个开发人员处理同一任务的适当git工作流方案

EN

我真的不能谈论你的帖子中描述的方法的优点，但我可以描述我们是如何在工作中使用的工作流程中解决协作编码的。

我们使用的工作流是众多分支中的一个。我们的结构是这样的：

Master是金色的；只有合并master才能接触到它(稍后会详细介绍)。

有一个dev分支，最初取自master，所有开发人员都会停止工作。而不是每个开发者都有一个分支，我们从dev中创建了功能分支或票证分支。

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

一旦该功能准备就绪，就会在本地将其合并回dev，并将其推送到云上(Bitbucket、Github等)。每个人都通过经常打开dev来保持同步。

我们每周发布一次，所以在QA批准开发分支后，每周都会创建一个名称中包含日期的发布分支。这是生产中使用的分支，取代了上周的发布分支。

一旦发布分支在生产中被QA验证，发布分支就被合并回master (和dev，只是为了安全起见)。这是我们唯一一次接触师父，以确保它尽可能的干净。

我们有一个12人的团队，这对我们来说工作得很好。希望这对我们有所帮助。祝好运!

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

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

在服务器开发人员不关心客户端开发更改的特定情况下，最好的做法是在本地从开发/功能分支派生客户端分支，并在完成功能之前将该部分重新设置为服务器工作的基础。-or放松约束并切换到不同的工作流程，就像您所做的那样;)

我们有一个主存储库，每个开发人员都有一个分支。

创建一个分支主体/some_project，然后在每个开发人员的fork上创建相同的分支名称fork/some_project。

(我们使用的是smartgit，而且我们还有一个策略，将远程命名为“主体”和“分叉”，而不是命名为“源”和“上游”，这只会让新用户感到困惑)。

每个开发人员还拥有一个名为some_project的本地分支。

开发人员本地分支项目跟踪远程分支主体/some_ some_project。

开发人员在分支项目上进行本地工作，并推送到他们的分支/ some_project _project，他们不时地创建拉取请求，这就是每个开发人员的工作如何合并到主体/某些项目中。

通过这种方式，开发人员可以自由地在本地拉/重建立基础，并推送到他们的fork -这几乎就是标准的fork工作流程。通过这种方式，他们得到了其他开发人员的提交，并且可能需要时不时地解决一些奇怪的冲突。

这很好，现在所需要的就是合并出现在主体/主控中的正在进行的更新(例如，紧急修复或在some_project完成之前交付的其他项目)。

为了实现这一点，我们指定了一个“分支主管”，他们的角色是在SmartGit中使用merge (而不是pull，rebase)将来自master的更新本地合并到some_project中。这有时也可能产生冲突，这些冲突必须得到解决。一旦完成此操作，开发人员(分支负责人)将强制推送到他们的fork/some_project分支，然后创建一个拉入请求以合并到主体/some_project中。

一旦拉取请求被合并，所有在主体/主上的新提交现在都出现在主体/某些项目分支上(并且没有任何东西被重新建立基础)。

因此，当每个开发人员下一次使用some_project和pulls (回想一下，他们跟踪的分支是主项目/某些项目)时，他们将获得所有更新，其中将包括从主项目/主项目合并的内容。

这听起来可能很冗长，但实际上是相当简单和健壮的(每个开发人员也可以从主体/主控中本地合并，但如果一个人这样做会更简洁，团队的其余成员生活在一个简单的世界中，就像单个开发人员的工作流程一样)。