资源预览内容
第1页 / 共31页
第2页 / 共31页
第3页 / 共31页
第4页 / 共31页
第5页 / 共31页
第6页 / 共31页
第7页 / 共31页
第8页 / 共31页
第9页 / 共31页
第10页 / 共31页
亲,该文档总共31页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
协作开发中的质量如何保证? 版本控制 版本控制是一种记录一个或若干文件内容变化 ,以便将来查阅特定版本修订情况的系统。 分类: 本地版本控制系统 集中化的版本控制系统 分布式版本控制系统 GIT分布式版本控制系统 GIT简史 早期Linux的开发人员是使用BitKeeper来管理 版本控制和维护程式码。2005年的时候,开发 BitKeeper的公司同Linux内核开源社区结束合 作关系,并收回使用BitKeeper的权利。 Torvalds开始着手开发Git来替代BitKeeper。 随着Git的快速发展,很多有名的软件都使用 Git来进行版本控制。 GIT特点 多数操作仅添加数据 直接记录快照,而非比较差异 GIT特点(续) 近乎所有操作都是本地执行 (离线操作) 时刻保持数据完整性(SHA-1 哈希值) 文件流转的三个工作区域: 工作目录,暂存区域,以及 本地仓库 工作目录,暂存区,和本地仓库 注:Stage 和 index 是同一个概念 Git 工作流程 在工作目录中修改某些文件。 对修改后的文件进行快照,然后保存到暂存区 域。 提交更新,将保存在暂存区域的文件快照永久 转储到 Git 目录中。 git对象 Git 是一套内容寻址文件系统。这种说法的意思是,Git 从 核心上来看不过是简单地存储键值对(key-value)。它 允许插入任意类型的内容,并会返回一个键值,通过该键 值可以在任何时候再取出该内容。 安装GIT 支持多种平台 Windows/MAC下 直接从官方网站:http:/git- 下载最 新二进制发行版 Linux下(以Debian/Ubuntu为例) $ apt-get install git 从官网下载源码自己编译安装 配置GIT 配置用户名称和电子邮件地址,以在commit log中体现出 来。 #git config -global user.name “zhangsan“ #git config -global user.email “zhangsan “ 查看已有的git配置信息 #git config -list 配置单个git项目的配置 #git config user.email “zhangsan “ 配置core.autocrlf Windows和Unix系统下文件换行的方式不同,因 此建议进行以下配置: windows系统下: #git config -global core.autocrlf true Unix类系统下: #git config -global core.autocrlf input 获取帮助 想了解 Git 的各式工具该怎么用,可以阅读它 们的使用帮助,方法有三: $ git help $ git -help $ man git- 比如,要学习 config 命令可以怎么用,运行: $ git help config 使用GIT仓库 在工作目录初始化新的git仓库: #mkdir hello #cd hello 该目录称为工作目录 #git init 将会在当前目录产生.git文件夹(即git目录) 创建一个bare仓库(无工作目录,一般在服务器上使用): #mkdir hello.git #cd hello.git #git init -bare Clone一个仓库 $git clone URL git add 和git commit $git add 将未跟踪或已修改的文件加入到暂存 区域 #git add hello.c $git commit 将暂存区域的文件提交到版本库 ,(如果使用-a 选项已跟踪已修改未暂存的文件 也会提交) #git commit -m “add hello world module“ 提交消息(commit message) 使用 git commit会提示写提交消息 或者 git commit -m “msg” 建议的消息模板: 本次更新的简要描述(50 个字符以内) 如果必要,此处展开详尽阐述。段落宽度限定在 72 个字符以内。 某些情况下,第一行的简要描述将用作邮件标题,其余部分作为邮件正文。 其间的空行是必要的,以区分两者(当然没有正文另当别论)。 如果并在一起,rebase 这样的工具就可能会迷惑。 另起空行后,再进一步补充其他说明。 - 可以使用这样的条目列举式。 - 一般以单个空格紧跟短划线或者星号作为每项条目的起始符。每个条目间用一空行隔开。 git status查看工作目录状态 三种文件状态: Changes to be committed Changes not staged for commit Untracked files git log显示提交日志 $ git log commit 96a8a6dff817ec66f44342007202690a93763949 Author: zhangsan Date: Mon Dec 9 21:52:11 2013 +0800 add hello world module mit hash(SHA-1 校验和) 2.作者的名字和电子邮件地址 3.提交时间 4.最后缩进一个段落显示提交说明 也可使用git自带的图形工具gitk(历史记录更直观) git分支 git branch分支操作 基于当前分支,新建一个名为develop的分支 #git branch develop 换到develop分支 #git checkout develop 简化上面两个操作为一个操作 #git checkout -b develop 从某个历史提交创建分支 #git checkout -b temp 8f7a493c 分支合并 Git merge 合并分支 #git checkout master 转到主分支 #git merge bugfix 合并1个bug修复分支 #git merge newfeature 合并1个新特征分支 与服务器同步 git push和git pull 为远程仓库(URL)添加一个别名: #git remote add origin userserver:/path/repo.git #git fetch origin 同步服务器上的数据到本地 #git merge origin/master 合并(一般是快进主分支) #git pull origin mater简化了git fetch和git merge两 个操作 #git push origin loacal_branch:remote_branch 更新远程仓库 #git push origin :serverfix 删除远程的serverfix分支 git diff比较差异 #git diff 比较的是工作区和暂存区的差别 #git diff -cached 比较的是暂存区和版本库的 差别 #git diff HEAD 可以查看工作区和版本库的差 别 每次commit后,git diff -cached没有内容,是 因为暂存区的内容已经更新到版本库中,因此 暂存区和版本库中的内容无差别 git reset撤销操作 git reset mixed ,是将git的HEAD变了,并根据 HEAD来更新暂存区,但文working tree的文件并没 有改变。 git reset soft . 实际上,是git reset mixed id 后,又做了一次git add git reset herd .是将git的HEAD变了,文件也变 了(相当于回到某个提交,之后的改变都将灰飞 烟灭)。 以上的1,2条用于重新整理提交,第3条用于放弃 之后的修改 注意: 一定要在理解了的基础上使用 .gitignore过滤文件 忽略规则 a.空行用于分割,便于阅读,#号开头表示注释,空行和 # 会被git忽略。 b.*号匹配文件或目录名中的0或多个字符,但不包含表示文件目录的反斜杠 / ; ?匹配单个字符;方括号表示匹配其中的一个字符。 *.ao 匹配 *.a *.o * foo0-9.c 匹配foo0.c foo1.c foo9.c c. 以反斜杠开头的表示只匹配当前目录下 /todo 匹配当前目录下的todo ,子目录下的todo不会匹配 d. 以反斜杠结尾的表示匹配目录 即 doc/ 忽略整个 doc目录 e.!对规则取反,即包含之前忽略掉的文件。如: *.html !index.html 表示除了名为index.html文件,其它的html文件均忽略(如果文件名 含#或!可使用转义,eg:#*#) 怎样进行团队协作开发 Git支持多种开发流程(Git Flow),典型的有: 集中式工作流(如下图) 集成管理员工作流 司令官与副官工作流 git使用惯例 要早提交,常提交,并且不要觉得麻烦 1. 每个提交的修订都会为你提供一个还原点。如果你完全把 代码搞砸了(没骗你,我们都这么做过),你是希望恢复 到一个小时前的工作还是一周前的工作? 2. 合并文件时会出现的危险会随着时间不断增加。合并文件 一直很麻烦。如果你不是每天都保持提交代码,某一天你 会突然发现你和其他人的更改内容会有50多个冲突。你不 会为此感到高兴的。 3. 它促使你把任务分离成分散的单元。通常人们都是快完成 的时候才提交的,因为他们想把代码做成一个完整的逻辑 单元模块。不过庞大的任务不可避免地要分离出较小的分 散功能,而频繁地提交它们会使你更了解它们,你可以一 个个地构建并提交。 git使用惯例(续) 写提交信息时一定要认真 解释清楚为什么要提交新的代码,同一个程序员之后提交信息绝 不能和前面的完全相同. 这里列出一些提交信息的反面教材: 1. 什么也没做 2. 能跑了 3. 解决了一些混帐问题 4. 解决了 5. 改进了一点bug 6. 上传了 7. 排字错误 8. 修订1024 git使用惯例(续) 常用git status查看工作目录状态 提交前要检查你更改了什么(使用git diff) 不要上传你自己的用户设置 附属文件也要集成在一起,比如更新了新的第 三方库(无源码的.a .so文件) 临时文件,编译生成的文件不要放进源代码管 理软件里(使用.gitignore来忽略),也不要通过 复制或者打包文件来进行备份
收藏 下载该资源
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号