标签: git-flow

在工作中,我们有一个基于git流的git工作流.我们有3个主要分支:dev,release和master

Dev是我们目前正在开发的东西,master就是我们在生产和发布中所拥有的是当我们正在进行发布并进行最后的bug修复时.当发布准备就绪时,发布分支将合并到master中并推送到生产中.

在master中创建的任何修补程序也会被推送到dev(和发布分支(如果当前正在运行))

问题是现在我们如何确保发布分支中的代码实际上是合并后的主代码？换句话说,release和master之间应该没有差异(合并之后).

当从发布分支合并到master时,我们也不想处理冲突,因此任何这些都应该自动处理.

尝试了几次,包括先前的下载和手动获取子模块.有没有人有解决方法？

SilverFir-2:SRC mike$ sudo ./git-flow-installer 
### gitflow no-make installer ###
Installing git-flow to /usr/local/bin
Cloning repo from GitHub to gitflow
Cloning into 'gitflow'...
remote: Counting objects: 1407, done.
remote: Compressing objects: 100% (602/602), done.
remote: Total 1407 (delta 893), reused 1285 (delta 790)
Receiving objects: 100% (1407/1407), 358.18 KiB | 121 KiB/s, done.
Resolving deltas: 100% (893/893), done.
Updating submodules
Submodule 'shFlags' (git://github.com/nvie/shFlags.git) registered for path 'shFlags'
Cloning into 'shFlags'...
fatal: unable to connect to github.com:
github.com[0: 204.232.175.90]: errno=Operation timed …

我们使用GitFlow来管理我们的软件存储库:http://nvie.com/posts/a-successful-git-branching-model/

我有一种情况,我不知道如何处理这个分支模型.

在几个星期的时间里,我做了大约十几个提交到一个feature分支(分支develop).为了减轻合并的负担develop,我在这两周的过程中将变化合并develop到我的feature分支中3次.该feature分公司完成且其变动合并回develop.

然而,事实证明,在大约一个月前release分支的分支上也需要此功能develop.有没有办法合并来自旧分支的更改,但省略了develop我合并到其中3次的更改？

这两个命令都会将代码推送到受关注的分支，以便其他开发人员可以在该分支上工作。那么这两个命令的确切区别是什么？

我一直在 git 中寻找一个好的分支模型，发现GitFlow非常适合我们的开发环境。然而，一个悬而未决的问题是如何以及在何处测试我们的版本。

发布分支听起来像是在发布之前运行所有回归测试的地方。然而，发布分支然后被合并到 master 中，被标记，这就是最终用于生产的东西。如果从 release 分支到 master 的合并冲突会发生什么？听起来像 master 需要完全重新测试（这可能很昂贵）。即使没有冲突，简单地将合并推送到生产环境是否安全，或者是否需要运行额外的基本烟雾测试？

我们已经注意到，在“git flow release finish”之后，“develop”分支是“master”之前的一次提交。

以下是额外的提交。

commit b4c00f50c980f22c0afcc15bd61e4911bd6bb5d5
Merge: 4000a21 18e1aee
Author: Joe Bloggs <joe.bloggs@hotmail.com>
Date:   Tue May 31 15:27:30 2016 +0100

Merge tag '1.0.0.4' into develop

1.0.0.4

提前致谢

我将 GitFlow 与映射到用户故事的功能分支一起使用。本质上，每个功能分支都代表一个用户故事。当故事完全实现和测试时，它被认为已经完成，并且功能完成（合并回开发分支）。

我现在的问题是我的功能已被拆分为 Epic，目的是制定渐进式部署计划。每个故事都应该是一个特色。绝大多数故事都经过设计，因此它们之间实际上没有任何依赖关系，以便能够单独实现它们。然而，需要注意的是，它们都依赖于一个共同的故事。

目前，common story（特性）已经完成，但是还没有通过测试/QA部门，所以我还不能把它合并回develop分支。但我想开始创作史诗中的另一个故事。

此时的“正确”过程是什么？我应该从现有功能分支的 HEAD 创建一个功能分支吗？它不遵循典型的 GitFlow 流程，所以我想知道其他人是如何解决这种情况的。

1. 我们可以在 git-flow 中将develop 分支合并到feature 分支中吗？

2. 如下图所示，有 2 个功能分支（A（红色）和B（蓝色）），由两个开发人员分配。当B需要从一些代码A，将它允许是A推动发展下去编码，然后B从发展拔呢？

3. 一个合并开发分支，没有合并而是覆盖，为什么，以及如何解决它？

我的问题是围绕 gitflow 过程中的一个非常具体的点（如此处所述）。

我已经将错误修正从release/1.2into合并master，并适当标记。

除了历史长相，有什么之间的差异是如何从背合并release/1.2从VS背合并master成develop。

我已经尝试了两种方法，在我简单的、人为的例子中，我看不出有什么不同develop，正如我预期的那样。

这有危险吗？我以后会遇到麻烦的问题吗？我错过了一些明显的东西吗？我怀疑答案可能与已经进入的其他功能有关master，但目前应该保留develop。

合并发布以开发：

合并主开发：

我们搭建了一个Asp.net核心微服务项目，将代码组织成一个超级项目和多个Git子模块（每个微服务就是一个子模块）。现在我们要开始使用 Git Flow 工作流。

初始化 gitflow 的最佳方法是什么？我们是否需要每个子模块有一个 git 流，或者我们应该在超级项目级别有一个全局 git 流？

谢谢！