在GitFlow工作流程中是否允许直接提交到主分支？
在GitFlow工作流程中，不允许直接提交到主分支。GitFlow是一种流行的代码管理模型，它将代码库分为多个分支，包括主分支（master）、开发分支（develop）、功能分支（feature）、发布分支（release）和修复分支（hotfix）等。
在GitFlow中，主分支（master）用于存放稳定的、可发布的代码版本。开发人员应该通过创建功能分支（feature）来开发新功能或解决问题，并在功能开发完成后将其合并到开发分支（develop）。开发分支（develop）是集成所有功能的分支，用于进行整体的开发和测试。
当开发分支（develop）上的功能开发完成并经过测试后，可以创建发布分支（release）进行发布前的准备工作，如版本号更新、文档编写等。发布分支（release）经过测试后，可以合并到主分支（master）进行正式发布。
修复分支（hotfix）用于紧急修复主分支（master）上的bug。当主分支（master）上出现bug时，应该创建修复分支（hotfix）进行修复，并将修复后的代码合并到主分支（master）和开发分支（develop）。
因此，在GitFlow工作流程中，直接提交到主分支是不被允许的。开发人员应该按照规定的分支流程进行代码的提交和合并，以确保代码的稳定性和可追溯性。
腾讯云相关产品推荐：
- 代码托管：腾讯云开发者工具（https://cloud.tencent.com/product/codetools）
- 持续集成与持续部署：腾讯云DevOps（https://cloud.tencent.com/product/devops）
- 代码质量管理：腾讯云CodeQuality（https://cloud.tencent.com/product/codequality）
- 代码审查：腾讯云CodeReview（https://cloud.tencent.com/product/codereview）
相关·内容
1回答
我正在做一个项目，我们正在使用gitflow工作流。基本上，我只是刚开始使用gitflow工作流，我只有一个问题。
存储库中有两个分支，即主分支和开发分支。我检查了开发远程分支，因为这个分支将包含项目的完整历史记录。
现在我想从团队获得最新的更新，我应该从主分支中提取它吗？还是在开发部门？
另一件事，如果我推动我的改变，我是否应该推动我的变化来源/主人？还是起源发展？
顺便说一句，我们所有的开发人员都远程检查了开发分支。使用git签出-b开发源/开发命令
忍受我刚开始的git工作流程。谢谢。
浏览 2提问于2020-03-28得票数 2
回答已采纳
1回答
我们移动到Gitflow工作流与TFS和正在使用雅各布Ehn插件在视觉工作室。在我们的发现中，我们已经决定了一个发布分支是额外的，并且增加了复杂性。我们可以在不创建发布分支的情况下实现Gitflow吗？我们将在开发分支本身上执行所有的测试，然后将其合并到主分支中，我们将从主分支进行构建。
浏览 0提问于2019-11-22得票数 0
回答已采纳
在GitFlow工作流中是否允许直接提交到主分支，或者主分支是否应该只包含来自其他分支(开发分支、热修复分支、版本分支和功能分支)的合并提交？
浏览 19提问于2019-05-08得票数 2
回答已采纳
1回答
在sprint开发期间，你是如何处理git流的？
我发现在开发期间，一些sprint任务是相互依赖的，所以不可能从master分支分支，因为它太早了，而且需要开发分支的功能才能继续在sprint上工作。
目前，我在sprint期间从开发分支，并对我正在从开发分支工作的分支进行重新基址。我发现使用这种方式，master仍然是稳定的，我们避免在分支之间进行大量的合并，以使项目达到继续开发所需的状态。
我认为这一部分到处都被遗漏了，我找不到一种有文档记录的方法来避免所有这些麻烦。
在开发期间，热修复不是master的分支，因为我们修复的功能可能是由功能冲突引起的问题，所以我们从开发中创建热修复。一旦
浏览 0提问于2017-02-28得票数 0
2回答
最近，我在Git中发现了工作流的三个概念：
GitFlow
GitHub流
GitLab流
我读过关于它的文章，但是我不太理解GitLab流。
简而言之。
GitFlow
我们有一个主营分公司作为生产部门。此外，我们还有一个开发分支，每个开发人员都可以在这里合并他的特性。有时，我们创建一个发布分支来在生产中部署我们的特性。如果发布分支中有错误，那么修复它并将更改拖到开发分支中。如果我们在生产中有一个关键的错误，创建新的修复分支，修复错误并将分支与生产合并(主)和开发分支。
如果我们很少发表我们的工作成果，这种方法就能很好地工作。(可能每两周一次)。
GitHub
浏览 3提问于2016-10-07得票数 57
回答已采纳
1回答
首先，让我先说一下我对GitHub流的理解，然后再问这个问题：
在GitHub流中，我们有一个main分支，feature/topic/bugfix/whatever分支从这个主要分支分支。一旦准备好，这个主题分支就会被合并到主分支中。在开发分支和主分支之间进行这种分离是非常重要的，以便使main始终指向良好的待办提交。通常，对main的合并提交将使用版本号进行标记。
所以我的问题是:为什么重要的是让主分支总是指向一个很好的提交？为什么我们不能依靠合并提交上的标记来指向就绪/稳定的版本提交呢？指向最新的好提交的git引用的附加值是多少？
编辑
正如标题所说，我的问题是关于GitHub流的。Gi
浏览 0提问于2021-07-29得票数 0
我只是和git和git流成了好朋友，并认为我已经准备好把我们的关系提升到一个新的水平。
假设我已经创建了一个git，它在显示有趣的猫图片方面做得非常出色。我使用git流来保持控件的所有特性和修补程序。
然后，我得到了一个可怕的想法，做一个相同的回购与有趣的狗图片。当我想要跨平台特性或修补程序时，什么是最好的git方法来分支、更改图片、继续使用git流并保持它们的同步？
我是否需要将两个“版本”分开，这样我就可以
主回购
猫回购
狗回购
然后工作在主回购和从其他人。
还是我只是把它分开
猫回购
狗回购
在每个地方都有一些git流和一些合并？
还是有更好的选择？
浏览 0提问于2018-02-12得票数 0
我们目前支持两种分支策略: gitflow和基于主干的dev。我的公司开始使用我所称的混合(未正确阅读IMO)的gitflow模型，但公司的方向是转向基于主干的开发。我喜欢这个方向，但是最好的方法是什么呢？我正在寻找最佳实践，但找不到这个话题在网上讨论。
我们使用GitHub进行单片机。
在我们的混合gitflow分支策略中，我们的git项目目前没有正确地使用gitflow“主”分支。
我们是否应该：
projectsDelete 在GitHub中创建新的git项目，并将基于gitflow的git项目的旧的gitflow git项目块访问到基于gitflow的git项目中的“主”分支在基于gi
浏览 4提问于2022-01-19得票数 1
2回答
我已经创建了一个裸的git存储库("Core")，它是从先前存在的使用gitflow的回购(生产)中克隆出来的。我再次将裸回购复制到非裸回购(" Staged ")中，然后在Staged中重新初始化git流(因为当我克隆裸回购时似乎没有遇到gitflow？)
但我注意到了一些奇怪的事情。假设我在开发分支的阶段回购中，并编辑一个文本文件(test.txt)。我运行git status，它告诉我test.txt已经被修改了。太棒了。
现在，我不提交或合并，但是我使用git checkout master签出主服务器，然后再次运行git status，它说test.t
浏览 0提问于2012-03-22得票数 2
回答已采纳
1回答
我读过这两篇关于git工作流的论文：
据我所知，这种模式很简单：
我们有一个开发分支(前主干)，
我们创建特性分支，以便在准备就绪时合并到开发中，
在实现所有特性时，我们将发布分支，并在一切就绪时将发布分支合并为主(并且只为完整性而开发)。
最后，我们标记主分支。
问题是：
在GitWorkflow的其他一些例子中，与这个模型有什么显著的区别吗？
如果不是，这个模型和standart SVN开发有什么不同？为什么我们称之为"GitWorkflow“-我看不出与standart SVN开发方案有什么不同。我们也可以对SVN做同样的事情。
浏览 2提问于2014-11-12得票数 0
3回答
我正在研究使用git分支为每个开发人员设置一个门控提交工作流，如下所示：
每个开发人员都有自己的远程分支。
开发人员只向他们的远程分支推送。
C.I服务器分别构建每个分支，并在测试通过后合并到主服务器中。
开发人员通过将他们的分支拉到主人并将其重新定位来接收更改。
这是否一个合理的解决办法？我来自subversion，对git没有多少经验。
浏览 5提问于2012-12-10得票数 2
回答已采纳
在我的项目(Angular app)中，我们聚合了几个本地创建的发布到npm存储库的工件。 在我的应用程序的package.json中的“依赖项”部分，我有： "@k/e-lib": "^0.3.0",
"@k/et-lib": "^0.3.0",
"@k/http-interceptors": "^0.3.0",
"@k/notifications": "^0.3.0",
"@k/static-assets"
浏览 11提问于2019-01-16得票数 1
我有一个主分支，它代表生产服务器上的内容。我有一个开发分支(母版的子类)，它包含在刚才完成的sprint中完成的工作。master分支还包含与dev不同之后在生产服务器上完成的修复。
现在，我需要将两者合并起来，并创建一个名为UAT的新分支，在这里将对其进行生产准备测试。
我应该这么做吗？
合并母版> dev
branch uat from dev
merge uat > master (once uat is stable)
或
来自师父的分支
合并开发> uat
合并uat > master (一旦uat稳定)
在这两种情况下，开发人员都将继续开发开发分支。
浏览 2提问于2013-10-30得票数 0
回答已采纳
我们有一个由许多项目(数据、服务、模型等)组成的MVC/C#解决方案。它开始于保存在一个DEV分支中的TFS中。然后我们创建了一个主分支，并将这个项目放入了Main中。然后，我们从Main创建了一个新的DEV分支(task-1271)，以便我们可以执行一些增强功能。它被发布并合并回Main中。然后，我们创建了一个新的DEV分支(task-1316)，用于进一步的增强。我注意到数据项目指向先前DEV分支(task-1271)中的数据项目dll (debug/bin文件夹)。这导致了问题，因为当我运行迁移时，它不会获取模型更改。在经历了很大的压力之后，我们最终让它接受了迁移的模型更改。现在我不愿意
浏览 3提问于2020-05-04得票数 0
4回答
我们使用Gitflow作为git分支工作流程(通过TFS)。当发布成功时，我们执行以下操作
将请求从释放中拉到主
从发布中拉出请求进行开发
步骤1创建提交(合并的PR XXX:合并发布到主)
步骤2创建提交(合并PR YYY:合并发行版以开发)
当我看着我们的分支，它说，发展是一个承诺后，大师。这是因为提交(合并的PR: XXX)不在开发阶段。
是否正确的过程，仅仅创建另一个拉请求从主开发(即使没有变化的拉请求)？
我在标准的上没有看到这个
浏览 0提问于2018-08-09得票数 14
回答已采纳
前几天我读了，对此我有一个问题。
如果在项目中使用功能分支或Gitflow分支工作流:是否有一个选项可以让用户将功能分支作为跟踪功能分支推送到原点，发出拉取请求，并且只有项目的维护者才能将跟踪功能分支合并到主(功能分支工作流)或开发(Gitlow分支工作流)中？
换句话说:如果一个人不想让事情过于复杂，但仍然有保证的代码审查来保护主/开发分支不受菜鸟的影响，那么是否可以将分支分配给用户，这样就不需要立即使用分支工作流了？
浏览 1提问于2015-08-04得票数 6
假设我有以下工作流：
git checkout -b feature
# do some work
git add new_file
git commit -m "finished feature"
git checkout master
# integrate the feature changes into master
git rebase feature
当通过rebase/merge/rebase & squash将来自特性分支的更改集成到主服务器上时，将在主服务器上创建一个新的提交散列。是否有任何方法将特性分支上的提交散列映射到主分支上的新提交散列，反之亦然
浏览 7提问于2020-06-20得票数 1
回答已采纳
我们使用的GitFlow具有相当高的标准设置，其中包括：
代表最新产品的大师
发展代表正在进行的发展
修补程序/x下的多个修补程序，表示正在运行中的错误修复程序。
功能/x下的一些特性表示下一个版本的飞行中更大的功能。
我们在develop和master之间确实有一些不同，例如，我们希望master指向特定版本的NuGet依赖项，而develop指向这些依赖项的其他版本。
我们正在发现的是，当我们做一个GitFlow修补程序并完成该修补程序时，在它从hotfix分支合并到develop中时，它将尝试将这些配置差异从主服务器合并到develop中，即使这些配置更改不是作为
浏览 0提问于2018-04-24得票数 3
回答已采纳
1回答
假设您目前处于产品的第3版，所以您的下一个版本是4，但是您的特性要比发布周期长得多，例如，要到版本5才能准备好(可能会更长)。在git流中处理这个问题的最好方法是什么？在我看来，这种工作流程不允许这样的事情发生。下一个版本之后没有真正的版本表示法。
在我过去工作的地方，我们为下一个版本提供了一个分支，即上面的示例中的release/4。并且主分支将在该版本之后的下一个版本，即版本/5。特性将不在版本4中，但版本5将从主分支开发出来。释放/4的特性分支将被合并回版本/4(如果版本4已经发布，这将是一个更新)，然后合并到master (虽然如果忘记合并到master中也不是什么大问题，因为如果他们
浏览 3提问于2017-07-17得票数 1
回答已采纳
当我开始使用git时，我的工作流程基于Gitflow模型：。我认为主要的想法是保持提交到适当的分支；例如，主分支将只有从开发分支合并的提交……即标签... 0.1。0.2。图中的1.0。我不完全理解git是如何工作的，也不完全理解这个工作流程是如何运行的，但我是这么想的，尤其是因为该页面上的图形只显示了主分支上的这几个提交，而不是所有的开发分支。
我把我的repo推到Bitbucket上，当我在开发分支工作时一切都很顺利，但是当我完成开发时；并且当我推上master分支时，我发现Bitbucket中的master分支现在包含了我在开发分支上所做的所有提交，而我认为我只会包含最后一次提交(我合并
浏览 0提问于2013-03-24得票数 4
回答已采纳
1回答
在下面的Gitflow，
在发布分支成功地与主分支合并之后，发布分支也将与Develop分支合并，以更新发布主合并过程中给出的修复。
该版本的生产bug修复将通过分支发布分支和其他分支来实现。
问题是，如果发布分支合并到开发分支中，而不是删除，那么在开发人员完成他们的项目之后，开发分支就不能被删除。最后，开发分支将合并多个发布分支，但不会删除.在任何时候，如果没有开发人员在处理存储库，那么Git应该只有一个主分支和多个发布分支。
任何分支(例如Release)是否处于合并但不删除的状态？
浏览 0提问于2019-01-18得票数 0
1回答
对不起，我无法决定这个问题是否属于堆栈溢出，就在这里。
我想知道是否应该是一个好主意，或不经常提交，即使在我的情况下意味着提交不工作的代码。
我正在重构整个应用程序，以更改为一个新的库，如果我不经常提交，我很担心。
我有一个独立的分支来处理这个特性，以避免破坏主(使用Git)上的代码。
你能提供更好的解决方案吗?或者可能提供一些例子，为什么这会是好的/坏的，如果有替代品的话？
浏览 1提问于2015-11-09得票数 1
回答已采纳
1回答
我使用Git流已经有一段时间了，但是在最初的一周左右，我在主和樱桃中手工创建发布分支，将所需的提交选择到发布分支中，而不是从主服务器创建它们。
例如，如果我在开发分支中有提交abcd123 My commit message，那么我也会手动地将它选中到发布分支中，此时我可能已经修改或编辑了提交消息，所以发布分支(现在是主分支)包含了这个提交，但是包含了一个不同的哈希，例如dbca321 My adjusted commit message。
这里的问题是，当我从develop创建发行版时，它还包含了我不想在现阶段部署的提交，因此我根据master进行重基，并排除了我不想要的提交。然而，在重基之
浏览 0提问于2016-01-24得票数 1
2回答
我一直在git中寻找一个很好的分支模型，并且发现非常适合我们的开发环境。然而，一个悬而未决的问题是如何和在何处测试我们的版本。
发布分支听起来像是在发布之前运行所有回归测试的地方。但是，发布分支随后被合并到master中，进行标记，这就是最终用于生产的内容。如果从发布分支合并冲突到主服务器，会发生什么情况？听起来好像主人需要完全重新测试(这可能是昂贵的)。即使没有冲突，简单地将合并推向生产是安全的，还是需要运行额外的基本烟雾测试？
浏览 9提问于2015-11-03得票数 4
回答已采纳
我们使用的是GitFlow工作流。在将版本/*分支合并到主服务器之后，我们需要关闭分支。对于这一任务，我们需要提供删除访问，以拉请求合并，但在这种情况下，合并可以随时删除发布/*分支。
我们是否有任何选择来限制分支只有在它被合并到其他分支之后才更接近？
浏览 0提问于2019-11-08得票数 2
1回答
有多少管道用于基于干线的开发？
、、、、
对于基于的工作流，建议使用三个管道(Dev、QA和prod)。
我的理解是，如果一个团队中有2-3个开发人员，并且拥有在预定义的时间(24小时)内提交更改的短暂特性分支，那么最好使用，如下所示。团队中的开发人员每天多次向主干(主)提交他们的更改。
优势使用TBD:
对于TBD，有一个主分支和多个发布的分支。
何地as
在Gitflow中，有多个发布的分支来自长期存在的开发分支.
1)使用TBD，使用Jenkins需要多少管道？
( 2)每个管道的输入/输出是多少？
浏览 3提问于2019-01-18得票数 3
我在一家分公司工作，拿到了一份工作副本，真的很不干净。在查看要提交的更改时，我希望将一些oneliner修复提交到master分支。
在这种情况下，使用git stash没有真正的帮助，因为我的工作副本有许多其他更改，这些更改还不能与主版合并。
有没有更有效的方法来解决这种情况？(例如，提交并移动它的父对象？)
浏览 1提问于2009-12-04得票数 3
回答已采纳
我读过关于Gitflow工作流的文章，他们说要从主创建开发分支，从develop创建特性分支。因此，我分了一个回购，创建了一个分支develop，它的父级是最新提交的master (C1)，然后我从正在工作的Development分支中创建了两个特性分支。现在，主有了新的提交，但是我的开发分支和特性分支仍然基于旧的提交(C1)。
有一种方法可以将更改集成为主进度，比如更改指向开发分支的位置？也许使用重基，但我不知道如何适用于我的案件。开发和功能，分支是本地的。
简单地说，如何处理一个特性，并不断地整合师父的进步？
浏览 2提问于2018-04-14得票数 0
回答已采纳
1回答
我们使用gitflow方法，所以主分支、开发分支、特征分支。为了发布，我们将dev合并到掌握中，然后从那里发布。
正在发生的是，每次我们去PR开发大师，我们被告知开发是一个提交后的主人，我们不能合并。所以我们把主人介绍给开发。它显示没有差别和合并很好。那么我们就可以把公关开发交给主人了。但是下一个版本的循环会重复，即使我们没有做任何事情来掌握。
我应该找什么能引起这一切的东西？
浏览 7提问于2022-06-08得票数 -1
回答已采纳
2回答
gitlab有推送请求功能吗
、、、、
使用gitflow模型在Gitlab中保护Master、develop和release分支
开发人员希望使用tortoisegit从本地开发分支推送到远程开发分支。他不能这样做，因为它是一个受保护的分支。主用户是否可以审查推送，然后将其合并到开发分支。
或者是否允许开发人员推送到开发分支，并让主分支合并为发布分支和主分支。
浏览 26提问于2018-08-30得票数 0
回答已采纳
1回答
如何实现演示发布
、、
我和我的团队正在使用GitFlow对我们的代码进行版本化，但是现在我们需要有第三个分支来进行演示，以便能够
在演示中发布用于测试，然后在所有测试通过后从演示发布到掌握。
将演示中的修复程序合并到开发中
将来自MASTER的修补程序合并到演示中，同时进行开发。
下面是版本控制流程的草案(我希望它能有所帮助)：
我找不到GitFlow的解决方案，有什么建议吗？我们应该选择另一种工具吗？
浏览 7提问于2022-03-22得票数 0
为了自动化我的CI，我需要获得从develop分支执行的最后一次合并到主分支(或者更一般地说，从给定的源分支执行到给定的目标分支)的信息。我试过
git log --oneline --merges master -20
但是，这给了我一个清单，其中列出了最后20个合并到主中的内容，而没有按源分支进行区分(留给我解析和推断源分支与注释的繁琐任务)。是否有一种干净而健壮的方法可以直接从命令行中过滤源分支？
注意:我不需要提供有关CI或分支管理最佳实践的建议.我们在内部使用GitFlow工作流()，所以所有与存储库/CI相关的东西都已经井井有条(从方法上讲)。我只需要一个非常具体的回答非常具体的
浏览 2提问于2019-10-15得票数 2
回答已采纳
我一直在网上搜索，我找不到一个很好的问题，所以我相信我对他们是什么有一个根本的误解。
唯一的区别是在gitflow中有一个发布分支，用于“尚未发布”的更改，而在基于主干的更改中，没有一个分支？
因为对于这两种方法，您都需要某种方法来确定“生产”在哪里--在通过主分支和基于主干的开发中，即通过标记提交。
对于您选择的任何方法，如果生产需要热修复，那么该修复不是需要从标记的提交或主分支的头上分支吗？然后，您将需要将这些修补程序更改与发布更改合并。
不管是哪种情况，结果都是一样的。我不明白为什么gitflow鼓励长期存在的特性分支。这听起来像一个问题，既可能发生在主干或流量。
我还听说人们抱怨说，在
浏览 0提问于2022-12-19得票数 3
1回答
这里有新的git用户。我想使用git，但我处于SVN环境中。从我读过的一些书和一些简单的实验，我遇到了一些麻烦的陷阱，我希望得到澄清如何开始，而我的同事想杀了我。
我希望我的工作流程是：
是一个与svn的主干保持同步的主git分支。本地git分支是我所做的特性和错误在其中工作的。我想经常地使这些特性分支与主服务器保持一致。当我准备好时，我想将一个特性分支与主服务器合并，并将其提交给svn.
这是一个典型的工作流吗？
最初，我使用git合并来合并我的主分支和特性分支。这导致了各种冲突和问题。我后来阅读，以避免使用git合并在一起，并坚持使用git重基。那么，下面的git命令是否正确？
git s
浏览 3提问于2011-10-03得票数 5
回答已采纳
我有develop，master和feature分公司。
我对feature分支做了一些修改，并在master上做了公关。我还在develop上做了一个PR，它有一些不是在master分支上的更改。
结果发现，当我想在develop上做公关时，我有一些冲突，所以我把它们固定在Github上。
但基本上，develop是在我的feature分支上合并的，而现在我在master分支上的PR已经从develop分支中得到了所有这些提交。
我不需要这个。
我试过使用git revert，但这对我的feature分支没有任何作用。
有没有办法从feature分支中删除这个合并，还是应该关闭这个PR并创建
浏览 0提问于2018-04-24得票数 0
回答已采纳
我打算将我的发布分支合并到master，我想知道在合并到master中时，是否应该将开发中的提交压缩到一个合并提交中。
关于git flow的一般文档包含来自Atlassian页面的类似图：
在这些图中，只有一次提交出现在主服务器上，而不是所有为开发而提交的提交。
实际上，我喜欢有一个只发布提交的主分支的想法。
当合并到master中时，我应该保留所有在开发中的提交吗？或者，当你跟随Gitflow时，你会在合并到master之前压缩提交吗？
链接到源文章：
浏览 0提问于2016-12-14得票数 47
我有个git项目。让我们假设我在side分支上，并且我修复了一个bug (Bug #XX)在交付之后，我发现了另一个与Bug #XX相关的问题。现在我将在git 2中提交引用bug #XX的代码。
假设另一个开发人员也有一个分支，他想挑选我的Bug #XX修复程序。
有没有办法说git将这两次提交绑定为一次提交。所以当你精挑细选一个的时候，两个都要吗？
当然，我知道我可以挑选它们到一个新的分支，然后将它们压缩到一个提交中。但我假设我的辅助分支是我交付产品的主分支。
有没有办法绑定这两个提交？并在它们之间建立依赖关系？
浏览 0提问于2014-05-29得票数 1
3回答
我们的项目使用gitflow作为详细的，我的问题是QA如何适应这个过程。
假设我有一个主分支和一个热修复分支。一旦完成了修补程序，那么我相信QA应该在hotfix的发布版上完成它的工作。如果未通过，则使用此修补程序更新修补程序。又得到了释放。现在，当hotfix通过QA时，代码将被合并回master (应该没有冲突，只是一个直接的主副本不被更改)。然后，生产发行版将由主版完成。不过，需要关注的是，QA尚未验证此构建。他们已经验证了一个修复程序的构建。
我们如何协调主版本仅适用于产品代码，但对足够多的产品代码进行QA测试？有人对这种情况有什么经验吗？我看不到任何细节说明QA和测试是如何融入git
浏览 2提问于2013-12-03得票数 5
回答已采纳
3回答
我已经使用GIT几个星期了，并试图了解如何切换分支而不需要执行文件。这就是我所做的。
克隆了一个git存储库，并拥有一个本地主分支。
创建基于远程分支的新本地分支(Branch2)。
对主分支中的2个文件进行了更改。
我现在要做的是从主程序切换到Branch2。我对主分支所做的更改仅用于本地开发，不应提交。但是，当我尝试在eclipse中执行此操作时(即双击我试图切换到的本地分支)，它会不断地告诉我，存在未提交的更改，我需要提交、存储或重置。
有人能告诉我如何对本地文件进行更改，并让git忽略这个更改，这样我就不会收到这条消息的提示？
浏览 4提问于2012-12-20得票数 5
回答已采纳
1回答
在Azure DevOps中，Groups的分支安全性默认为“Force”属性，对于所有Azure DevOps组来说都是“Not”。这实际上拒绝了这一许可。
我们遵循我工作的gitflow，并且通常会显式拒绝持久化分支、Master和Develop的这个权限；然而，对于特性分支，我宁愿默认为“允许”，这样管理员就不必参与进来了。是否有一种方法可以为所有分支默认“强制推送”为“允许”为Azure DevOps‘贡献者’组，除非明确设置为“拒绝”？
干杯。
浏览 3提问于2018-09-26得票数 5
回答已采纳
我们想阻止人们直接推送给master。但我们也希望人们能够将他们的PR合并到master中。
我已经尝试在主分支上选择Restrict who can push to matching branches。这会自动选择一个允许Organization administrators, repository administrators, and users with the Maintain role.的选项。
然后，如果我有一个具有维护角色的团队，他们仍然可以直接推送到master。如果我将此权限降级为“写入”，他们将无法合并PR。
有什么办法可以解决这个问题吗？
浏览 2提问于2021-04-01得票数 0
1回答
CircleCI过滤器拉出请求
、、、、
我有这样一个Gitflow分支结构：
主(默认)
开发
特征/标题
我使用CircleCI时启用了“只构建拉请求”功能。启用此功能后，它将生成所有拉请求，并始终生成默认分支。因此，会发生以下情况：
从feature/header创建到运行CircleCI测试的develop
合并后，从develop到master的PR也会运行CircleCI测试
合并后，将触发完整的CircleCI生成和部署，因为master是默认分支。
我的问题是，我希望develop是我的默认分支，因为在Gitflow中创建的PRs有99%进入了develop。是否有一
浏览 1提问于2019-02-14得票数 4
2回答
我正在尝试在Azure DevOps (现场)中配置一个发布管道，以支持git流策略。我想要达到的目标是：
提交“release/*”触发软件的构建，并发布到QA的一个位置，提交给“主”，从第1步开始，将相同的软件构建(工件)发布到生产位置
因此，当我做一个git流“开始发布”时，软件就可以用于测试/QA，而当我“完成发布”时，它将提供给用户。
我的构建管道工作良好，它由发布分支触发，并以发布工件任务结束。我的发布管道使用这个工件，并有用于QA和生产的阶段，但是生产阶段永远不会触发。对于QA，我已经为‘Production /*’和在生产中为'master‘提供了一个工件过滤器。
是否
浏览 2提问于2019-11-15得票数 3
回答已采纳
我使用的是GitFlow，其特性分支映射到用户故事。本质上，每个特性分支都代表一个用户故事。当故事被完全实现和测试时，它被认为已经完成，并且这个特性已经完成(合并回开发分支)。
我现在的问题是，我的特性已经被分割成一个史诗，目的是有一个渐进的部署时间表。每个故事都应该有特色。绝大多数故事的设计都是为了使它们彼此之间不存在任何依赖关系，从而能够单独地实现它们。然而，有一点要注意的是，他们都依赖于一个共同的故事。
目前，普通的故事(特性)已经完成，但是还没有通过测试/质量保证部门，所以我还不能把它合并回开发部门。但我想在史诗里开始另一个故事。
在这一点上，“正确”的过程是什么？我应该仅仅从我现有的
浏览 2提问于2016-09-30得票数 4
回答已采纳
1回答
我很难理解促进构建(及其工件)的概念如何与GitFlow一起工作。我正在与Git、Jenkins和Artifactory (作为一个新的补充)制定一个持续的集成/交付工作流。这就是我到目前为止所做的工作：
来自develop分支的构建构件将自动推送到dev回购(如果单元测试等通过)，从而提升到dev状态。这些工件不可能得到进一步的推广。
来自feature分支的工件根本不会被推送或提升。
来自release分支的工件也只能提升到dev (或者我应该引入release回购吗？)
一旦release合并到master中，新提交就会被标记，Jenkins将运行完整的CI/CD管道。在
浏览 0提问于2019-06-19得票数 3
回答已采纳
我想知道。我有一个主分支机构。还有另一个由开发人员创建的分支，称为分支A。因为我是repo的所有者，所以我计划直接提交给主分支。开发人员是合作者。会否对A科造成影响？或者我的修复将自动应用于分支A？拉取请求过程中是否有影响。不管怎样，我正在使用git。
浏览 0提问于2020-09-12得票数 0
1回答
我正在使用gitflow工作流。在master中，我创建了一个hotfix分支并进行了一些修复。在合并回master之前，我想我应该先合并到develop，只为了查看在暂存中的更改，然后合并到主。
说合并到develop修复有一个冲突，我解决了通过合并开发到hotfix分支(是的，耻辱我)，我只是意识到我不能合并到master，因为开发有不稳定的东西。
如何创建从提交到合并与开发的分支？
PS:我使用git merge develop进行合并(没有使用no-ff标志)。
浏览 2提问于2017-02-17得票数 2
回答已采纳
1回答
因此，我们开始使用gitflow工作流与我们的服务器端以及移动开发。它非常适合服务器端代码，因为有测试覆盖和构建自动化，特性分支一旦测试确定就会被合并到开发分支中。与移动开发不同的是，由于更改是在您想要的时候(除了构建和测试之外没有时间部署)，所以您可以快速测试您所推送的代码中是否有任何bug，并快速进行更改。因此，这个工作流对于服务器端的开发非常有用。然而，我们面临的问题，移动开发与这一工作流。
使用gitflow工作流，我们有三个持久分支，即开发、阶段和主分支。主分支上的代码进入我们的play商店应用程序，我们有另一个封闭的beta google play商店应用程序，它只对我们的团队成员
浏览 8提问于2016-02-14得票数 3
我一直在努力阅读和学习，并试图理解一些东西。
我总是在本地裁剪功能分支，对它们进行工作，远程推送它们(以显示我的工作)，提交了一个PR，并(最终)远程合并了我的特性分支。
GitFlow似乎给出了一种稍微不同的模式：
局部切割特征分支
在当地工作
局部合并
推
我想知道这种“本土化”策略的好处是什么？
浏览 3提问于2017-12-10得票数 0
回答已采纳
是的，另一个流动问题。:(
我非常了解“标准”git重基流：
开发人员在上游分支(例如“主分支”)之外创建跟踪分支(例如“featureA”)。
开发人员代码，提交，拉和重基，代码，提交，拉与重基，等等。
代码完成后，开发人员将提交并推送到master。
我遇到的问题是，在与主合并之前，这个没有留给代码评审的空间。评审人员只在主服务器上看到更改，因此如果开发人员需要调整任何内容，那么对于给定的功能，主服务器上将有多个提交。理想情况下只有一个。
我知道有几种选择可以解决这一问题，但并不理想：
让开发人员将特性分支推到远程。这样做的问题是，在他们从大师手中重新建立基地后，推
浏览 3提问于2013-01-23得票数 5
扫码
添加站长 进交流群
领取专属 10元无门槛券
手把手带您无忧上云
相关资讯
热门标签
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM活动推荐
腾讯云开发者
