我想知道是否可以同时在多个功能分支上处理 Maven 项目，并避免不断覆盖 Nexus 中其他功能分支产生的工件。
我正在一个跨国项目中工作，该项目使用 gitflow 工作流来开发多个组件（30+）。每个组件都有一个 git 存储库，因此 gitflow 工作流应用于每个组件。所以每个组件都有一个开发和几个功能分支。通常，每个组件产生至少一种由其 GAV 识别的人工制品。
假设我们有组件 A（带有特征分支 feature/A-foo 和 feature/A-bar）和 B（带有特征分支 feature/B-foo）
Component A:
A:develop
A:feature/A-foo
A:feature/A-bar
Component B:
B:develop
B:feature/B-foo
A:feature/A-foo 和 B:feature/B-foo 工作在同一个主题上，需要交换快照版本以测试它们的交互（例如客户端/服务器功能）。组件 A 和 B 只能通过 Nexus 交换工件（无法访问其他组件的源代码）。因此，A:feature/A-foo 必须部署其快照工件以使其可用于 B:feature/B-foo，反之亦然。
但是当 A:feature/A-bar（适用于完全不同的主题）之后部署时，由于相同的 GAV 和更新的时间戳，它会“覆盖”Nexus 中的快照工件，并且 B:feature/B-foo 将导入在其下一个构建中出现错误的工件。
一种解决方案是使用功能名称（例如 foo）扩展 GAV：
some.company.componentA-1.2.3-foo.jar
some.company.componentA-1.2.3-bar.jar
some.company.componentB-3.2.1-foo.jar
通过这种方式，您可以避免 A:feature/A-foo 覆盖 A:feature/B-bar 的工件，因为它们具有不同的 GAV。但这非常容易出错（在分支时重命名 GAV，再次合并到开发时将其重命名；如果有人忘记重命名，它会搞乱构建）。
有没有更好的解决办法？还是应该禁止在功能分支上部署？
我已经启动了一个新的git存储库git flow,完成了一两次提交并推送.
当我在新目录中克隆存储库并运行git flow命令时,我收到错误:
Fatal: Not a gitflow-enabled repo yet. Please run 'git flow init' first.
出错的原因是.git/config新克隆目录中的文件不包含git flow配置.
如何推送/共享配置,以便任何克隆存储库都具有正确的配置？
我很难理解Git流如何与Github一起工作.
Github允许集成更改的fork/pull请求模型,其中整个上游repo及其所有分支都被复制到fork中.
然后使用git flow,我将分支dev开发分支说然后完成后我的更改将合并到我的fork的dev分支而不是上游.因此,当一个pull请求返回到上游repo时,它会将dev(fork)合并到dev(上游),但这会丢失我所存在的所有功能分支等知识.
因此,为了让Git流正常工作,我是否需要停止分配repo并直接在上游repo中创建功能分支？
所以fork/pull应该与git flow分开吗？
前几天我读了https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow,我有一个问题.
如果在项目中使用功能分支或Gitflow分支工作流:是否存在用户将功能分支作为跟踪功能分支推送到源的选项发出拉取请求,并且只有项目的维护者才能合并跟踪功能分支进入主(功能分支工作流)或开发(Gitlow分支工作流)？
换句话说:是否可以将分支分配给用户,以便如果不想让事情过于复杂但仍然保证代码审查能够保证master/develop分支免受新手的影响,那么人们就不会立即需要分岔工作流程？
我们正在采用该git-flow方法，并开始在我们公司使用 GitHub 来组织我们的工作并帮助协作。
但我们的行业有相当长的开发周期（正式发布之间有很多年），所以我们可能develop一次会在分支上呆上好几个月。然而，只有当您推送到 时master，才会触发一些不错的 GitHub 功能：
所以我们不能使用 GitHub 自动跟踪进度，直到几个月后，项目就基本完成了。我相信如果我创建develop默认分支，这个问题就会消失。
但还会出现其他问题吗？就像，我仍然想master成为头版。我担心来到该项目的人只会看到最新的开发版本，可能没有错误检查等。
我们在当前项目中致力于 git-flow 并同时添加多个功能。我们只有一个 QA 环境，一次只能容纳一个构建。如果有多个功能等待测试，并且我们的 QA 成员可以并行测试它们，我们需要（如此处回答）创建一个integration分支以上传到 QA 环境并进行测试。但是，我们发现该流程在该解决方案中出现了一些问题：
有没有更好的方法来并行测试多个功能？您有什么建议可以让流程变得更好吗？
为了确保所有代码最终都通过拉取请求代码审查，我们已经开始按照git-flow样式为特性和 bug 分支创建分支。
唯一的问题是，一旦在发布分支中发现错误，我们通常必须从发布分支中创建一个分支，以便将拉取请求返回到发布分支。但是在修复发布分支的错误时，似乎没有明显的 git-flow 过程来处理发布分支之外的分支。
修复发布分支错误和代码审查的 git-flow 流程是什么？
您是否应该修复开发中的错误并创建新的发布分支？分支发布分支仍然有效的 git-flow 吗？处理发布分支错误修复的拉取请求代码审查的最佳方法是什么？
在 gitflow 中，所有发布分支最终都是
但我们为什么不只是
在修补程序的情况下，我们可以
我在我的项目中按照gitflow工作流程使用git/hub和github，我想知道是否有一种简单的方法可以避免进入 github 合并和关闭我的拉取请求。
我当时正在关注的工作流就是这个。
git checkout -b my-feature-123 develop
git add .
git commit -m "my changes"
git push origin my-feature-123
hub pull-request -m "my changes" -b develop
#enter guthub and merge PR
#run deployment
git checkout develop
git pull origin develop # everything up-to-date
所以我想用命令行合并命令替换#enterguthub 和合并 PR部分，直到现在似乎没有任何效果。
我正在尝试设置GitVersion来处理我们项目的语义版本控制 (GitFlow)，但它并没有像我预期的那样自动递增。我也在努力阅读项目的文档，这不是最容易理解的。
基本上我们希望建立一个具有 Major.Minor.Patch 约定的版本控制系统，我们手动增加 Major，当一个 release 分支合并到 master 时自动增加 Minor，当一个 feature 分支合并到 develop 时自动增加 Patch。
这是我的当前 GitVersion.yml
mode: ContinuousDeployment
branches:
feature:
increment: Patch
regex: feature?[/-]
release:
increment: Minor
regex: release?[/-]
develop:
regex: develop$
master:
regex: master$
ignore:
sha: []
同样为了测试它，我写了一个小的 ruby 脚本来加速这个乏味的过程。我包含它只是为了确保我以预期的方式使用 GitVersion 和 GitFlow。
require "git"
def new_feature_branch i
g = Git.open(Dir.pwd)
branch_name = "feature/number-#{i}"
g.checkout("develop")
g.branch(branch_name).checkout
open('README.md', 'a') do |f|
f.puts "\r#{i}"
end
g.add("README.md")
g.commit("##{i}")
g.branch("develop").checkout
g.merge(branch_name)
g.branch(branch_name).delete
print(`gitversion`)
end
new_feature_branch(ARGV[0])
输出 gitversion
{
"Major":1, …