Git基本操作

前言

  • Git相关操作总结
  • 2018-7-14, 联创团队分享
  • 文中部分图片见文末参考链接

正文

一. 基本概念

版本控制

  1. 本地版本控制: 单机
  2. 集中式版本控制系统: 多人合作; 中央服务器;需要联网(查看提交历史等)
  3. 分布式版本控制系统: 多人合作; 每一个客户端都是一个完整的仓库镜像
  4. 集中式与分布式区别: 集中式中由中央服务器保存所有的提交记录,存在宕机和数据丢失风险,常见如:SVN;分布式中,不用担心因为服务器故障造成的数据丢失,常见如:Git

几个基本概念

  1. 工作区(Working): 就是平时我们可见的部分,一般是对项目中某个版本独立提取出来
  2. 暂存区(索引)(Stage): 保存了下一次将提交的文件列表信息
  3. Git仓库(.git): 是最重要的部分,我们所有的操作(版本控制,提交历史等)都基于Git仓库
  • 为了理解的更形象,可以结合下面这张图,将一个版本库划分为三个部分


    Git基本操作_第1张图片
    Git分区.png

文件的几个状态

  1. 未跟踪(Untracked): 从未add的文件
  2. 已修改(Modified): 修改了一个已add文件之后,还未重新add(处于工作区)
  3. 已暂存(Staged): 修改了一个文件,并add,但是还未commit(处于暂存区)
  4. 已提交(Commited): 修改了一个文件之后,add并commit(处于版本库)

HEAD与分支

  1. HEAD: 一个指针,始终指向当前活跃分支
  2. 分支: 实际上也是一个可变指针,始终指向最后一次commit的对象,没commit一次,分支就前进一次
  • 话不多说,看图
  • 分支始终指向该分支上最近一次commit


    Git基本操作_第2张图片
    Git_指针_1.png
  • HEAD始终指向当前分支


    Git基本操作_第3张图片
    Git_指针_2.png
  • master

每次创建仓库的时候,都会默认创建的一个分支

  • HEAD^, HEAD^^, HEAD~100
  1. HEAD^ : 表示上一个版本
  2. HEAD^^ : 表示上两个版本
  3. HEAD~100: 表示上100个版本(当然,如果不闲麻烦的话,也可以写100个^)
  4. 所谓的上一次,即在当前分支上,按照提交顺序区分的
Git基本操作_第4张图片
Git_指针_3.png

二. 基本操作

git status

  1. 基本输出如下:


    Git基本操作_第5张图片
    git_status_1.png

    2.首先能够看出的信息是当前处于哪个分支上,接下来是上面所介绍的文件处于什么状态,然后是一些命令提示,可以怎么操作,基本比较简单

  • git status -s : 简化命令输出;只输出文件状态


    git_status_2.png
  • git status -sb: 简化命令输出;只输出当前所处分支和文件状态(这个命令比较形象...:)


    git_status_3.png

git log

  1. 查看提交日志,确切的说查看当前分支之前的提交日志
  • git log --oneline: 简化输出
  • git log --graph: 图形界面输出
  • git --oneline --graph: 合用
  • git log -p [-n]: 可以查看每一步完整的提交区别,使用-n参数,表示显示最近n次
  • git reflog : 记录每一次命令,这个操作主要是用于当回退到某一版本的时候,想要回到未回退前的版本,但是这时候用git log只能显示出当前版本之前commit id,看不到回退前的commit id,此时就可以用此命令查看命令历史

撤销操作

我们平时所需要用到的撤销操作主要是针对: 工作区内容撤销,暂存区内容撤销,分支上的版本回退;分别对应文件所处的几种状态

  • 工作区内容撤销
  1. 主要用于当工作区内容被误修改或者无效修改时,需要清除修改的工作区内容,但是该操作需谨慎,因为无法恢复
  2. git checkout -- file : 撤销对file文件在工作区的修改;如果想要一次性撤销对工作区的内容修改,可以使用通配符,git checkout -- .
  3. 需要注意的是该操作只对已追踪文件起作用,对于未追踪的文件(Untracked)(即新建的文件,没有add的文件)是无法用git checkout -- file来撤销的;对于这些文件需要手动rm
  • 暂存区内容撤销
  1. 暂存区就是说已经add,还未commit的文件;
  2. git reset HEAD [file] : 撤销暂存区修改,此时即将上次add到暂存区的内容(还未commit)重新回退到工作区;实际上是版本回退的一个变种使用
  • 版本回退
  1. 当已经将修改commit到分支上时,如果要回退,只能回退版本了
  2. git reset --hard commit_id : 将暂存区的内容回滚到commit_id的提交,同时这里加了--hard参数,表示回滚工作去为commit_id内容;需要注意的是,如果此时工作区有未追踪的内容,那么其将丢失(简单来说这条命令会同时回滚暂存区和工作区)
  3. git reset --soft commit_id : 加上--soft指令后,暂存区和工作区的内容都不会改变,只是单纯的混滚分支和HEAD到commit_id
  4. git reset commit_id : 如果没有加参数(实际上是有参数的,默认参数为--mixed),此时会将暂存区内容回滚,但是工作区不受影响
  • 可以结合下图来理解和记忆


    Git基本操作_第6张图片
    图解Git_1.png
  • 关于回退的几点建议
  1. 回退之前考虑清清楚,对于Untracked文件的某些回退操作是无法恢复的
  2. 弄清楚命令的作用效果再使用,特别是在共享分支上的操作

