为什么巨头都用git等工具来管理代码，我想绝对不仅仅是为了装13，今天要跟你谈个正经人正经管理代码的事。
协同开发
不同的行业不同的team协同工作方式也不同，今天我阐述的是互联 技术组的协同开发工作方式。作为一个混迹于互联 多年，每天的工作中都要和同事一起工作、交流甚至是争议，所以更好的协同开发会让工作更流畅，更高效。首先我们要先了解一下协同开发的主要工作形式和内容，举个简单的例子：N个程序员在一起开发一个项目A，N个程序员每天可能要修改同一个文件，项目A每天可能要发布（ONLINE）多个版本。那怎么能保证程序员N1，N2，。。。，Nn改一个文件不冲突或者是不被覆盖？多个版本的A1，A2,…,An的发布ONLINE版本不出现BUG呢？
版本控制
版本控制工具
版本控制系统常用的基本分为集中式版本控制系统和分布式版本控制系统两种。
集中式版本控制系统 例：svn，CVS。版本库集中存放在中央服务器，工作时需联 ，版本记录提交到中央服务器。
分布式版本控制系统 没有“中央服务器”,每个人的电脑上都是一个完整的版本库。版本记录提交到本地仓库，无需联 ，OffLine状态下可以看到所有的Log。分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
集中式版本控制系统(svn) VS 分布式版本控制系统(git)
svn优点：工作中使用svn大家能够看到其他人正在做些什么，管理员也可以很好的掌握每个开发者的权限。svn缺点：如果中央服务器发生单点故障，那么大家只能等中央服务器恢复后才能工作。或者备份不够及时，会有丢失数据的风险。git优点：git没有中央服务器概念，每一个人是一个完整的克隆版本，OffLine状态下可以继续工作，可以提交代码，可看到所有的Log等。如果服务器发生故障，可以用任何一个镜像出来的本地仓库恢复。git缺点：git没有权限控制，所以每个开发者都有一个完整的代码库。
git更好用的分支
git分支的灵活会让开发者工作更快捷方便。svn同样拥有分支，为什么git的分支更好用呢？分支（Branch）在SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开启新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。Git的分支是通过更改指针指针来实现，每个工作成员可以任意在自己的本地版本库开启无限个分支。举例：当我想做一个功能， 我可以开一个分支，做我喜欢的事。完全不需担心妨碍其他工作成员。只要我不合并及提交到主要版本库，没有一个工作成员会被影响。等到我不需要这个分支时， 我只要把它从我的本地版本库删除即可。无痛无痒。git的使用教程我做了个ppt，有兴趣的同事可以下载学习交流，这里我重点讲一下分支管理及分支管理策略。
分支管理
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点,每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变.假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支。
Git分支管理基本策略
一、主分支Master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
二、开发分支Develop
主分支只用来发布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
三、 功能分支，开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop
四 、预发布分支，发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试，预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
五、修补bug分支，正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。
github
在这个世界上有个叫GitHub的神奇的 站，从名字就可以看出，这个 站就是提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库
需要注意一点的是，Git仓库和GitHub仓库之间的传输是通过SSH加密，所以需要建立一个公钥秘钥，公钥添加到github上。这里我暂时不介绍。
GitLab
GitLab是利用 Ruby on Rails 一个开源的版本管理系统，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。这个我们团队现在正在使用，刚才我们也讲过git没有权限控制，gitlab基本解决了这个问题，而且web界面的人性化更能提高工作效率。其实我的理解gitlab其实就是github线下高仿源代码。
代码部署策略
自动化部署及工具
我们现有平台用的瓦力系统，其实有很多开源的产品，我简述一下期工作原理。线上（ONLINE）的完整的代码我们通过copy的形式复制一份,将每次上传的差异文件打包覆盖到copy的系统文件上，将应用指向到copy的文件上。通俗的将就是linux上的软连接。这样我们通过自动化脚本，可以同时进行多点操作。如果发布的正式版本出现重大问题，我们可以进行快速回滚，通俗的讲其实就是将我们现在的应用指向到copy前的目录。那大家就会疑问，那我们的应用在硬盘上岂不是存在很多的copy目录，这个没关系，我们可以通过定时清理，比如说我们按照个数清理，保持10个最新的copy目录，其他的自动删除。只要是设置一个合理的区间值就可以了。
如何避免版本发布发生错误
版本发布后最理想的状态用户正常使用，不出现任何bug。如何降低上线后的产品不出现bug呢？
我们在本地开发环境和线上环境前要做个隔离版本发布，预发布环境。也就是说正式发布之前我们要测试一遍，具体如何测试？涉及本次上线的相关人员预先提供或者是准备测试用例，按照测试用例一点一点去排查错误。在上线之前，在预发布版本发现所有的问题及时修正。
专业术语：
测试环境验收通过之后，合并到预发布环境的master，部署预发布环境
QA全面回归，发现问题提bug，开发者从master切分支修正再次合并、部署、验收。
回归完毕打tag，准备上线！
版本发布流程图
OA系统的使用及OA系统如何提供工作效率
OA办公自动化（Office Automation,简称OA）是将现代化办公和计算机 络功能结合起来的一种新型的办公方式。OA到底如何提高工作效率呢？简单举例：如何一个人发现问题，那他会向处理问题的人反馈问题，那如果是十个人呢，或者是更多的人，更多人里有n个人反馈是同样的问题呢？那处理的问题的人每天基本的工作只能是接收问题了，而不是处理问题了。OA系统就是将所有人的问题汇总，比如说1个人发现问题，将问题反馈到OA系统，更多的人将问题反馈到OA系统，那处理问题的人每天只要打开OA处问题就可以了，处理好后通过OA系统功能通知提出问题的人即可，而且重复的问题也不会去浪费同样的沟通时间成本，大大的提高了工作效率。如果是一个问题或产品需要长期处理，如果单靠人去记忆，如果人忘记了或者是外力因素人突然不在这个岗位了，那这个问题如何追踪呢。OA系统则可以长期记忆直至问题或产品结束。现在很多企业追求无纸化办公，我觉得其实道理是一样的。让繁琐琐碎的工作让系统去辅助，减少人与人之间的沟通成本时间，最大化的提高工作效率我们现在应用的OA系统是阿里公司提供的tower，大家有兴趣的可以学习一下。个人认为tower的图像化界面比较友好。我们现在OA系统的实际应用场景有很多，包括系统的bug及产品需求，都可以实际应用到OA系统里。
wiki是什么？
MediaWiki全球最著名的开源wiki程序，运行于PHP+MySQL环境。MediaWiki从2002年2月25日被作为维基百科全书的系统软件，并有大量其他应用实例。MediaWiki的开发得到维基媒体基金会的支持。
wiki的作用
总结
借助工具辅助工作，更好的提高工作效率和成功率。
减少人与人之间的沟通成本及时间，工作最大化。
合理的处理问题的应急解决方案，出现问题时将损失和风险降至最低
声明：本站部分文章内容及图片转载于互联 、内容不代表本站观点，如有内容涉及侵权，请您立即联系本站处理，非常感谢！