适当的git工作流程方案，多个开发人员在同一个任务上工作

Question

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

我们在Bitbucket中有一个存储库。主分支仅被视为包含稳定代码。每个开发人员都必须创建自己的分支，并在自己的分支中实现功能/错误修正。一旦他决定，他的代码准备就绪，他创建了一个很好的分支历史（使用rebase，修改，樱桃挑选等）并将其推送到Bitbucket，在那里创建一个拉动请求到主分支。质量检查验证功能并批准（或不批准）它，然后我验证代码，如果可以，我将他的工作合并为主（通过快进或重新定位以获得更好的提交历史记录）。

但是这种方案只适用于单个开发人员在分支机构上工作的情况。在我们的例子中，我们几乎总是有两个开发人员用于一个分支，因为一个开发人员在服务器端（PHP），另一个开发人员在客户端（HTML / CSS / JS）。这两者应该如何以一种方式进行协作，使主人的历史保持干净？

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

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

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

Answer 1

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

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

师父是金;只有合并主人接触它（更多关于这一点）。

有一个dev分支，最初是从master开始的，所有开发人员都会工作。我们不是为每个开发人员提供分支，而是从dev创建功能或分支。

对于每个谨慎的功能（错误，增强等），都会从dev创建一个新的本地分支。开发人员不必在同一分支上工作，因为每个功能分支的范围仅限于该单个开发人员正在处理的内容。这就是git便宜的分支派上用场的地方。

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

我们按周发布时间表，因此每周，在QA批准开发分支后，将在名称中使用日期发布分支。这是生产中使用的分支，取代了上周的发布分支。

一旦QA在生产中验证了发布分支，发布分支就会合并回master（和dev，只是为了安全）。这是我们唯一一次接触主人，确保它尽可能干净。

对于我们这个团队来说，这非常有效。希望它有所帮助。祝好运！

Answer 2

我想仍然没有人真正回答过如何在保持干净历史的主题分支中进行协作的原始问题。

正确的答案很遗憾，你不能把所有这些都放在一起。您只能修改您的私人本地历史记录，在您为其他人发布内容之后，您应该在其上工作。

在您的服务器开发人员不关心客户端开发人员更改的特定情况下，您可以做的最好的事情是从开发/功能部件本地分支客户端分支，并在完成功能之前在服务器之上工作部分 - 或放宽您的约束并切换到不同的工作流程，就像你做的那样;）

Answer 3

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

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

（我们使用smartgit，我们还有一个策略，遥控器被命名为'principal'和'fork'而不是'origin'和'upstream'，这只会让新用户感到困惑）。

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

开发人员本地分支some_project跟踪远程分支principal / some_project。

开发人员在分支some_project和push-to到他们的fork / some_project上进行本地工作，他们不时创建pull请求，这就是每个开发人员的工作如何合并到principal / some_project中。

这样开发人员可以自由地在本地提取/重新绑定并推送到他们的分支 - 这几乎是标准的fork工作流程。通过这种方式，他们可以获得其他开发人员的提交，并可能不时地解决奇怪的冲突。

这很好，现在需要的是一种合并在主体/主体中出现的持续更新的方法（例如紧急修复或在some_project完成之前交付的其他项目）。

为了实现这一目标，我们指定了一个“分支引导”，他们的角色是使用SmartGit中的merge（而不是pull，rebase）将master中的更新本地合并到some_project中。这也有时会产生冲突，必须解决这些冲突。完成此操作后，开发人员（分支负责人）强制推送到他们的fork / some_project分支，然后创建一个pull请求以合并到principal / some_project中。

一旦该请求被合并，所有在Principal / master上的新提交现在都存在于principal / some_project分支上（并且没有任何重新设置）。

因此，下次每个开发人员访问some_project并拉（回想一下，他们跟踪的分支是principal / some_project），他们将获得所有更新，其中包括从principal / master合并的内容。

这可能听起来很长，但它实际上相当简单和强大（每个开发人员也可以只从本地/主人本地合并，但如果一个人这样做更整洁，团队的其余部分生活在一个简单的世界，就像单个开发人员的工作流程） 。

Answer 4

您可能会看到Git-flow这可能会对您有所帮助

http://nvie.com/posts/a-successful-git-branching-model/

Answer 5

这将使他无法改变或改变已经发布的提交。

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

但是，如果另一个用户在重新设置之前从其中一个提交中分支出来，那么这只会是一个问题。在一个较小的项目/较小的用户群上，这些临时提交甚至可能在转折发生之前就不会被注意到，从而抵消了风险。

如果从这些临时提交中分支出来的人的风险太大，那么您的决定就属于您。如果是这样，那么您可能需要为这些私人更改创建第二个私有Bitbucket仓库。另一个选择是做merge commits而不是变基，但这也不理想。

Answer 6

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

首先，我们的团队领导创建了具有两个分支的git项目

1. 大师（它是受保护的，没有人可以推到这里，除了团队领导）
2. 开发（所有开发人员都可以推送）

他们告诉我们，只要我们完成了一个已分配的任务，就可以在我们的本地环境中工作并创建提交。

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

1. 去拉

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

然后团队领导告诉开发人员提交所有代码并逐个推送，然后一次拉动。

对于前者

• dev1创建提交并推送到服务器
• dev2再次拉动并创建提交和推送
• dev3再次拉动并创建提交和推送
• 等等..

现在问题是冲突：

• 有时从开发分支中提取代码git会通知我们自动合并所有冲突 - 这意味着git会自动应用其他开发人员所做的新更改
• 但有时SAME git告诉自动合并失败并显示一些文件名
• 然后团队领导角色出现了 - 他的工作是：“他审查所有列出的文件（在自动合并失败过程中）并手动合并冲突并创建提交并推送到服务器。

现在如何手动合并：GIT只是用这样的所有内容更新冲突文件：

<<< 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

并创建提交和推送。

再次在早上我们拉（只是为了确保我们没有错过前一天的任何事情），这就是我们在这里工作的方式。

Answer 7

要记住的规则是：

• 有1个master和1个develop分支
• 有功能分支从develop分支产生
• 每次你准备QA测试的版本，合并到develop
• 有释放分支从develop分支产生
• 将错误修正发送到发布分支
• 如果您准备好QA测试版本，请合并到develop
• 当您为PRODUCTION准备好版本时，请合并到master中，并为其创建标记

下图是世界各地团队遵循的牛眼策略（来自here）：

Answer 8

对于确切的问题，多个开发人员在同一个任务上，简短的回答是任务是在该任务的集成分支中完成的。在通常的Git工作流程中，“任务”分支被视为“主”或“开发”分支（如此处提供的大多数答案）。此集成分支在其他地方详述的“Git功能分支工作流程”中处理。

此任务分支是处理该任务的开发人员使用普通Git命令共享代码的地方。

例

要开发新的启动画面，首席开发人员（或其他人）可以

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

现在每个开发人员都将在他们的分支上开发并在GitHub等中央Git repo服务器上的功能启动上创建拉动请求。就像神圣的“主人”分支一样。

功能完成后，feature-splash将合并到master中。当然，必须使用master上的新代码更新此功能。 feature-splash可以在master上使用rebased吗？

这不是我最初的想法。我在各个地方读到了这个。请注意，在许多工作流文章中，此任务特定分支实际上不是一个概念。例如，在一篇文章中，我们有“功能分支通常只存在于开发人员存储库中，而不是原产地”。也许需要多个开发人员的任务总是分解为子任务？我想如果你了解未来并知道需要什么。