标签: git-flow

我使用git flow创建了一个修补程序.现在我不久前做了这件事,并将少量文件提交给开发环境.然后我切换到另一个功能.现在我希望看到我针对此修补程序更改/提交的文件列表.

任何人都可以给出如何列出文件的命令.

请原谅我的无知，但我正在尝试将“git-flow”模型付诸实践（手动，没有 git-flow 工具集）。

我发现一个有趣的概念是，会有一个主分支，每个提交都是真正可行的发布。所以你在 master 上标记了 v1.0.0 提交，然后是 v1.1.0 标记，当查看 master 时，这是一个不错的 2-commit-long 日志。但是你已经准备好发布 v1.2.0 并且你的develop分支有 1000 个中间提交，但是你已经准备好签字并按下按钮说“好吧，现在是发布时间”。

我的目标是在主时间线上添加第三次提交。我可以看到该--squash选项可以让您向 master 添加一个提交，因此您可以查看 master 日志并查看您的三个提交：v1.0.0、v1.1.0 和 v1.2.0。尽管开发分支可能冗长而冗长，但压缩可以让您了解 master 的整洁历史，其中每个版本都是正式发布......没有机会抓住中间开发提交！

它有效，但让我困扰的是，在网络图中查看这会产生“断开连接”的提交。Git 理解将这个被压扁的第三次提交与开发分支的所有数千个添加绑定在一起没有明显的关系。它似乎是单独漂浮的，不像 git-flow 图是手绘的并且总是指向事物。

获得“合并箭头”（又名多个父项）的其他合并选项似乎具有与中间提交建立连接的副作用。所以突然之间，master 不仅仅是这 3 个有福的提交……它已经扩展到包括所有这 1000 个开发提交的完整历史。如果 master 的重点是只包含可发布版本的分支，这似乎违背了目的……但突然间，每个中间状态都对 master 进行了提交。1003 而不是 3 个主提交。

Git 可视化有点险恶，因为它掩盖了分支中的重复。所以我在 git-flow 上看到的图表是图片而不是终端打印输出git log等。我不确定人们对像说 master 只包含可发布版本这样的声明有什么期望。

长话短说：除非它们带有完整的提交历史，否则我找不到在发布点保留 develop 和 master 之间“箭头式”关系的选项。如果我查看有很多箭头的 git-flow 图，我会担心吗？在我概述的场景中，我应该查看主历史记录并查看合并的每个中间开发版本和 1003 次提交历史记录，还是 3 次提交历史记录？

假设我有一个开发分支，并且在某个功能分支中工作，其中我有一个或多个提交，我不断修改提交并与其他一些分支进行变基（以保持提交历史记录干净以供将来使用）。在每个阶段，我都会在本地进行与开发相关的差异。所以我有一组差异，我想看看它们之间的区别。我怎样才能轻松做到这一点？我可以使用什么样的 git 命令序列？

更新

解决方案是有两个与开发相关的差异。在开发中拥有存储库的副本，应用第一个差异。复制花药并应用另一个补丁。使用一些比较工具并比较两个存储库。这将是我所期望的结果。这种方法的问题是我需要至少有两个存储库副本，并使用一些工具来比较目录。另一种可能更好的方法是使用两个分支，应用补丁并提交更改，然后比较分支。问题： git 命令中是否有更简单的东西可以做到这一点？比如拿这个分支和两个 diff 文件，返回给我 diff？

在 symfony/symfony 项目中，我看到 master (3.3-dev) 存在一个名为UPGRADE-4.0.md. 4.0开发还没开始，但是这个文件已经存在了。什么原因？

我在git树中遇到了意外情况。我已经从master创建了一个分支，但是当我在新分支上执行提交时，好像这些提交与master在同一代码行中进行...

如您所见，在最左侧是master（深蓝色）的代码行，在顶部，我们可以看到Sprint_15，它是master的分支，似乎在同一行上有提交...不知道为什么会这样。由于功能已合并到Sprint_15中而不是母版中，因此我希望代码会换行，

