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工作流程。它就是这样。

1. 开发人员有一项任务需要完成。


2. 开发人员关闭 master ，我们称之为任务。


3. 开发人员使用任务。
   
   
   
   1. 开发人员为任务编写自己的单元测试。
   
   



4. 开发人员在需要时从 master 获取更新。
   
   
   
   1. 他们可以重新绑定或合并，无所谓。
   开发人员完成任务。
   
   
   
   1. 开发人员通过 master 进行最终更新。
   
   
   2. 单元测试和所有回归测试均通过。
   
   
   3. 可选开发者将任务提交给QA进行验收测试。开发人员合并到 master 。
   
   
   4. 开发人员删除任务。
      
   
   
   
   

   因为开发人员正在编写他们自己的单元测试，此时你知道 master 中的所有内容都经过了单元和集成测试。一些重要或多毛的功能已经在5.3中进行了验收测试，但通常您在此时不会打扰QA。
   
   

   健康的工作流程非常重要， master 始终保持高质量状态。这意味着开发人员必须参与测试过程。 QA并没有把它抛到墙上，并希望最好，质量保证部门应该花时间在接受和黑匣子测试上来发现开发人员不会想到的错误。 当您决定准备发布时，
   
   

   
   
   

   
   
   1. 将测试分支与 master 匹配。
      
      
      
      1. 您可以合并 master ，在 master 或删除并重新创建测试分支。
      
      

   
   
   2. QA获取自上次发布后添加的所有更改的列表。
      
      
      
      1. 他们可以从问题跟踪器中获得此信息。
      
      
      2. 如果 testing 是重新启动 master 它们可以 git log 并查看自上次发布以来的合并提交。
      
      
      
      3. 让QA验收测试变更列表，对照测试。
      
      ol>
      
      

      让我们在这里暂停并解释步骤3的重要性。 QA是用户看到它之前的最后一行。 QA测试用户实际使用的内容非常重要。用户将看到集成的代码库，而不是单独工作的单个功能部门，因此QA应该将精力集中在集成版本上。

      
      
      

      功能可以独立工作，并且当他们合并时有奇怪的错误。一个简单的例子是将项目的编码从ASCII改为Unicode的功能。开发人员忠实地改变整个系统来使用Unicode，这很好。与此同时另一位开发人员正在完成一项任务，其中包括更改一些视图他们没有考虑字符编码，他们用ASCII假设编写他们的视图。开发人员对测试视图感到恐惧。单独测试，但功能分支工作正常。结合在一起，QA可以捕捉仍然使用错误字符编码的视图。

      
      
      

      继续。

      
      
      4. QA发现错误并将其报告给开发人员。
         
         
         
         1. 开发人员补丁测试（直接适用于小事情，在分支中适用于大事情）
         
         
         2. 可选开发人员将这些修补程序挑选回 master 。这是可选的，因为它将在以后处理。
         
         

      
      
      5. QA声明测试准备发布。
         
         
         
         1. release 是 git merge --ff-only testing 。如果它没有快进，你的修补程序位于 release 中，需要被回溯。 释放与版本号。
         
         
         2. release 被推送到生产。 $ b

      
      
      6. testing 会合并回 master 。
      
      

      最后一步确保在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.

      1. Developer has a task to do.
      2. Developer branches off master, let's call it task.
      3. Developer works on task.
         1. Developer writes their own unit tests for the task.

      4. Developer gets updates from master when they need them.
         1. They can rebase or they can merge, doesn't matter.

      5. Developer finishes task.
         1. Developer does a final update from master.
         2. Developer makes sure their unit tests and all regression tests pass.
         3. Optional Developer submits the task to QA for acceptance testing.
         4. Developer merges into master.
         5. Developer deletes task.

      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...

      1. Match the testing branch to master.
         1. You can merge with master, rebase on master or delete and recreate the testing branch. They each have slight advantages and disadvantages which will become apparent.

      2. QA gets a list of all changes which have been added since the last release.
         1. They can get this from the issue tracker.
         2. If testing is rebased off master they can git log and look at the merge commits since the last release.

      3. Have QA acceptance test the change list against testing.

      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.

      4. QA finds bugs and reports them back to the developers.
         1. Developers patch testing (directly for small things, in a branch for big things)
         2. Optional Developers cherry-pick those fixes back to master. It's optional because it will be taken care of later.

      5. QA declares testing ready for release.
         1. release is git merge --ff-only testing. If it doesn't fast-forward, you have hotfixes in release which need to be backported.
         2. Tag release with a version number.
         3. release is pushed to production.

      6. testing is merged back into master.

      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屋！