git的实际工作经验总结

分支工作的一个较佳的实践, 即git工作的最佳实践

从最初的svn到后来的git,上来给我的感觉就是git更方便, 可以在本地进行版本的提交,回退. 后来对hash有所了解, 知道了git的每个版本其实都是一个固定的hash. 这个hash有自己的父节点, 只要记住了这个hash, 提交就不会丢失.
实际呢? 对git的理解也是在这里, 大家还是在一个 develop 上去开发, 工作模式跟 svn 其实没有差别(除了我们自己的个人分支外, 在本地可以进行一些其他的处理)

分支的功能

develop分支

1. 最初开发阶段

当初我们在 develop 分支上开发, develop 就相当于我们原来的 svn 的一个分支一样, 大家都在这里进行开发. 知道我们真的进行决定发版后.

2. 发布版本阶段

后来开始进行版本的发布后, 我们大家的工作版本仍然在 develop 分支上, 然后 test 分支会从 develop 上进行切过来, 然后 release 分支上又会从 test 分支上进行切出. 然后在对应的分支上进行bug的提交.

好处没有啥,就是比较好理解吧. 坏处是在 develop 上的东西终究会直接上到 release, 不能对某些功能进行很好的控制, 也不能很好的控制代码质量. 因为工程的功能点比较多, 也不可能对所有的功能进行全部的回归. 只能尽量的对一些改动的地方进行重点测试.

3. 按照功能点进行的分支控制

开始按照通用的工作流, 所谓的 git flow 进行开发.但是可能又会稍有不同.
我们每个人的开发起点都是基于 release 分支的(或者 master), 基于一个比较稳定的版本然后开始自己的特性分支开发. 每一个特性就是一个固定的功能.
基于功能点的分支,这个分支只是属于你的,如果这一个分支需要进行测试, 那么我们提交到 test 分支上去. test作为一个测试的分支, 是可以随时变化的.
如果需要上线的分支, 我们是会合并到 release 分支上去的.
develop分支作为一个开发内部的协调沟通分支.

后记与总结

记录的很乱, 最后也总结一个下.
每一个分支都有每一个分支的功能. 每个人又是在每个人的分支上进行开发, 这个开发的起点一定是稳定的分支, 这样你增加的功能就会比较单一(只是你自己开发的分支). 对于以后的发布和合并都会比较好处理. 如果分支的开发周期比较长, 最好经常 rebase 一下release 的代码, 避免以后合并处理的冲突较多.
develop: 开发内部的协调和自测分支;
test: 测试分支, 提测分支;
release: 发布分支, 比较稳定的分支;
master: 线上分支, 稳定版本的分支;

对于bug的修复, 如果是自己的特性分支问题, 那么就在自己的特性分支上开发. 如果是稳定版本的修复, 一定是在对应的稳定版本进行修复. 然后经过 test 分支的回归(如果是 hotfix 可以直接合并到 release 或者 master 上进行紧急测试), 合并到对应的版本上去.