我的想法是，通过将Sprint_14和Sprint_15合并在一起，这在历史上做得很时髦，但是我不确定为什么。

我对git还是很陌生，因此它的某些基础仍然让我感到困惑。

我想为我们的新 Web 应用程序推荐 Gitflow。我们有 QA 环境，在发布前完成产品验收测试。我想知道应该将哪个分支部署到 QA - 发布分支还是主分支？哪个分支应该部署到生产？如果我们部署并测试发布分支，然后将其合并回 master 谁来测试 master？

当我在 master 和开发分支上有拉取请求分支策略时，如何在 Azure Repos 上实现 Git Flow？我很想让它发挥作用，但我不知道最佳实践。我目前在 Azure Git 存储库上设置了 gitflow，但在 master 上有 PR 分支策略。如果由于没有创建 PR 而推送到 master 失败，我该如何完成发布或修补程序分支。同样，如果我的开发分支在 AzureDevOps 存储库中有 PR 分支策略，我无法使用“git flow feature ...finish”“完成”我的功能，因为推送开发分支会失败？

我已经尝试过在开发（用于完成功能）和主控（用于发布合并和/或修补程序合并）上没有 PR 分支策略。

我试图查阅 AzureDevOps 的分支策略指南，但它没有提及 GitFlow https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure -devops#管理发布

该指南更直接地针对新功能从“master”创建功能分支并与 PR 合并，然后对于版本，它建议您从 master 创建发布和修补程序分支，这些分支永远不会合并回来。

预期：能够完成功能并通过 PR 合并回开发 能够同时完成发布和修补程序并合并回 master 并通过 PR 进行开发。

实际：完成一个功能。尝试合并到具有 PR 分支策略的任何分支（master、develop）时，发布或修补程序失败

我是 git 新手。

我遵循 git-flow 分支模型，所以我有分支 master 和 develop ，每次我需要一个新功能时，我都会打开一个新的功能分支。

我对功能分支中的几个文件进行了一些更改，并暂存了它们，但尚未提交，因为这些更改尚未经过测试：

$ git status
On branch feature/ParamConfigFaultCollection
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   IOLSE_User_Objs.h
        modified:   data.c

现在我需要在分支开发上工作，所以我切换到它，我使用 Sourcetree 作为 git GUI 并双击开发：

并且我希望开发人员看不到功能分支上隐藏文件中的更改，但似乎这些更改也存在于开发中：

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   IOLSE_User_Objs.h
        modified:   data.c

我究竟做错了什么？

在GIT流分支模型(如在描述这个交)指出一个应该创建release由分支的分支develop.

这可以很好地工作,但据我所知,也可能导致无意识的更改,使其成为release分支.假设您正在处理功能A,B和C,并将它们合并到develop.几天后,功能A和B变得足够稳定以便释放,但功能C仍然落后.您不希望功能A和B因功能C而延迟,并且您无法恢复功能C,develop因为其他开发人员依赖它.

作为解决这个我认为支化release的关闭master,然后将其合并特征A和C.

(我仍然不是100%熟悉git,所以下面的一些陈述可能完全错误,所以请澄清.)

这个问题是因为功能A和B与功能C一起开发,并且开发人员保持他们的功能分支与develop分支最新,一些C的代码最终在功能分支A和B.如果我合并这些分支在release分支上然后我可能最终得到C中的代码.我仍然习惯于变基的想法,但如果我尝试使用rebase而不是合并,我会得到所有这些冲突.也许我可以选择提交或类似的东西,但每次我想在发布分支上放置一些代码时,这似乎太复杂了.

如果有一个简单的方法可以实现这一点,你们能让我知道吗？

如果开发人员针对不同的功能在不同的分支上工作,我理解他们可以从功能分支中提供QA构建,一旦测试它就可以与"develop"合并.但是,如果QA团队相当大并且可以同时测试多个功能,那么如何为它们提供包含驻留在不同分支中的功能的构建？