标签: git-flow

我正在使用git-flow进行开发,而Bundler则发布我的gem.我的问题是如何同时使用git-flow release和rake release.两者都标记git,因为标签是相同的,所以存在冲突.

如何在不删除标签的情况下处理此问题.现在我在开发分支(git-flow)上,并使用git-flow将其移动到主分支,您使用git-flow版本.

谢谢你的帮助,

-Damien

我在Git hub上设置了一个存储库,我正在使用git flow.我知道如何创建功能,发行版和修补程序,但是从我到目前为止所读到的内容看起来并不清楚如何推送到中央存储库(github),因此我有几个问题:

1. 一旦一个功能完成,你已经运行了git flow feature finish如何将其推送到github？
2. 一旦它被推送到Github我是否需要从Github拉出来或者我们是否从未触及中央仓库并且只是使用它以便其他开发人员/服务器可以从中获取？
3. 开发人员如何使用git flow从中央仓库中撤出？

谢谢

我们经常从master分支到大型功能分支.这些功能分支通常在与master合并之前工作数天甚至数周(尽管最佳实践要求我们需要尽可能频繁地合并,实际上它可能会有所不同).

因此,我们尽可能地尝试git pull --rebase origin master以便与master保持更新.但是,我们偶尔会遇到以下情况:

1)从master分支到分支feature/new-branch

2)进行更改feature/new-branch并提交更改.

3)git pull --rebase origin master把提交放在主人的头上.修复任何冲突和git add .+git rebase --continue

4)进行更多更改feature/new-branch并提交更改.

5)git pull --rebase origin master再次.

但是,在步骤5),该过程要求我们从步骤3)修复相同的冲突.哪个可能很乏味.

这是正确的最佳实践git流程,如果没有,我们还能做些什么来提高流程效率？

我们使用Gitflow进行Web构建,我对如何hotfixes工作有疑问.但首先我应该解释一下,我们并没有完全使用正常的Gitflow工作流程.

我明白,通常你会分支你的features,他们会develop在完成时合并,你会创建你的release,release合并到master你并部署它,作为一个真正的"版本化版本".

但是,由于这是客户端工作,我们不会执行"发布",而是在需要时部署功能,因此我们的feature分支的更改会master在临时基础上合并.

这确实会引起问题,因为feature分支从分支开始develop就超前了master; 合并这些feature分支到master会合并其他的改变到master的变化(即存在于develop在当时feature是支链的都还尚未master).我们知道这不是Gitflow的设计方式,但我们需要某种分支模型,所以我们(有点)通过提交提交而不是合并分支来解决这个问题.

所以,我理解这些问题,我不相信他们正在为我现在的问题做出贡献,但为了以防万一,这就是我们使用它的方式.不过我的问题是:

hotfixes 应该怎么合并？

在我看来,情景是:

• master 是"生产"
• develop 领先于 master

然后,您想要修补hotfix分支的即时问题.在Gitflow中,这个分支来自master,当你完成时hotfix,它会被合并到master 和 develop

但这怎么不会造成大问题呢？

最近,我尝试创建一个hotfix在一个文件中更改单行副本.我完成了hotfix,并且更改合并到master没有任何问题,但是当它厌倦了合并时develop,它创建了一个巨大的35文件差异,在我没有触及的文件中有几个合并冲突,由于develop和之间的差异master.

我明白,这是因为你被合并hotfix 的分支,其本身分支master …

我们正在Gitflow用于git分支工作流程（通过TFS）。发布成功后，我们将执行以下操作

1. 将请求从发布拉到主
2. 从发布中拉出请求以进行开发

第1步创建提交（合并PR XXX：将发行版合并到母版）

第2步创建提交（合并PR YYY：合并要开发的版本）

当我查看我们的分支机构时，它说开发是主人的一项承诺。这是因为提交（合并PR：XXX）不在开发中。

是否简单地从主节点创建另一个要创建的拉取请求的正确过程（即使拉取请求中没有更改）？

我在标准的Gitflow模型上看不到

我正在尝试在Jenkins中建立持续集成以进行git流式开发.我以为我会创建三个工作来构建RPM包:用于master,develop和最新的发布分支.

问题在于最新的发布分支,因为我不确定是否可以设置构建以便Jenkins轮询我的git repo,并且只有在最新版本/*分支中发生更改时才进行构建.人们更常见的是克隆工作和核心分支名称,还是我打算做什么？

Gradle 属性存储到名为gradle.properties. 它可以位于项目根目录或~/.gradle/

根据gradle.org上的这个讨论，项目根目录中的属性文件应该包含项目特定的属性并且应该在源代码控制之下（在我的例子中是 Git）。用户特定的属性应该在， ~/.gradle/gradle.properties以便它们不会在 SCM 下提交。

但是，我应该将特定用户的特定属性放在特定项目的何处，比如说中央 Git 存储库的凭据？

我正在使用jgitflow-gradle-plugin需要属性gitUsername和gitPassword. 这些属性不应该被明确提交。因此，它们不能放在项目根目录的 gradle.properties 中。另一方面，它们不应该由不同的项目共享，因为我可以使用具有不同凭据的不同 Git 中央存储库。

有没有办法gradle.properties在一个项目中使用多个文件？其中一个将被提交，另一个将被忽略。

我最近阅读了有关 github 流程的信息。我现在正在使用 gitflow，我发现 Github flow 看起来很有趣，因为它在工作流方面不像 gitflow 那样繁重。

我不明白的是，一旦功能完成，就会创建一个拉取请求。在合并回 master 之前如何测试这些更改（准备生产）。在 gitflow 中，一旦将某些内容提交到发布分支 UAT 环境中，我就有一个 CI/CD 任务，并且当测试完成并且一切正常时，更改将合并到 master 中并进行部署。在 Github flow 中 UAT 环境的位置在哪里？

我使用Gitflow开发原理开发了一个 Python 库，并有一个用于单元测试和包上传到（私有）PyPI 的CI阶段。我想在将上传的包合并回集成分支之前使用它进行测试。

其他包管理器（和流行的工具）允许版本标识符包含功能分支特定标识符，例如1.2.3-my-feature-alpha.1符合SemVer。然而，PEP-440禁止使用此类版本控制方案，twine甚至拒绝此类上传。

如果想要创建此类预发行版（可能与多个功能分支并行发生）且不存在符合 PEP-440 的版本标识符冲突，那么命名 Python 包版本的正确（或可行）方法是什么？

我目前正在为我的团队制定工作流程。我们收到的建议是使用 GitFlow 方案。该方案可以放在图表上如下：

但是，我有一个关于如何管理特定案例的问题。由于我们的活动，我们必须维护客户可能仍在使用的以前版本，并且由于各种原因不想更新。

在 GitFlow 方案中，主干应该是发布发生的地方。主干中的提交是可能可交付的产品，并且应该收到版本标签。

那么...我怎样才能回到过去，为旧版本生成修复程序并将其合并回主干以生成该版本？

另一个问题是我是否不想将该修复程序带回后备箱？

在我看来，这种工作流程更适合不断向客户推送新版本的软件，例如移动应用程序，但不适用于工业产品，即使它们是从 CI 构建的。但也许我在这里遗漏了一些东西，因此我的问题