Git开发vs发布分支最佳实践 [英] Git Development vs Release branch best practices
问题描述
我从每个sprint开始监测两个分支 - Release
和 Master
。
$ master $
分支从开发人员创建新分支(特定于任务),实现其更改并创建拉入请求,并将其合并到主。
版本
分支是sprint特有的,它始终可以提交给生产。我们只将提交给 Master
并经 QA
验证的分支合并到Release分支中。 这种方法最适合我们,因为我们在固定的时间间隔提交 Release
,并实施和验证特定的功能,因此我们完全知道发生了什么下一个版本。
这个问题延续了 avoid-merging-master-into-development-branch
和 git-merge-only-branch-specific-commitits
在一行中,我想
请确保只有通过QA验证的开发分支才能进入下一个候选发布版本。
我曾想过使用我以前的讨论中的以下工作流程选项;
git pull --rebase master taskA
//在taskA分支上工作,do多次提交,并在需要时多次执行此命令;
在重新赋值taskA到Master
的时候git checkout taskA
git rebase -i origin / Master //删除任何不属于taskA的提交。
git checkout origin / master
git merge taskA
这个工作流程会为我在 Master
上重新命名的每个分支提供清晰的历史记录,并由QA验证。我可以轻松地将已验证的分支重新映射回 Release
分支。
我的方向是否正确?这个git-flow会最好吗?有没有更好的方法来做我想做的事情?
我们只将合并分支提交给Master,并由QA验证到Release分支。
这意味着您必须两次集成功能分支。一旦进入Master并再次进入Release。你正在努力解决这个明显的问题:你如何确保集成到Master中的所有内容都集成到Release中?由于功能基于其他功能构建,因此它们必须采用相似的顺序。
不要试图解决这个问题。这很困难和混乱,你一定要小心。最好有一个更简单的流程。让我们回到您的既定目标。
确保只有通过QA验证的开发分支转到下一个候选人。
(Emphasis mine)这不是一个目标,而是实现目标的解决方案。你真正的目标是什么?如何...
确保只有经过QA验证的代码进入下一个发布。
看看我在那里做了什么?质量发布不关心代码的来源,它关心代码的状态被释放。您希望确保没有任何QA未检查过的内容进入发布版。为了做到这一点,我建议改变你的工作流程,一个版本的 Gitflow工作流程。它就是这样。
- 开发人员有一项任务需要完成。
- 开发人员关闭
master
,我们称之为任务
。 - 开发人员使用
任务
。
- 开发人员为
任务
编写自己的单元测试。
- 开发人员为
- 开发人员在需要时从
master
获取更新。
- 他们可以重新绑定或合并,无所谓。 开发人员完成
- 开发人员通过
master
进行最终更新。 - 单元测试和所有回归测试均通过。
- 可选开发者将
任务
提交给QA进行验收测试。开发人员合并到master
。 - 开发人员删除
任务
。
任务
。
- 将
测试
分支与master
匹配。
- 您可以合并
master
,在master
或删除并重新创建测试
分支。
- 您可以合并
- QA获取自上次发布后添加的所有更改的列表。
- 他们可以从问题跟踪器中获得此信息。
- 如果
testing
是重新启动master
它们可以git log
并查看自上次发布以来的合并提交。
- 让QA验收测试变更列表,对照
测试
。 - QA发现错误并将其报告给开发人员。
- 开发人员补丁
测试
(直接适用于小事情,在分支中适用于大事情) - 可选开发人员将这些修补程序挑选回
master
。这是可选的,因为它将在以后处理。
- 开发人员补丁
- QA声明
测试
准备发布。
-
release
是git merge --ff-only testing
。如果它没有快进,你的修补程序位于release
中,需要被回溯。释放与版本号。 -
release
被推送到生产。 $ b
-
-
testing
会合并回master
。 - Developer has a task to do.
- Developer branches off
master
, let's call ittask
. - Developer works on
task
.- Developer writes their own unit tests for the
task
.
- Developer writes their own unit tests for the
- Developer gets updates from
master
when they need them.- They can rebase or they can merge, doesn't matter.
- Developer finishes
task
.- Developer does a final update from
master
. - Developer makes sure their unit tests and all regression tests pass.
- Optional Developer submits the
task
to QA for acceptance testing. - Developer merges into
master
. - Developer deletes
task
.
- Developer does a final update from
- Match the
testing
branch tomaster
.- You can merge with
master
, rebase onmaster
or delete and recreate thetesting
branch. They each have slight advantages and disadvantages which will become apparent.
- You can merge with
- QA gets a list of all changes which have been added since the last release.
- They can get this from the issue tracker.
- If
testing
is rebased offmaster
they cangit log
and look at the merge commits since the last release.
- Have QA acceptance test the change list against
testing
. - QA finds bugs and reports them back to the developers.
- Developers patch
testing
(directly for small things, in a branch for big things) - Optional Developers cherry-pick those fixes back to
master
. It's optional because it will be taken care of later.
- Developers patch
- QA declares
testing
ready for release.release
isgit merge --ff-only testing
. If it doesn't fast-forward, you have hotfixes inrelease
which need to be backported.- Tag
release
with a version number. release
is pushed to production.
testing
is merged back intomaster
.
因为开发人员正在编写他们自己的单元测试,此时你知道 master
中的所有内容都经过了单元和集成测试。一些重要或多毛的功能已经在5.3中进行了验收测试,但通常您在此时不会打扰QA。
健康的工作流程非常重要, master
始终保持高质量状态。这意味着开发人员必须参与测试过程。 QA并没有把它抛到墙上,并希望最好,质量保证部门应该花时间在接受和黑匣子测试上来发现开发人员不会想到的错误。 当您决定准备发布时,
ol>
让我们在这里暂停并解释步骤3的重要性。 QA是用户看到它之前的最后一行。 QA测试用户实际使用的内容非常重要。用户将看到集成的代码库,而不是单独工作的单个功能部门,因此QA应该将精力集中在集成版本上。
功能可以独立工作,并且当他们合并时有奇怪的错误。一个简单的例子是将项目的编码从ASCII改为Unicode的功能。开发人员忠实地改变整个系统来使用Unicode,这很好。与此同时另一位开发人员正在完成一项任务,其中包括更改一些视图他们没有考虑字符编码,他们用ASCII假设编写他们的视图。开发人员对测试视图感到恐惧。单独测试,但功能分支工作正常。结合在一起,QA可以捕捉仍然使用错误字符编码的视图。
继续。
最后一步确保在QA流程中发现的任何错误修补程序将合并回 master code>。这就是为什么我早些时候说过如何重置
testing
并不重要,它将全部合并回 master
无论如何。
你有。确保发布的所有代码的过程都经过QA。除了开发质量保证的变更日志外,没有必要仔细追踪已集成的内容。
I have been monitoring two branches starting from each sprint - Release
and Master
.
Master
branch is from where developers create new branch(task specific), implement their changes, and creates pull request which gets merged into the Master.
Release
branch is sprint specific which remains always submittable to the production. We only merge branches committed to the Master
and verified by the QA
into Release branch.
This approach works best for us as we submit Release
at fix regular interval with specific functionality implemented and verified, and hence we exactly know what's going in the next release.
This question is continuation of avoid-merging-master-into-development-branch and git-merging-only-branch-specific-commits
In one line I want to
"Make sure that only development branches which are verified by QA goes to the next Release Candidate."
I have thought of to use following workflow options from my previous discussions;
git pull --rebase master taskA //Work on taskA branch, do multiple commits, and also execute this command multiple times whenever required; At time of Rebasing taskA to Master git checkout taskA git rebase -i origin/Master // Remove any commits that are not belongs to taskA. git checkout origin/master git merge taskA
This workflow will give me clear history for each of my branches rebased on the Master
which will be verified by QAs. I can easily rebase verified branch back to the Release
branch.
Am I going in right direction? Would this git-flow works best? Is there any better way of doing what I want to achieve?
Here's your problem.
We only merge branches committed to the Master and verified by the QA into Release branch.
This means you have to integrate feature branches twice. Once into Master and again into Release. You're struggling with the obvious problem: how do you make sure everything integrated into Master is integrated into Release? And because features build on other features, they have to be in a similar order.
Don't try to solve this problem. It's hard and messy and you'll always have to be careful. Better to have a process that's more foolproof. Let's go back to your stated goal.
Make sure that only development branches which are verified by QA goes to the next Release Candidate.
(Emphasis mine) That's not really a goal, that's a solution to implement a goal. What's your real goal? How about this...
Make sure that only code which has been verified by QA goes to the next Release.
See what I did there? A quality release doesn't care about where the code came from, its cares about the state of the code being released. You want to make sure nothing that hasn't been checked by QA goes into the release. To do that, I would suggest changing your workflow to a version of the Gitflow Workflow. It goes like this.
Because developers are writing their own unit tests, at this point you know everything in master
has been unit and integration tested. Some important or hairy features have been acceptance tested in 5.3, but generally you don't bother QA with that at this point.
It is very important to a healthy workflow that master
is always kept in a state of high quality. This means developers have to be involved in the testing process. There's no throwing it over the wall to QA and hoping for the best, QA should be spending their time on acceptance and blackbox testing to catch bugs the developers will not think of. Master is always your Release Candidate.
When you decide you're ready for a release...
Let's pause here and explain why step 3 is important. QA is the final line before users see it. It's important that QA is testing what the users will actually use. Users will see the integrated code base, not individual feature branches working in isolation, so QA should focus their efforts on the integrated release.
Features can work great in isolation, and have weird bugs when they're combined. A simple example would be a feature which changes the project's encoding from ASCII to Unicode. The developer dutifully changes the whole system to use Unicode and it's great. Meanwhile another developer works on a task which includes changing some views. They're not thinking about character encoding, and they write their views with ASCII assumptions. Developers are horrible about testing views. Tested in isolation, but feature branches work fine. Combined together, QA can catch the view which is still using the wrong character encoding.
Moving on.
That final step ensures any patches to bugs found in the QA process will be merged back into master
. This is why I said earlier it doesn't really matter how you reset testing
, it will all be merged back into master
anyway.
There you have it. A process for ensuring all code which is released has gone through QA. Except for developing the change log for QA, there is no careful tracking of what's been integrated where necessary.
这篇关于Git开发vs发布分支最佳实践的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!