一、代码仓库
解释：git其实是用来存储代码的开源仓库，通过给当前仓库下的用户分配不同的角色：管理员、开发者、测试等来区分权限；
1、一般代码仓库的拥有者（owner）添加用户及分配角色的权限，对整个代码仓库有全部的操作权限，如：创建分支、删除分支、拉取代码、提交代码；
2、一般代码仓库的开发者（developer）对部分操作权限，如：创建分支、拉取代码、提交代码；
3、一般代码仓库的测试者（qa）对部分操作权限，如：pull-request，拉取代码；
二、分支
1、master分支
解释：主分支，创建一个代码仓库后默认在master分支上
2、开发分支、测试分支（公共分支 or 环境分支）
（1）开发分支：有开发人员根据项目或功能创建的分支，需要以master最新代码为基础，创建一个全新的分支，并推送到远端，在改分支上修改代码，目的是为了不受其他功能的影响，保持纯净的开发环境；
（2）测试分支：类似于开发分支，如果只有一个功能或者项目时，等同于开发分支；若多个项目同时进行，并且需要同一个环境，必须将多个开发分支merge（合并）到一个公共的分支，目的是为了测试能同时进行多个项目的测试；
3、pull、merge、tag、reset、commit、push、pull-request
（1）pull：拉取远端代码到本地；
（2）merge：合并某个分支代码到当前的分支；
（3）branch：分支，某个功能的修改均在一个固定的分支上（分支名不可与远端所有分支名重复）；
（5）tag：分支的另一种形式，针对某个分支上的某一个次提交打一个tag（标签），根据这个tag可以精确快速的找个某一次具体的提交时间以及提交内容；目的是为了与下一次的代码提交区分开；
（6）reset：重置某个具体分支的代码，一般命令为： git reset --hard head ;其中的head及为某次具体的提交，使用SHA-1码作为唯一标志，回退到之前的提交；
（7）commit：提交一次代码；
（8）push：推送到远端；
（9）pull-request：提交代码时先申请，需要其他有权限的开发者通过本次提交；
（10）conflict：冲突，分支合并时由于同一代码块或者同一行的代码在不同分支进行了不同的修改。
三、一些问题
1、测试分支和开发分支用途是什么？
（1）测试分支：为了能多个项目同时进行测试，不影响其他项目的测试，共用同一套测试环境；
（2）开发分支：针对某个pmo（项目）单独创建的分支，代码只对需要实现的功能进行修改；
2、代码分支命名规则是什么？合并分支命名规则是什么？
（1）代码分支（也就是开发分支）：pmo名_功能名（英文）；例如 PT-3246 或者 PT-3246-detail
（2）合并分支：test_环境名（t1、t2、fvt）；
3、同一仓库/站点的多个并行pmo分支需要在同一个测试环境部署怎么办？
合并正在并行的多个pmo分支为一个环境分支（及公共分支：test_环境名）。
备注：
（1）需要找开发合并，合并中如果出现冲突，需要找该pmo分支的开发者进行冲突解决；
（2）需要维护该公共分支的代码始终为几个项目的最新，及时合并master代码，及时合并开发代码，部署到具体的环境；
（3）某个pmo分支合并后影响到其他pmo功能时，需要及时找开发确认情况（可能是合并代码的过程中丢失了某部分的代码）；
4、项目A和项目B合并的部署分支，在项目A提前测试完成的情况下，如何进行发布？
先在测试环境单独部署项目A的分支代码，并告知其他正在使用该站点的测试及开发单独占用所需要的时间；
部署验证完成确认无其他问题后，使用本次生成的btag（其实就是tag，只是另一种命名，btag=开发tag）发布线上。
5、开发分支合入测试分支审批权限执行人是谁？
测试
6、bds系统怎么区分开发环境、测试环境和线上环境？测试环境有几套？怎么选择不同的测试环境部署？
备注：bds系统也就是Jenkins打包系统
（1）开发环境：DEV
（2）测试环境：QA
（3）线上环境：OPS
（4）测试环境一共有3套，fvt、t1、t2；根据自己项目需要，以及测试环境占用情况选择测试环境；
举个例子：
现在有tujia-online-promo-docker站点的功能需要部署到测试环境，
首先看该功能是否依赖其他站点的部署，如果需要，与其他站点的环境保持一致；如果不需要，看该功能开发是否指定测试环境，若指定，则使用开发指定的测试环境；若未指定，则看该站点是否3套环境都已经部署了其他功能，若其中有未部署的环境，则选择该套；若均已占用，则与负责的测试及开发商定合并环境分支部署；
7、怎么确认当前的部署不存在部署冲突？怎么分批部署？怎么全量部署？
（1）部署冲突：查看当前环境部署的是公共分支还是测试分支
如果是公共分支，那么一般不会存在冲突，只要保证各个分支的代码不存在冲突，将自己需要测试的分支合并到公共分支即可；
如果当前需要部署的环境被单独占用，需要与部署该单独分支的测试进行沟通，部署公共分支。
（2）分批部署：选择单个服务组或者多个服务组（多个时，用逗号隔开，如A,B,C）分多次发布
（3）全量部署：选择ALL，即为全量部署
8、怎么确认线上发布rtag是正确的？
rtag产生的过程：分支部署 → 生成btag → 发布线上，生成rtag
首先确认需要上线分支的已经是最新代码，btag是由已经diff过的最新代码打包生成，并且在测试环境验证无其他问题，再确认发布上线的btag是正确的，来确保rtag是正确的。
备注：若为回滚的rtag，一定要与开发确认该rtag的正确性（一般使用上一次线上发布的rtag）。
9、怎么检查rtag和btag所在分支拉取正确？
详见第8条（总结来说，一是保证最后一次部署的分支跟code diff的最后一次代码提交是保持一致的，二是不要出现手误粘贴错误的情况）
10、btag和rtag用途是什么？怎么使用？
（1）btag：
用途： 用来记录一次测试环境打包的产物名称，可以用来作为查找某一次功能打包的时间点，大多数情况下作为发布线上的tag_name。
使用方法：在bds系统的配置tag_name中填入，部署在测试环境时则为当前功能为生成btag的分支功能；部署在线上环境时，生成rtag，则线上功能为当前功能为生成btag的分支功能。
（2）rtag：
用途：用来记录线上环境打包的产物名称，可以用来作为查找某一次功能打包的时间点，大多数情况下作为<u>回滚线上发布</u>的tag_name。
使用方法：在bds系统的配置tag_name中填入，部署在测试环境时则为与线上功能保持一致；部署在线上环境时，为回滚线上功能到当前rtag的功能。
11、线上回滚后操作步骤
（1）回滚：使用上一次发布到线上的rtag（该rtag所在线上功能必须正常）重新部署线上，此时master的代码并没有被reset；
（2）回滚后：此时线上功能已经回到上一次发布的功能，但是master的代码仍然是最新的未回滚的代码，此时需要开发修改master的代码为未发布前的代码，并且推送到远端（这样做的目的是为了保证需要合并master代码的分支不会带上有问题的代码）。
