Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
代码版本控制那点事
我是谁
我是宋利鹏,爱google、爱mac、爱开源
关注linux、ruby、java、php、架构、互联网
http://github.com/songlipeng2003
为什么要代码版本控制
管理代码版本
团队协作
代码分支管理
谈谈工具
第一代 CVS
第二代 SVN
第三代 分布式代码管理工具 Git
为什么是git
分布式代码管理
离线提交
无痛分支、tag
强大的第三方代码托管,github、bitbucket、
oschina、csdn等
聊聊github
开源免费
简单而好用的issue管理
漂亮的api和回调接口,可以很容易和第三方工具集
成
社交化的开源社区
基于wiki的文档管理
强大的第三方工具链
分支管理
分支的最佳实践 – git flow
http://danielkummer.github.io/git-flow-
cheatsheet/index.zh_CN.html
关于提交
我们每天都在向svn里提交代码,但是我们的提交怎么
样呢?我们一起来看看
提交中的问题
怕生成版本过多,不敢提交
不了解修改内容,就直接提交
不查看提交内容,就提交
每天固定时间才提交,例如下班
每次需要完成一个大功能才提交
提交的时候,注释不写,或者书写不规范
我们该怎么做
尽早提交
尽快提交
经常提交
提交前必须清楚自己修改了什么,查看每个文件修
改了什么
写好提交注释
原子提交
一个不能再细分的功能点做一次提交
修复一个bug做一次提交
每次提交要尽量保证不影响项目的正常运行和测试
错误的注释
不写注释
写了等于没有写注释
1. 修改了项目
2. 修复了bug
3. 补充提交
如何注释
使用 添加、修复、改进、修改等动词开始,描述清
楚修改位置及其功能,描述清楚代码运行环境等
良好的注释,例如:
1. 添加用户管理功能
2. 修复了首页在chrome打开报错问题
3. 忽略临时文件夹和日志文件夹
忽略
忽略那些文件?
项目文件,例如eclipse、idea配置文件
临时文件,例如缓存文件、临时拷贝文件、运行时文件
日志文件,例如错误日志、访问日志
依赖文件,例如jar包,依赖包等, 最佳使用依赖管理代替在代码中包含依
赖,例如maven...
什么时候不应该提交
在文件中只修改的一些空格或者换行,没有修改代
码逻辑
你根据自己环境修改了代码配置,例如数据库配置
你的修改的代码只是中间产物而不是原始代码
你修改的代码仅仅是为了调试使用,例如var_dump
语句
什么是优秀的提交
每次提交只做一个修改
每次提交要包含完整的修改
写好注释,说明你修改了什么
注释说明为什么做了这个修改
不要提交被注释的代码
Upcoming SlideShare
Loading in …5
×

代码版本控制那点事

1,120 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

代码版本控制那点事

  1. 1. 代码版本控制那点事
  2. 2. 我是谁 我是宋利鹏,爱google、爱mac、爱开源 关注linux、ruby、java、php、架构、互联网 http://github.com/songlipeng2003
  3. 3. 为什么要代码版本控制 管理代码版本 团队协作 代码分支管理
  4. 4. 谈谈工具 第一代 CVS 第二代 SVN 第三代 分布式代码管理工具 Git
  5. 5. 为什么是git 分布式代码管理 离线提交 无痛分支、tag 强大的第三方代码托管,github、bitbucket、 oschina、csdn等
  6. 6. 聊聊github 开源免费 简单而好用的issue管理 漂亮的api和回调接口,可以很容易和第三方工具集 成 社交化的开源社区 基于wiki的文档管理 强大的第三方工具链
  7. 7. 分支管理 分支的最佳实践 – git flow http://danielkummer.github.io/git-flow- cheatsheet/index.zh_CN.html
  8. 8. 关于提交 我们每天都在向svn里提交代码,但是我们的提交怎么 样呢?我们一起来看看
  9. 9. 提交中的问题 怕生成版本过多,不敢提交 不了解修改内容,就直接提交 不查看提交内容,就提交 每天固定时间才提交,例如下班 每次需要完成一个大功能才提交 提交的时候,注释不写,或者书写不规范
  10. 10. 我们该怎么做 尽早提交 尽快提交 经常提交 提交前必须清楚自己修改了什么,查看每个文件修 改了什么 写好提交注释
  11. 11. 原子提交 一个不能再细分的功能点做一次提交 修复一个bug做一次提交 每次提交要尽量保证不影响项目的正常运行和测试
  12. 12. 错误的注释 不写注释 写了等于没有写注释 1. 修改了项目 2. 修复了bug 3. 补充提交
  13. 13. 如何注释 使用 添加、修复、改进、修改等动词开始,描述清 楚修改位置及其功能,描述清楚代码运行环境等 良好的注释,例如: 1. 添加用户管理功能 2. 修复了首页在chrome打开报错问题 3. 忽略临时文件夹和日志文件夹
  14. 14. 忽略 忽略那些文件? 项目文件,例如eclipse、idea配置文件 临时文件,例如缓存文件、临时拷贝文件、运行时文件 日志文件,例如错误日志、访问日志 依赖文件,例如jar包,依赖包等, 最佳使用依赖管理代替在代码中包含依 赖,例如maven, composer, bundle, npm等 参考网站:http://www.gitignore.io/ https://github.com/github/gitignore
  15. 15. 什么时候不应该提交 在文件中只修改的一些空格或者换行,没有修改代 码逻辑 你根据自己环境修改了代码配置,例如数据库配置 你的修改的代码只是中间产物而不是原始代码 你修改的代码仅仅是为了调试使用,例如var_dump 语句
  16. 16. 什么是优秀的提交 每次提交只做一个修改 每次提交要包含完整的修改 写好注释,说明你修改了什么 注释说明为什么做了这个修改 不要提交被注释的代码

×