1回答
基于合并分支的构建版本
、、、、
我想实现NuGet包的自动语义版本控制作为VSTS构建步骤(实际上是在cakebuild步骤中)。问题是，虽然获得正在执行的分支构建很容易，但我不知道如何获得关于哪个分支被合并到主分支的信息(修补版本的热修复分支，或者次要版本的带有新功能的开发分支) (buildSystem.TFBuild.
浏览 15提问于2018-02-27得票数 1
回答已采纳
4回答
在一个持续开发的web项目(不是产品)中，我们目前有以下的分支策略，大致基于git流：主分支:将发布的版本/发布版本修补程序分支:发布版本中的紧急修补程序每次更新都会生成一个发布候选版本，并将其部署到暂存系统。在手动批准后，将发布候选产品部署到生产中。
特性分
浏览 0提问于2017-03-02得票数 23
回答已采纳
我们遵循基于主干的开发方法，当一个特性准备就绪时，我们将其合并到master并创建具有语义版本的发布分支，因此我们可以完全控制主要/次要/补丁版本控制。版本/1.0.0。我们在构建步骤中运行gitversion，该步骤考虑分支名称中提供的版本控制并基于它创建版本(默认的gitversion
浏览 5提问于2019-09-16得票数 1
1回答
我试图通过Python项目的语义版本化来理解基于主干的开发。有人有过采用基于主干的包语义版本化开发的经验吗？我将语义版本存储在version.py:__version__中
在主干(主) version.py:__version__上，1.0.0-SNAPSHOT是D2，在CI服务器上，每个构建都会附加该版本号更改日志可以在发布分支上完成，但这意味着必须将其合并回主干(main)。
浏览 0提问于2019-04-11得票数 2
回答已采纳
3回答
我们在使用Azure DevOps服务的项目中遵循gitflow模型。我有一个经典的基于编辑器的管道，它构建了Dev和Release/R1.0分支。我将设置一个基于经典编辑器的管道，它将在版本结束时合并Release/R1.0分支后，从主分支构建我的release R.10。假设这个经典的基于</em
浏览 0提问于2020-01-30得票数 1
我读了很多关于版本控制系统的文章，比如SVN，Git和各种分支模型(基于功能，基于发布等)，但它们似乎都不符合我们的项目需求。
我们(团队)将开发一个框架，该框架将作为不同应用程序的核心。因此，将有一个框架和多个不同的应用程序构建在该框架上。每个应用程序都有通常的项目周期:构建、发布……框架本身不会发布，但可能标记了不同的版本。在应用程序的开发过
浏览 3提问于2011-12-31得票数 1
我刚刚开始使用github，我正在尝试找出在GitHub中维护多个版本的最好方法。我读到过你绝对不应该为不同的版本创建分支，因为你不会合并它们。 我在哪里存储这些不同的版本？我再也不会接触它们了，但仍然想把它们保存在我的存储库中？
浏览 155提问于2021-11-05得票数 0
1回答
我们正在使用codepipeline和bitbucket云的代码构建作为源存储库。
我们不会经常发布，我们的版本在发布之前受到严格的监管(首先是由客户在准备环境中进行评审)，等等。对于develop、staging和production环境，我们有单独的分支，因为代码管道不支持基于标记的版本，而且特性分支将经常合并到开发分支中。开发分支将不频繁地
浏览 1提问于2021-10-18得票数 0
我有几个构建配置，它们成功地创建了NuGet包并将它们发布到TFS中的提要。有没有一种方法可以设置构建配置，以基于用于构建<
浏览 0提问于2017-09-20得票数 1
对于一个项目，假设我有一些发布分支： release/1.2release/1.0 这些发布分支基于次要版本。因为它们一直被支持，所以它们中的每一个都将处于不同的补丁版本，存储在某个构建配置文件中(在我的例子中是gradle)。然后我想将这个分支合并到下两个分支，以传播修复。一般来说，这将非常顺利地工作。但是，在修复 我还希望
浏览 35提问于2015-07-29得票数 2
回答已采纳
2回答
夜间构建、GitFlow和PR
、、、、
我的客户决定拥有一个基于develop分支的自动夜间构建。我们通常创建一个feature分支(如果有必要的话，我们提供一个在该分支上手动编译的版本)，当工作完成时，我们发出一个拉请求(对develop分支)
客户抱怨说，夜间构建没有包含任何关于仍在进行中的特性的内容，但是我们不希望在没有拉请求的情况下合并代码。有什么聪明
浏览 0提问于2021-12-23得票数 -1
在软件开发期间，关闭版本/票务系统中的票/问题的最佳实践(以及为什么)是什么？哪一种解决方案更好：
A.在特性
浏览 0提问于2018-12-05得票数 1
目前我们使用SVN进行版本控制。我们创建一个分支，并在分支中开发所有新功能，测试人员也使用分支版本构建进行测试。简而言之，Live build总是从主干构建。
我知道这不是一个好<
浏览 3提问于2015-07-21得票数 0
1回答
我开发了两个版本的同一应用程序:免费和付费一个。这两个分支都是基于Git中的“主”分支。有时，我将主分支合并为“免费”和“付费”分支，以保持它们的最新。但是对于免费和付费的应用程序来说，有必要有不同的包名。它不是混淆了Git提交历史，还是应该在应用程序构建之前临时重命名包名，并在git中保留原始包名？
浏览 1提问于2016-03-24得票数 3
回答已采纳
1回答
这些分支永远不会合并到master中，因为它们是对基本游戏的可选修改。当发布一个新版本的modpack时，我会基于modpack-v1.2.3创建一个新的分支master，然后将所有的mods合并到它上来创建modpack版本。\其中分支a和b直接从master构建，而c
浏览 0提问于2021-08-23得票数 1
1回答
假设我们已经决定遵循“基于版本”的分支策略，因此我们将为每个版本创建一个分支，并且可以从这些分支中添加维护更新作为子分支。我们是否：首先创建发布分支，然后在分支稳定时才合并到主干中？我发现前者更容易处理(减少必要的合并)，特
浏览 0提问于2014-08-08得票数 2
回答已采纳
1回答
我正在尝试自动化一个构建模式，该模式将主要通过环境和分支来跟踪特定构建的升级。所以，我的源代码如下所示：现在，我已经在DEV分支中建立了连续的构建。基本上，对于每一次签入，都会计划构建并执行单元测试。我希望能够将从DEV到QA的任何一组签入合并，并使其自动触发QA构建。
浏览 0提问于2012-04-19得票数 2
回答已采纳
TeamCity安装程序：
我还没有弄清楚如何让一个VCS连接到CenterProj回购，然后触发基于提交/合并到各自分支的
浏览 15提问于2016-07-08得票数 0
回答已采纳
我们有基于TFS环境的分支机构。我们有开发主版本和热修复。
我们的octopus生命周期要求代码首先部署到开发环境中，然后部署到测试环境中，然后部署到登台环境中，然后部署到生产环境中。我们在开发tfs分支中进行开发，我们有一个Teamcity构建，目标是开发分支，然后触发octopus deploy部署到开发环境中。但一旦开发测试完成，我们需要将代码合并到主分支，并将代码从主分支部署到测试环境，然后
浏览 2提问于2016-10-27得票数 0
扫码
添加站长 进交流群
领取专属 10元无门槛券
手把手带您无忧上云
相关资讯
热门标签
云服务器
ICP备案
腾讯会议
云直播
对象存储活动推荐
腾讯云开发者
