59

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

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

但是这种方案仅在单个开发人员在分支上工作的情况下才有效。在我们的例子中，一个分支几乎总是有两个开发人员，因为一个开发人员在服务器端(PHP) 工作，而另一个开发人员在客户端(HTML/CSS/JS) 工作。这两者应该如何以某种方式协作，使 master 中的提交历史保持干净？

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

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

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

4

8 回答 8

87

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

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

师父是金；只有合并大师会触及它（稍后会详细介绍）。

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

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

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

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

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

这对我们有 12 人的团队很有效。希望对我们有所帮助。祝你好运！

于 2013-02-14T07:04:56.227 回答
7

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

正确的答案是对不起，你不能把所有这些放在一起。你只能修饰你的私人本地历史，在你为其他人发布一些东西之后，你应该在此基础上工作。

在服务器开发不关心客户端开发更改的特定情况下，您可以做的最好的事情是在本地从开发/功能分支中分叉客户端分支，并在完成功能之前将该部分重新设置在服务器工作之上 - 或放松您的约束并像您一样切换到不同的工作流程；）

于 2014-04-29T15:38:41.630 回答
7

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

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

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

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

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

开发人员在分支 some_project 上进行本地工作并推送到他们的 fork/some_project，他们不时创建拉取请求，这就是每个开发人员的工作如何合并到 principal/some_project 中的方式。

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

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

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

合并该拉取请求后，principal/master 上的所有新提交现在都出现在 principal/some_project 分支上（并且没有任何内容被重新定位）。

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

这听起来可能很啰嗦，但实际上相当简单和健壮（每个开发人员也可以从主体/主服务器本地合并，但如果一个人这样做会更整洁，团队的其他成员生活在一个简单的世界中，就像单个开发人员的工作流程一样） .

于 2017-01-19T23:00:03.190 回答
3

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

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

然而，只有当另一个用户在这些提交被重新定位之前从其中一个提交中分支时，这才会是一个问题。在较小的项目/较小的用户群中，即使在变基发生之前，这些临时提交也可能永远不会被注意到，从而消除了风险。

如果有人从这些临时提交分支的风险太大，则由您决定。如果是这样，那么您可能需要为这些私有更改创建第二个私有 Bitbucket 存储库。另一种选择是合并提交 而不是变基，但这也不理想。

于 2013-02-14T04:38:21.667 回答
3

要记住的规则是：

  • 有 1 个master和 1 个develop分支
  • 让功能分支从分支develop产生
  • 每次您准备好供QA测试的版本时，合并到develop
  • 让发布分支从分支develop产生
  • 在发布分支中进行错误修复
  • 当您准备好供QA测试的版本时，合并到develop
  • 当您为PRODUCTION准备好版本时，合并到master并为其创建标签

下图是世界各地团队遵循的靶心策略（图片来源：取自这里）：

在此处输入图像描述

于 2018-08-17T07:31:10.460 回答
2

对于确切的问题，多个开发人员在同一任务上，简短的回答是该任务是在该任务的集成分支中完成的。该“任务”分支被视为通常 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

现在，每个开发人员都将在他们的分支上进行开发，并在中央 Git 存储库服务器（如 GitHub）上的功能飞溅上创建合并请求。就像为神圣的“主”分支所做的那样。

功能完成后，功能飞溅将合并到主控中。当然，这个特性飞溅必须与 master 上的新代码保持同步。功能飞溅可以使用基于 master 的 rebase 吗？

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

于 2019-04-07T04:09:53.113 回答
2

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

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

  1. 大师（被保护了，除了领队，没有人能推到这里）
  2. 开发（所有开发者都可以在这里推送）

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

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

  1. Git 拉取

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

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

例如。

  • 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

并创建提交和推送。

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

于 2016-06-04T18:09:34.203 回答
1

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

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

于 2013-02-14T07:19:28.223 回答