前言
- Git相关操作总结
- 2018-7-14, 联创团队分享
- 文中部分图片见文末参考链接
正文
一. 基本概念
版本控制
- 本地版本控制: 单机
- 集中式版本控制系统: 多人合作; 中央服务器;需要联网(查看提交历史等)
- 分布式版本控制系统: 多人合作; 每一个客户端都是一个完整的仓库镜像
- 集中式与分布式区别: 集中式中由中央服务器保存所有的提交记录,存在宕机和数据丢失风险,常见如:SVN;分布式中,不用担心因为服务器故障造成的数据丢失,常见如:Git
几个基本概念
- 工作区(Working): 就是平时我们可见的部分,一般是对项目中某个版本独立提取出来
- 暂存区(索引)(Stage): 保存了下一次将提交的文件列表信息
- Git仓库(.git): 是最重要的部分,我们所有的操作(版本控制,提交历史等)都基于Git仓库
-
为了理解的更形象,可以结合下面这张图,将一个版本库划分为三个部分
文件的几个状态
- 未跟踪(Untracked): 从未add的文件
- 已修改(Modified): 修改了一个已add文件之后,还未重新add(处于工作区)
- 已暂存(Staged): 修改了一个文件,并add,但是还未commit(处于暂存区)
- 已提交(Commited): 修改了一个文件之后,add并commit(处于版本库)
HEAD与分支
- HEAD: 一个指针,始终指向当前活跃分支
- 分支: 实际上也是一个可变指针,始终指向最后一次commit的对象,没commit一次,分支就前进一次
- 话不多说,看图
-
分支始终指向该分支上最近一次commit
-
HEAD始终指向当前分支
- master
每次创建仓库的时候,都会默认创建的一个分支
- HEAD^, HEAD^^, HEAD~100
- HEAD^ : 表示上一个版本
- HEAD^^ : 表示上两个版本
- HEAD~100: 表示上100个版本(当然,如果不闲麻烦的话,也可以写100个
^
)- 所谓的上一次,即在当前分支上,按照提交顺序区分的
二. 基本操作
git status
基本输出如下:
2.首先能够看出的信息是当前处于哪个分支上,接下来是上面所介绍的文件处于什么状态,然后是一些命令提示,可以怎么操作,基本比较简单
-
git status -s : 简化命令输出;只输出文件状态
-
git status -sb: 简化命令输出;只输出当前所处分支和文件状态(这个命令比较形象...:)
git log
- 查看提交日志,确切的说查看当前分支之前的提交日志
- git log --oneline: 简化输出
- git log --graph: 图形界面输出
- git --oneline --graph: 合用
- git log -p [-n]: 可以查看每一步完整的提交区别,使用
-n
参数,表示显示最近n次 - git reflog : 记录每一次命令,这个操作主要是用于当回退到某一版本的时候,想要回到未回退前的版本,但是这时候用
git log
只能显示出当前版本之前commit id,看不到回退前的commit id,此时就可以用此命令查看命令历史
撤销操作
我们平时所需要用到的撤销操作主要是针对: 工作区内容撤销,暂存区内容撤销,分支上的版本回退;分别对应文件所处的几种状态
- 工作区内容撤销
- 主要用于当工作区内容被误修改或者无效修改时,需要清除修改的工作区内容,但是该操作需谨慎,因为无法恢复
- git checkout -- file : 撤销对file文件在工作区的修改;如果想要一次性撤销对工作区的内容修改,可以使用通配符,
git checkout -- .
- 需要注意的是该操作只对已追踪文件起作用,对于未追踪的文件(Untracked)(即新建的文件,没有add的文件)是无法用
git checkout -- file
来撤销的;对于这些文件需要手动rm
- 暂存区内容撤销
- 暂存区就是说已经add,还未commit的文件;
- git reset HEAD [file] : 撤销暂存区修改,此时即将上次add到暂存区的内容(还未commit)重新回退到工作区;实际上是版本回退的一个变种使用
- 版本回退
- 当已经将修改commit到分支上时,如果要回退,只能回退版本了
- git reset --hard commit_id : 将暂存区的内容回滚到commit_id的提交,同时这里加了--hard参数,表示回滚工作去为commit_id内容;需要注意的是,如果此时工作区有未追踪的内容,那么其将丢失(简单来说这条命令会同时回滚暂存区和工作区)
- git reset --soft commit_id : 加上--soft指令后,暂存区和工作区的内容都不会改变,只是单纯的混滚分支和HEAD到commit_id
- git reset commit_id : 如果没有加参数(实际上是有参数的,默认参数为--mixed),此时会将暂存区内容回滚,但是工作区不受影响
-
可以结合下图来理解和记忆
- 关于回退的几点建议
- 回退之前考虑清清楚,对于Untracked文件的某些回退操作是无法恢复的
- 弄清楚命令的作用效果再使用,特别是在共享分支上的操作
diff操作
- 之所以将这个命令单独提出来,是因为这个命令是很有用的
- git diff : 比较工作区和暂存区的区别(也可以比较特定的文件: git diff file (仍然是工作区和暂存区中file内容的比较))
- git diff --cached : 比较的是暂存区和版本库最后一个版本的区别
- git diff HEAD : 比较的是工作目录树(包括暂存区和工作区)和版本库最后一个版本的区别
- git diff commit_id -- file : 具体文件的比较(没有加具体文件时比较的所有)比较版本号为commit_id的file文件和当前工作区的file文件的内容区别
分支操作
- 分支在我们日常开发中是很重要的概念,特别是当项目变得很大,版本迭代很快时,管理好分支显得尤为重要
- 区分本地分支和远程分支
- 远程分支: 远程仓库中的分支;所谓的远程分支就是从本地推送到远程仓库时指定的如:
git push origin master
(创建远程分支master,并将当前分支内容推送到远程master分支)或者git push origin dev
(创建远程分支dev,并将当前分支内容推送到远程dev分支)(注意: 可以指定推送到那个分支,如果没有该远程分支,将创建该远程分支)- 本地分支:
- git ls-remote : 列出远程分支
- git branch : 不带参数时,只是列出本地分支
- git branch --all : 列出所有分支,包括远程分支
- Clone仓库后的分支
多人合作开发时,一般会有master,dev等几种主干和长期分支(关于这些稍后讲解);当我们刚开始上手一个项目时,往往都不是从一个新项目开始,当Clone下代码库之后,会默认创建一个本地master分支,与远程的master分支同步,如下
- 但是实际上我们需要在dev分支上进行开发,而且dev分支往往也是最新的;因此此时我们需要切换到dev分支,使用命令
git checkout dev
,该命令可以远程的dev分支在本地变得可追踪(track),与之具有相同效果的命令还有git checkout --track origin/dev
- 之后,我们可以在dev分支上再创建自己的个人分支开发,每完成一个部分之后merge到dev并推送到远程(git push origin dev)
- 上面是我们接手一个项目时的大致流程,但是实际上其中还有很多比较坑的地方,比如说冲突...
- 推送到远程的时候先diff一下,再次确认提交的文件;
冲突处理
- 冲突:
- 冲突的出现一般是在不同分支上修改了同一个文件,不同的分支可以是本地的不同分支,也可以是不同客户端的分支
- 解决冲突的一般是更新代码后手动解决之后再提交
- 常见场景是,如上在dev分支上开发时,当需要推送到远程时,如果远程的dev分支比本地dev分支新,那么推送就会失败;所以一般情况下,推送到远程之前,先pull更新一下代码,如果有冲突手动解决之后再提交即可(也可以使用fetch)(关于二者的区别,参见博客)
gitignore文件的编写
- 编写规范
- 所有空行或者以 # 开头的行都会被 Git 忽略
- 可以使用标准的 glob 模式匹配
- 匹配模式可以以(/)开头防止递归
- 匹配模式可以以(/)结尾指定目录
- 要忽略指定模式以外的文件或目录,可以在模式前加上惊叹号(!)取反
示例如下:
# 忽略所有的.a文件
*.a
# 但是不能忽略lib.a,即使上面使用了.a来忽略所有.a文件
!lib.a
# 只是忽略当前目录下TODO文件,而不忽略类似subdir/TODO
/TODO
# 忽略所有在build/中的文件
build/
# 忽略doc/notes.txt之类文件,但是不忽略如doc/server/arch.txt之类的文件
doc/*.txt
# 忽略在doc/目录下所有的.pdf文件,包括doc子目录下的.pdf文件也会被忽略
doc/**/*.pdf
三. Git常见分支模型:GitFlow
-
先赋一张经典的图
- 该分支模型是常见也是用的最多的一种,不难理解;但是并不是每一个部分都是必须的,可以根据实际需要选择
- master: 只用于发布新版本
- develop: 开发主分支,每个人可以有自己的分支
- hotfix: bug修复,短期存在,merge到dev和master
- feature: 新特性开发分支,短期存在,merge到dev
四. 其他
只是想分享一些其他的东西 :)
- shell脚本
- 补丁: 使用场景之一是,当你发现项目中有bug,但是你没有修改权限时,此时可以使用文件补丁的形式发给leader,显得专业一些