标签: git-flow

需要一些帮助来组织分支和工作流程。
前提条件：10 名使用 git 的开发人员，0 单元测试覆盖率，10^5 行代码。

在我们的仓库中，有一个master充当production.
每个功能都在不同的分支上开发，这也创建了一个新的域 ( branch.qa.com)

完成后，QA 团队会检查更改branch.qa.com，然后将其合并到主服务器中并自动推送到生产服务器。

问题：
分支 A 可能有css变化。它被上传A.qa.com并被检查。
同时，开发人员B从其分叉分支master并对其进行处理，修改相同的css.

这两个更改对于其分支来说似乎都是合法的，但可能会发生这种情况，即更改B实际上会破坏 上的某些内容A。

合并A进去master就ok了 那么合并B到master就会对 所做的改变产生不好的影响A。

请问您排除这种情况吗？你如何合并pre production？

我有一个由几个人组成的团队，使用 git flow 方法（master、develop、hotfixes、features、releases）和一个远程裸存储库来处理同一个 git 存储库。

我们有一个包含一些提交的修补程序，已成功合并到 master 中，一切都很好。现在，一周后，经过很多更改，在继续开发之后，我们有了一个发布分支，但也没有合并到 master 中。

我们注意到系统中的一些文件已恢复到修补程序之前的状态。这些文件最近才在提到的修补程序中被触及，并且在开发分支中没有对它们进行进一步的更改。

奇怪的是，我在 git 日志历史记录中找不到显示任何这些文件存在冲突的合并，这可能表明团队成员遇到了冲突并且没有正确解决它。

我所能看到的只是添加了所需更改的修补程序的提交，但我找不到恢复这些更改的后续提交。

git whatchanged -p -r -m -- myfile我再次尝试使用，我看到的只是修补程序的提交。

我怎样才能知道这些文件发生了什么？这可能是我的存储库中的损坏吗？

详见我们的项目是使用gitflow这里我的问题是如何做QA适应这个。

考虑我有一个 master 分支和一个 hotifx 分支。一旦修补程序完成，那么我相信 QA 应该在修补程序发布时做它的工作。如果它没有通过，则使用此修复程序更新修补程序。QA 再次发布。现在，当修补程序 RC 通过 QA 时，代码将合并回 master（应该没有冲突，并且只是作为 master 的直接副本没有更改）。然后从 master 完成生产发布。令人担忧的是，QA 尚未验证此版本。他们已经验证了一个修补程序版本。

我们如何协调 master 仅用于生产代码，但对接近足够的生产代码进行 QA 测试？任何人对这种情况有任何经验吗？我看不到任何详细说明 QA 和测试如何融入 gitflow 的内容。

谢谢

在过去的几个月里，我们一直在工作中松散地跟踪 git flow，但遇到了漫长的 QA 等待问题。

这是我们的流程：

• 开发人员在功能分支上进行本地开发
• 当团队认为该功能准备就绪时，将其合并到开发中，推送到开发服务器（Codeship & rsync）
• 客户批准功能
• 功能合并到 master，推送到 prod

不幸的是，客户有时可能需要长达数周的时间来批准一项功能。这可能是由于积压、内容创建、人员流动等原因。

但是，与此同时，新功能可能已合并到开发中并推送到开发服务器进行审批。假设第二个功能获得批准并需要尽快部署（当然）。我如何在不带第一个功能的情况下从 dev 中获得第二个功能？

总的来说，我们对 git 比较陌生。我们已经使用了大约 6 个月，并且使用过 GitHub 和 BitBucket。我们尝试通过使用 GitBash 尽可能多地学习，以便深入了解 git 的核心。

我们正处于真正想要考虑我们的分支策略的阶段，因此我一直在做一些研究。

在我看来，GitFlow 对我们的要求来说过于复杂。我们总共参与了大约 20 个不同的项目，每个项目可能每 2 个月左右发布一次。查看 GitHub Flow 后，这似乎是一个非常直接的选项，可以满足我们的需求 - 但是它似乎确实有一个缺陷，我希望人们对此发表意见。

master 分支中的任何内容都是可部署的。我们部署到 UAT/QA 环境，该版本可能会保留 3-4 周，具体取决于客户和/或我们签署所有内容所需的时间。与此同时，其他人可能需要做一些完全不同的事情。在这个阶段，基于 Github Flow 的流程，如果该用户从 Master 那里获取了一个分支，他们将包括此时实际上仍在 QA 环境中的更改。那么，是不是我误解了 GitHub Flow 的第一点——即 master 分支中的任何东西都是可部署的——如果代码已经通过 QA 等，这可能才正确吗？

如果是这样的话，流程实际上看起来更像吗？：

• 从 Master 取一个分支
• 在分支中提交更改（仅在此阶段返回分支）
• 将分支与名为“Develop”的单独分支合并
• 发布到 QA/UAT
• 当 Release 被批准时，将分支与 Master 合并并部署？

我认为 GitHub Flow 中的第 1 点让我们感到困惑——当发布仍处于 QA 阶段时，我们当然不应该将其推回 Master——这将使 Master 分支可能不稳定，当然不是目前在生产中的分支。

我工作的公司正在使用 gitflow。

我们遵循每个功能分支的方法，其中实现、测试单个功能，然后 PR 进入开发阶段。当需要发布时，我们会在开发之外创建一个发布分支 - 我们在发布分支上触发构建并将其部署到 TEST 环境。由于合并到开发中的多个功能分支，可能存在一些集成缺陷。这些是直接针对发布分支解决的。一旦我们很高兴与发布分支，我们部署（确切的状态同样是签署过建立由QA），以督促。

在这个阶段，我们需要让我们的发布分支代码回到 develop 并进入 master，这两个分支都是受保护的分支。假设有一些针对 release 分支的提交，我们需要做 2 个 PR，即一个用于 release->develop，一个用于 release->master。

几个问题：

1. 人们如何直接针对发布分支审查提交？我们 可以在实际发布之前重新进行 PR 开发，但这对我来说似乎有点不合时宜。
2. 人们如何处理将发布分支合并到开发和主分支中的方法。要开发的 PR 只是直接针对发布分支进行的提交，而要掌握的 PR 还将包括已经 PRd 到开发中的所有功能。掌握的公关似乎有点过时了。

谢谢。

假设有 5 个功能合并到开发中（例如 ABCDE），但其中一个功能没有通过 QA（例如 C）。

如何在排除功能的同时启动发布分支？

我想通过仅读取.git文件夹中的内容来获取当前分支或标签。

我看了很多的解决方案，它们都依赖于执行git status，git branch，git describe，或类似的东西，然后解析输出。但是如果我们不能确定有一个git二进制文件可以调用怎么办？我们不能依赖那个。

对于分支，它看起来几乎非常简单：cat .git/HEAD，但对于标签，它变得有点复杂。我git-flow用来创建我的特征分支和我的标签。当我切换到标签时，我得到：

$ git checkout tags/v0.11.2 
Note: checking out 'tags/v0.11.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you …

我已经为我继承的 repo 配置了 gitflow，我有三个环境：

• 开发（在提交到开发分支时部署到）
• 质量（在提交到master分支时部署到）
• 生产（从 CD 工具部署到，但从master选择最新提交）

我们还使用修补程序来修复生产问题。

您可能会推断出，在我们的质量（测试期间）期间，我们实际上无法进行热修复，因为生产环境和质量都取自master的最新提交