《git入门ppt》由会员分享，可在线阅读，更多相关《git入门ppt（31页珍藏版）》请在金锄头文库上搜索。
1、协作开发中的质量如何保证？ 版本控制 版本控制是一种记录一个或若干文件内容变化 ，以便将来查阅特定版本修订情况的系统。 分类： 本地版本控制系统 集中化的版本控制系统 分布式版本控制系统 GIT分布式版本控制系统 GIT简史 早期Linux的开发人员是使用BitKeeper来管理 版本控制和维护程式码。2005年的时候，开发 BitKeeper的公司同Linux内核开源社区结束合 作关系，并收回使用BitKeeper的权利。 Torvalds开始着手开发Git来替代BitKeeper。 随着Git的快速发展，很多有名的软件都使用 Git来进行版本控制。 GIT特点 多数操作仅添加数据 直接记录
2、快照，而非比较差异 GIT特点（续） 近乎所有操作都是本地执行 (离线操作) 时刻保持数据完整性(SHA-1 哈希值) 文件流转的三个工作区域: 工作目录,暂存区域,以及 本地仓库 工作目录,暂存区,和本地仓库 注：Stage 和 index 是同一个概念 Git 工作流程 在工作目录中修改某些文件。 对修改后的文件进行快照，然后保存到暂存区 域。 提交更新，将保存在暂存区域的文件快照永久 转储到 Git 目录中。 git对象 Git 是一套内容寻址文件系统。这种说法的意思是，Git 从 核心上来看不过是简单地存储键值对（key-value）。它 允许插入任意类型的内容，并会返回一个键值，通过
3、该键 值可以在任何时候再取出该内容。 安装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项
4、目的配置 #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 命令可以怎么用，运行： $ g
5、it 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 将暂存区域的文件提交到版本
6、库 ,(如果使用-a 选项已跟踪已修改未暂存的文件 也会提交) #git commit -m “add hello world module“ 提交消息（commit message） 使用 git commit会提示写提交消息 或者 git commit -m “msg” 建议的消息模板: 本次更新的简要描述（50 个字符以内） 如果必要，此处展开详尽阐述。段落宽度限定在 72 个字符以内。 某些情况下，第一行的简要描述将用作邮件标题，其余部分作为邮件正文。 其间的空行是必要的，以区分两者（当然没有正文另当别论）。 如果并在一起，rebase 这样的工具就可能会迷惑。 另起空行后，再进一步补
7、充其他说明。 - 可以使用这样的条目列举式。 - 一般以单个空格紧跟短划线或者星号作为每项条目的起始符。每个条目间用一空行隔开。 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 wor
8、ld 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 合并分支 #g
9、it 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两 个操作 #g
10、it 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 ，是将
11、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或多个字符,但不包含表
12、示文件目录的反斜杠 / ； ?匹配单个字符；方括号表示匹配其中的一个字符。 *.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支持多种开发流程(
13、Git Flow)，典型的有： 集中式工作流（如下图） 集成管理员工作流 司令官与副官工作流 git使用惯例 要早提交，常提交，并且不要觉得麻烦 1. 每个提交的修订都会为你提供一个还原点。如果你完全把 代码搞砸了（没骗你，我们都这么做过），你是希望恢复 到一个小时前的工作还是一周前的工作？ 2. 合并文件时会出现的危险会随着时间不断增加。合并文件 一直很麻烦。如果你不是每天都保持提交代码，某一天你 会突然发现你和其他人的更改内容会有50多个冲突。你不 会为此感到高兴的。 3. 它促使你把任务分离成分散的单元。通常人们都是快完成 的时候才提交的，因为他们想把代码做成一个完整的逻辑 单元模块。不
14、过庞大的任务不可避免地要分离出较小的分 散功能，而频繁地提交它们会使你更了解它们，你可以一 个个地构建并提交。 git使用惯例（续） 写提交信息时一定要认真 解释清楚为什么要提交新的代码，同一个程序员之后提交信息绝 不能和前面的完全相同. 这里列出一些提交信息的反面教材： 1. 什么也没做 2. 能跑了 3. 解决了一些混帐问题 4. 解决了 5. 改进了一点bug 6. 上传了 7. 排字错误 8. 修订1024 git使用惯例（续） 常用git status查看工作目录状态 提交前要检查你更改了什么(使用git diff) 不要上传你自己的用户设置 附属文件也要集成在一起，比如更新了新的第 三方库(无源码的.a .so文件) 临时文件，编译生成的文件不要放进源代码管 理软件里(使用.gitignore来忽略)，也不要通过 复制或者打包文件来进行备份
