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

Question

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

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

但是这种方案只适用于单个开发人员在分支机构工作的情况。在我们的例子中，我们几乎总是有两个开发人员用于一个分支，因为一个开发人员正在开发服务器端（PHP），另一个开发人员 - 客户端（HTML / CSS） / JS）。这两者应该如何协作，在master中保存历史记录保持清洁？

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

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

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

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，我们还制定了一项政策，即遥控器名为＆＃39; principal＆＃39; fork＆＃39;而不是＆＃39; origin＆＃39;和＆＃39; upstream＆ ＃39;这只会让新用户感到困惑。）

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

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

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

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

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

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

一旦合并了pull请求，所有在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-project

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

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

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

1. Git Pull

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

然后，团队负责人告诉开发人员提交所有代码并逐个推送，然后拉一下。

对于前。

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

现在问题是冲突：

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

现在如何手动合并：GIT只是使用以下所有内容更新冲突文件：

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

Team-lead在分析之后更新该文件：

 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分支中产生了发布分支
• 将错误修正纳入发行分支
• 准备好要进行质量检查测试的版本后，合并到develop
• 准备好用于 PRODUCTION 的版本后，合并到master中，并为其创建标签

下图是全球团队所采用的靶心策略（来源：摘自here）

Answer 8

对于确切的问题，多个开发人员正在执行同一任务，简短的答案是该任务是在该任务的集成分支中完成的。在通常的Git工作流程中，该“任务”分支的处理方式与“ master”或“ dev”分支一样（此处提供了大多数答案）。该集成分支在其他地方详述的“ Git Feature分支工作流程”中进行处理。

此任务分支是从事该任务的开发人员使用常规Git命令共享代码的地方。

示例

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

let lines = map(getline(1, '$'), '[v:key + 1, v:val]')
call filter(lines, 'v:val[1] == "EXPRESSION"')

每个使用此功能的开发人员都这样做：

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

现在，每个开发人员都将在自己的分支上进行开发，并在中央Git回购服务器（如GitHub）上的功能飞溅上创建向合并请求的拉取请求。就像为神圣的“主”分支所做的一样。

完成功能后，功能飞溅将合并到母版中。当然，必须使用master上的新代码使此功能飞溅保持最新。可以在主控板上使用功能飞溅吗？

这不是我的初衷。我在各个地方都读到了有关此事的信息。请注意，在许多工作流程文章中，这个特定于任务的分支并不是一个真正的概念。例如，在一篇文章中，我们有“功能分支通常仅存在于开发人员存储库中，而不存在于源中。”也许需要多个开发人员的任务总是分解为子任务？我猜你是否知道未来，知道需要什么。