GIT 使用规范和最佳实践

1.1. GIT 使用规范和最佳实践

1. GIT入门请先读完

http://backlogtool.com/git-guide/cn/intro/intro1_1.html 2. GITFlow 相关请参照:

http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html 以下是我总结的干货 3. 主要分支和操作流程

1. develop – 主分支

i. 用于将新功能和修复汇总,所有的修改最终都需要回到这个分支 ii. 不对应任何环境

2. feature/* 用于新功能开发的分支, 从develop里拉出来

i. 可以由Git-Flow -> Start New Feature自动创建出来 ii. 对应开发和测试人员的本地环境

iii. 对于此功能的开发和测试将在此分支进行

iv. 此分支也可以拉出其他分支, 但是最终也必须回到此feature的

分支, 哪里拉的分支必须merge回到哪里去 v. 开发完成,并且单元测试完成, 并且经过组长审核以后应该把此feature汇合到主分支上 Git-Flow -> Finish Feature, 然后默认分支会回到develop上

3. release – 共享服务器测试环境(Staging) ,从develop里拉出来, 测试完成以后发布到master (生产环境)

i. 在develop上由Git-Flow -> Start new release出来 比如Release11-13 (起一个自己明白的名字) ii. 开发人员单元测试Release11-13, 可以

iii. 然后所有Release上的改动发布去生产环境之前需要发布前在

Staging上测试 (测试前问ReleaseManager是否ready) iv. 测试人员测试的时候发现了bug需要让开发人员知道是在哪

个Release分支(Release11-13上最新的提交) v. 开发修复bug以后直接提交,推送到Release分支(Release11-13) vi. 通知Release Manager继续发布Release上的补丁, 循环直到测

试人员确认ReleaseOK, 然后就是发布去master分支 vii. 在最新的Release分支上, GitFlow -> Finish Release (完成版本发

布) 会把最新的release分支并把release上面所有增加的改动

合并去master和develop

4. master分支– 对应生产环境, 只做2件事情

i. 记录发布到生产环境的提交(打上ProdXX的Tag) ii. 修复紧急bug (打上hotfix分支名的Tag)

5. hotfix 分支– 用来修复生产环境紧急bug

i. 由GitFlow -> start new hotfix 在本地创建分支 ii. 修复完以后提交

iii. 如果需要协作, 请把本地hotfix推送服务器

iv. 测试完成以后需要GitFlow -> finish hotfix 完成修复, 才会把修

复合并去最新master和develop分支,但是合并之前这2个分支都要是最新(分别去各分支pull) v. 注意: 每台电脑上只能有一个本地hotfix, 如果需要同时处理2个hotfix, 可以先把hotfix推送到远程,删除本地再拉新的hotfix分支 vi. 进阶的操作包括遴选, 回滚, 重置, 贮藏 都是有用的, 但是

不应经常被使用, 有遇到类似情况请自行研究

4. 操作基本

1. Fetch(获取) 用来获取远程服务器分支的信息并同步到本地

2. 完成阶段性修改都要 commit (拉取) 3. 共享自己的修改需要push (推送)

只有以上操作会跟远程服务器同步, 以下操作都属本地操作, 如果不推送其他人看不到

4. 注意当前本地分支, 本地分支需要跟远程同步(XXX Track origin/XXX) 5. 先把改动本地使用Stash (贮藏)

6. 切换(Switch/Checkout)分支之前unstaged files里面不能有跟另一个分支里的文件冲突的文件, 如果有应该先commit或者Stash

i. 建议将configure.properties等文件做如下操作, 这样的话就不需要提交

7. 在哪个分支里面找的bug就在哪个分支commit& push 8. 标签(Tag)用来提供额外信息, 比如 “已发布Staging测试(ReleaseXX-XX)”, “通过测试(PassTest)”或者 “已于X月X日发布生产(ProdXX-XX)”等等