标签: git-flow

我现在使用 git 很长时间了。但我从来没有以协作的方式使用过它。我目前正在建立一个新项目并计划很多事情，其中​​包括：如何 git？

好的，所以我已经开始阅读了一些，这是一个简单的决定：很好，我们将使用功能分支工作流。棒极了。

下一个问题：合并还是公关？合并！美好的。

最后一个问题：FF还是非FF？
在功能分支工作流中合并 FF 甚至有意义吗？合并FF时感觉整个功能分支故事都是浪费。
使用我没有考虑过的非 FF 有什么缺点吗？

在阅读“平面”（如git log --oneline） git log 时，我认为这些合并提交没什么大不了的。但是当使用一些更花哨的git log --format ...东西时，当日志看起来像这样时，它可能会很有帮助。至少在我看来。

*   e3f667e (HEAD, origin/master, master) Merge branch 'issue#1702'
|\
| * ec359fe (origin/issue#1702, issue#1702) 1702: two
| * 45a63b3 1702: two
* |   97bbec7 Merge branch 'issue#1701'
|\ \
| |/
|/|
| * f959cc9 (origin/issue#1701, issue#1701) 1701: two
| * 9217d3c 1701: one
|/
*   6c934ea Merge branch 'issue#1606'
|\
| * …

我希望使用 GitLens 来管理 git-flow 结构。GitLens 是否集成了此 Git 扩展？或者还有其他扩展吗？

我在 Windows 上使用 Git flow。当我通过以下方式初始化我的存储库时

git flow init -d 

我得到以下输出

Which branch should be used for bringing forth production releases?
- develop
- master
 Branch name for production releases: [master]

Which branch should be used for integration of the "next release"?
  - develop
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? []
Bugfix branches? []
Release branches? []
Hotfix branches? []
Support branches? []
Version tag prefix? []

可以看出，默认前缀为空。谁能告诉我这些前缀是在哪个配置文件中设置的？

问题是我正在使用 PowerShell 脚本克隆多个存储库并通过 …

我是 git-flow 的新手。想知道这三个主题实际上是如何工作的以及它们之间的区别吗？

在功能上，我是这样开始的：

git flow feature start features_name

这是很重要的finish它后start，然后publish这些功能？

我在发布的时候发现，它从GitHub分支上消失了，但是为什么呢？

我认为关于 git-flow 的主题很少，这些是主要的：

+ Feature
+ Release
+ Hotfix

我正在尝试使用GitVersion的+semver:patch命令来更改我的补丁版本号，但它没有按我预期的方式工作。

我的master分支上有一个标签“2.2.0”。我在我的开发分支上做出了以下承诺：

b5d9f141  (HEAD -> develop, origin/develop) +semver:patch
75122489  Added unit test. +semver:patch
3b4e7eef  (tag: 2.2.0, origin/master, master) Merge branch 'release/2.2.0'

我正在关注GitFlow。在最近两次提交之后，我希望我的版本报告为 2.3.2，但 GitVersion 仍然将其报告为 2.3.0。

"主要次要补丁":"2.3.0"

它是如何+semver工作的，有没有什么方法可以按照我想要的方式仅使用提交消息来提高活动版本号（即无需手动标记）？

我过去工作过的大多数团队在使用 Git 时都遵循相同的工作流程（有一些微小的变化）：

1. 拉动develop树枝 ( git checkout develop)
2. 从中创建一个新的功能分支 ( git checkout -b feature/XYZ-123)
3. 做你的工作
4. 当您准备好创建 PR 时，添加并提交更改 ( git add . && git commit -m "some commit message")，然后返回develop并拉取它 ( git checkout develop && git pull)
5. 切换回您的功能分支并合并develop到其中 ( git checkout feature/XYZ-123 && git merge develop)
6. 最后按下 ( git push -u origin feature/XYZ-123) 并创建 PR

我们将其称为“合并方法”。好处是，develop自您创建分支以来所做的任何更改现在都会合并到您的分支中。因此，当您创建 PR 时，不存在合并冲突，develop并且代码审阅者可以看到您的分支和develop.

我现在正在一个团队中工作，该团队在合并步骤之前具有类似的流程，但随后develop他们没有合并到我的功能分支中，而是要求从 …

我即将使用本地 Azure DevOps 环境将我的发布分支合并到 master 中。当我去完成拉取请求时，我会得到四种合并类型选项：

• 合并（无快进）
• 壁球提交
• 变基和快进
• 半线性合并

我更愿意保持所有历史记录完好无损，确保最大限度地减少修补程序或未来发布分支的问题。我正在尝试遵循 git-flow 流程。

通常我会使用带快进的 Rebase，但是（当我选择“Squash”时）屏幕上会显示一条消息：

“如果您计划在未来的工作中使用 source 分支，请考虑使用非快进合并”。

这意味着什么？快进的 Rebase 不安全吗？

谢谢你的建议。

我们正在使用git flow.这是流程.

1. git flow功能启动myfeat
2. git commit -a
3. git checkout开发
4. git pull
5. git flow功能checkout myfeat
6. git flow功能rebase myfeat
7. git flow功能完成了myfeat
8. git push

错误:

Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 820 bytes, done.
Total 8 (delta 6), reused 0 (delta 0)
To git@github.com:blah/blah.git
   d675b35..d35f160  develop -> develop
 ! [rejected]        master -> master (non-fast-forward)

为什么它告诉我,当我推动开发时它拒绝主人(如果你不熟悉git流程,开发是一个远程跟踪分支)

我正在运行git版本2.3.6和git flow版本1.8.0,当我运行命令时,git flow feature checkout <branch>我收到消息:

The command 'git flow feature checkout/co' will be deprecated per version 2.0.0

有谁知道为什么这会被弃用和/或我应该使用什么呢？

当我尝试从我创建的功能分支切换回master时使用SourceTree我得到一个错误:

Updating the following directories would lose untracked files in it

我想切换回master来制作另一个功能分支,但我无法这样做.