标签: git-flow

我试图使用说明安装gitflow在github上自述一拉:wget的-q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo sh

并且它默默地失败了...只是回到提示.有任何想法吗？

我喜欢让我的功能分支与开发保持同步.经常做"git merge --no-ff develop"有什么不对吗？然后在最后,运行"git flow feature finish feature1".这些功能分支是共享的(这意味着其他人可能正在使用它,或者我正在家里的计算机上开发它),主要是因为我喜欢知道它们在其他地方备份.如果他们没有被分享,是否会优先考虑变基？

或者,最好不要让你的功能分支保持最新状态,最后将所有功能合并在一起？

在我们公司,我们正在从SvN转移到Git(是的,迟到总比没有好).有了这个,我们也尝试简化版本控制过程.为此,我发现了一篇有趣的文章:Vincent Driessen成功的Git分支模型.

据我所知,开发人员假设是线性版本.要明确:

v1.0.0 --> v1.0.1 --> v1.0.2 --> v1.1.0 --> v1.1.1 etc

未提及对旧版本的支持.例如:我们支持最多三个主要版本,因为一些客户端不想升级.所以想象我们有以下版本:

v7.0.0 --> v8.0.0 --> v9.0.0 --> v10.0.0

当有发现了一个严重错误v8.0.0 后释放v9.0.0,我们取出一个标签v8.0.0,修正错误,然后把它合并到develop和master分支机构.合并到master获取标记v8.0.1.

由于两件事,我似乎有些奇怪:

1. 该master时间表的样子v7.0.0 --> v8.0.0 --> v9.0.0 --> v8.0.1 --> v10.0.0.我完全知道这是可能的,但是它也可以接受吗？
2. 当我合并hotfix到master(并且master在那一刻v9.0.0)并用它标记时v8.0.1,我是否也获得介于v8.0.0和之间的功能v9.0.0？

提前致谢!

我目前正在试图找出,如何在一个场景中使用git flow进行发布管理,我有一个git存储库,其中包含两个解决方案中的大约15个项目以及数据库的脚本.

每个解决方案基本上包含一个项目,该项目将生成可执行文件,10个项目包含两个解决方案(如DAL,SAP访问包装器等)使用的基本功能.
解决方案一是具有用户UI的应用程序.
解决方案二是Windows服务.
两个解决方案和数据库的发布不同步.这意味着通常只有三分之二的矿石被释放.这导致不同的版本号.例如,UI很频繁地发布,服务很少发布.数据库介于两者之间.因此,UI可以具有2.1.15版本,服务2.1.1和数据库2.1.5.

现在,如何处理共享项目？他们应该使用UI的版本号还是服务的版本号？
我如何解释其中一个共享项目的更改不会自动触发两个解决方案的发布？这意味着同时,生产环境包含相同项目的两个不同版本.这在某种程度上需要反映在存储库中.

我有点迷失在这里,任何建议,经验等将不胜感激.
我可以自由地以任何方式构建存储库和代码库,如果有帮助,我可以创建其他存储库.

我正在使用git- repo使用git-flow分支模型.我把它推到了一个中央存储库.加入该项目的新开发人员如何克隆它？

克隆存储库仅提供master分支.新开发人员如何获得develop分支机构以及他选择的一些功能分支？

在使用git-flow模型使用git进行发行时，我将存储库切换为指向master，tag中的最新提交，然后从tag中进行构建。好的做法是将所有存储库子模块的更改合并到master中，并使其指向master（即master中的最新提交），还是将所有子模块的提交保持不变就足够了吗？

在我们的项目中,我们按照http://nvie.com/posts/a-successful-git-branching-model/关注回购模型 .

到目前为止,我一直在开发分支中添加功能,但是现在我们的项目已经创建了一个发布分支,我需要在该发布分支上添加一个修复程序.根据我的阅读,添加修补程序将修复程序添加到我的主分支而不是发布分支.那么如何在我的发布分支上添加修复？

gitflow符合我们的需求，而giversion似乎也符合gitflow。但是有一件事我还不完全了解。让我解释一下困扰我的事情。

1. 我们在开发分支上做了一些功能上的工作-所有软件包都标记为1.3.0-unstable.1、1.3.0-unstable.2，依此类推。
2. 每个软件包都将通过管道-开发，测试，测试，生产。
3. 因此，当开发人员准备就绪并且一切都很好时，根据gitflow我们启动了release分支。
4. 发行时不需要做任何更改，我们会立即完成它-发行分支已合并到主版本和开发中。
5. 构建服务器会再创建一个软件包1.3.0，该软件包已准备就绪。

如何实现一次构建，在这里部署多个？根据所有规则，我们需要将1.3.0-unstable.x升级到prod env，导致此软件包确实在dev和test中进行了测试，但是该版本对于prod看起来有点奇怪，不是吗？当来自master分支的1.3.0从未部署到任何地方时。

问题是这样的：在git flow模型中，我应该从master的merge提交构建到发布吗？

答案并不十分令人满意：

1. 我们在与主人合并时不做-ff
2. 还是一个不同的包裹

在哪个分支中应该根据git-flow标记beta版本？

我们有一个发布分支准备版本x.0.0,但在发布之前x.0.0我们想发布一个beta(x.0.0-beta).master在这种情况下是否应合并发布分支,然后进行标记x.0.0-beta,master或者是否应在发布分支上标记此beta版本x.0.0？

附加问题:候选发布版(x.0.0-rc1)的程序与beta相同吗？

我正在努力将gitflow设置为允许创建多个修补程序...我已经运行了以下命令：

git config --add gitflow.multi-hotfix true
git config --global gitflow.multi-hotfix true

当我跑步时：

git config --list
git config --global --list

我可以看到它设置正确

gitflow.multi-hotfix=true

但是仍然...每次我尝试创建新的修复程序时，都会要求我首先完成当前的修复程序...

我的Mac Book Pro正在运行Mojave 10.14.1（18B75）

另一个可能有所帮助的细节是，我注意到，每次我运行添加命令时，配置中的另一行都将添加完全相同的信息gitflow.multi-hotfix = true。因此，我尝试清除所有设置并从头开始并运行以下命令：

git config --unset gitflow.multi-hotfix
git config --unset-all gitflow.multi-hotfix

但是，无论我尝试运行这些命令多少次，都保留了允许多个修复程序的行，但是实际上我无法创建多个修复程序分支。