diff操作

  1. 之所以将这个命令单独提出来,是因为这个命令是很有用的
  2. git diff : 比较工作区和暂存区的区别(也可以比较特定的文件: git diff file (仍然是工作区和暂存区中file内容的比较))
  3. git diff --cached : 比较的是暂存区和版本库最后一个版本的区别
  4. git diff HEAD : 比较的是工作目录树(包括暂存区和工作区)和版本库最后一个版本的区别
  5. git diff commit_id -- file : 具体文件的比较(没有加具体文件时比较的所有)比较版本号为commit_id的file文件和当前工作区的file文件的内容区别

分支操作

  • 分支在我们日常开发中是很重要的概念,特别是当项目变得很大,版本迭代很快时,管理好分支显得尤为重要
  • 区分本地分支和远程分支
  1. 远程分支: 远程仓库中的分支;所谓的远程分支就是从本地推送到远程仓库时指定的如:git push origin master(创建远程分支master,并将当前分支内容推送到远程master分支)或者git push origin dev(创建远程分支dev,并将当前分支内容推送到远程dev分支)(注意: 可以指定推送到那个分支,如果没有该远程分支,将创建该远程分支)
  2. 本地分支:
  3. git ls-remote : 列出远程分支
  4. git branch : 不带参数时,只是列出本地分支
  5. git branch --all : 列出所有分支,包括远程分支
  • Clone仓库后的分支
  1. 多人合作开发时,一般会有master,dev等几种主干和长期分支(关于这些稍后讲解);当我们刚开始上手一个项目时,往往都不是从一个新项目开始,当Clone下代码库之后,会默认创建一个本地master分支,与远程的master分支同步,如下


    Git基本操作_第7张图片
    Git分支_1.png
  2. 但是实际上我们需要在dev分支上进行开发,而且dev分支往往也是最新的;因此此时我们需要切换到dev分支,使用命令git checkout dev,该命令可以远程的dev分支在本地变得可追踪(track),与之具有相同效果的命令还有git checkout --track origin/dev
  3. 之后,我们可以在dev分支上再创建自己的个人分支开发,每完成一个部分之后merge到dev并推送到远程(git push origin dev)
  4. 上面是我们接手一个项目时的大致流程,但是实际上其中还有很多比较坑的地方,比如说冲突...
  5. 推送到远程的时候先diff一下,再次确认提交的文件;

冲突处理

  • 冲突:
  1. 冲突的出现一般是在不同分支上修改了同一个文件,不同的分支可以是本地的不同分支,也可以是不同客户端的分支
  2. 解决冲突的一般是更新代码后手动解决之后再提交
  3. 常见场景是,如上在dev分支上开发时,当需要推送到远程时,如果远程的dev分支比本地dev分支新,那么推送就会失败;所以一般情况下,推送到远程之前,先pull更新一下代码,如果有冲突手动解决之后再提交即可(也可以使用fetch)(关于二者的区别,参见博客)

gitignore文件的编写

  • 编写规范
  1. 所有空行或者以 # 开头的行都会被 Git 忽略
  2. 可以使用标准的 glob 模式匹配
  3. 匹配模式可以以(/)开头防止递归
  4. 匹配模式可以以(/)结尾指定目录
  5. 要忽略指定模式以外的文件或目录,可以在模式前加上惊叹号(!)取反
    示例如下:
# 忽略所有的.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

  • 推荐开源Gitignore文件编写

三. Git常见分支模型:GitFlow

  • 先赋一张经典的图


    Git基本操作_第8张图片
    Git_Flow_1.png
  1. 该分支模型是常见也是用的最多的一种,不难理解;但是并不是每一个部分都是必须的,可以根据实际需要选择
  • master: 只用于发布新版本
  • develop: 开发主分支,每个人可以有自己的分支
  • hotfix: bug修复,短期存在,merge到dev和master
  • feature: 新特性开发分支,短期存在,merge到dev

四. 其他

只是想分享一些其他的东西 :)

  • shell脚本
  • 补丁: 使用场景之一是,当你发现项目中有bug,但是你没有修改权限时,此时可以使用文件补丁的形式发给leader,显得专业一些

五. 参考链接

  • GitFlow
  • Git文档
  • Git高级
  • Git秘密
  • 图解Git

你可能感兴趣的:(Git基本操作)