随着近些年 Git 的快速普及，想必无论开发还是测试在日常工作中都要用到 Git。
对于刚刚接触的 Git 的人来说，打开一个 Git 仓库，面对十几个甚至几十个分支时，有的人不理解，有的人云里雾里，为什么会创建这么多分支？
对于开发需要知道如何通过 Git 分支来管理产品的开发和发布，尤其是对于大型的项目的开发，只有 master 和 develop 分支是无法满足产品管理和发布要求的，我们还需要其他分支以便更好的管理产品代码。
对于测试更多的了解开发过程及分支管理有助于测试及开展自动化测试用例，可以针对不同的分支进行测试用例的编写，在以后回归测试里可以通过分支或是 tag 找到对应的测试用例。
在持续集成中，你可能需要通过 Jenkins 来修改代码，并且将修改后的代码提交到Git仓库里。怎么做呢？最方便的做法还是 Jenkins 提供对应的插件，但是很遗憾我没找到合适的。另外我也觉得通过脚本的方式来实现会更加稳定，不用担心 Jenkins 以及插件升级带来潜在不好用的可能。
在使用 Jenkins pipeline 的时候，在 Linux 需要用 root 来执行，我想通过 Jenkins pipeline 的语法来解决，但是只找到这种方式：SSH Pipeline Steps
这个pipeline里包含了如下几个技术：
Like database product, it runs on multi-platform, but for software enginner they may only works on one platform, how they could identify their code works on all platform? manually build the various platforms? NO!
Most people would know we can use Jenkins pipeline, they may create multi Jenkins job for different stuation.
How to do it in an elegant way, I would want to share how to use multibranch pipeline to achieve.
Code Coverage is a measurement of how many lines, statements, or blocks of your code are tested using your suite of automated tests. It’s an essential metric to understand the quality of your QA efforts.
Code coverage shows you how much of your application is not covered by automated tests and is therefore vulnerable to defects. it is typically measured in percentage values – the closer to 100%, the better.
When you’re trying to demonstrate test coverage to your higher-ups, code coverage tools (and other tools of the trade, of course) come in quite useful.
List of Code Coverage Tools
| Tools | Support Language | Cost | Partners |
|—|—|—|—|—|
| Squish Coco | C, C++, C#, SystemC, Tcl and QML | Not disclosed |Botom of this page Selected Clients|
| BullseyeCoverage | C, C++ |$800 for 1-year license and up | |
| Testwell| C, C++, C#, Java| Not disclosed| |
| Parasoft C/C++test |C, C++ | Not disclosed | partners |
| VECTOR Code Coverage | C, C++ | Not disclosed (free trial available)| partners |
|JaCoCo| Java | Open Source| Most famous code coverage tool in Java area |
最近遇到一个 regression bug，是产品完成构建之后，build commit number 不对，显示的 HEAD 而不是常见的 97b34931ac HASH number,这是什么原因呢？
我检查了 build 脚本没有发现问题，branch 的输出是正确的，那我怀疑是引入 Jenkins 的原因，果然登录到远程的 agent 上去查看分支名称如下：
C:\workspace\blog>git branch |
果然问题出在了 Jenkins 上。这个问题有简单办法解决，就是直接使用git命令来clone代码，而不使用Git插件
git clone --depth 1 -b u2opensrc https://username:"passwowrd"@git.github.com/scm/blog.git blog |
这种方式固然简单，不会出错，但它是明码显示，我岂能容忍这种不堪的处理方式吗？肯定还是要在 Git 插件上找到解决办法的。
随后google一下，果然有遇到和我一样问题的人，问题链接 这里。
他说他做了很多调查，还跟专业的 Jenkins 人士联系，试了很多次，最后找到这个办法
checkout([$class: 'GitSCM', branches: [[name: '*/feature/*']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'LocalBranch', localBranch: "**"]], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '99f978af-XXXX-XXXX-8147-2cf8f69ef864', url: 'http://TFS_SERVER:8080/tfs/DefaultCollection/Product/_git/Project']]]) |
主要是在 extensions:[] 中加入这句 [$class: ‘LocalBranch’, localBranch: “**”]
这是 Jenkins 的 Bug 吗？带着这个疑问随后通过 Pipeline Syntax，找到 checkout: Check out from version control，在 Additional Behaviours 里有 Check out to specific local branch 这个配置项
If given, checkout the revision to build as HEAD on this branch.
If selected, and its value is an empty string or “**”, then the branch name is computed from the remote branch without the origin. In that case, a remote branch origin/master will be checked out to a local branch named master, and a remote branch origin/develop/new-feature will be checked out to a local branch named develop/newfeature.
看介绍原来 Jenkins 自带这个设置，只是它不是默认选项，所以才遇到刚才那个问题。随后选择这个设置，然后填入”**”，然后生成 Pipeline 脚本，就跟上面的脚本一样了。