联系我

Git知识拾遗

2020.05.18

前言

Git版本操作无论是对于开发或者其他一些版本管理操作都有极大的裨益,用好Git能显著提升我们的工作效率,这里将常用的Git概念和指令重新梳理一下,以求在日常的工作使用当中可以方便查阅且能进一步巩固Git相关的知识结构。

创建版本库

  • 【指令】通过git init命令把这个目录变成Git可以管理的仓库
  • 【约定】所有的版本控制系统,其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从100KB改成了120KB,但到底改了啥,版本控制系统不知道,也没法知道。

状态查询观察

  • 要随时掌握工作区的状态,使用git status命令。
  • 如果git status告诉你有文件被修改过,用git diff可以查看修改内容。

版本回退

  • 【commit介绍】每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”,这个快照在Git中被称为commit。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit恢复,然后继续工作,而不是把几个月的工作成果全部丢失。
  • 【查看版本历史】git log命令显示从最近到最远的提交日志。如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline参数
  • 【解惑】为什么commit id需要用这么一大串数字表示呢?因为Git是分布式的版本控制系统,后面我们还要研究多人在同一个版本库里工作,如果大家都用1,2,3……作为版本号,那肯定就冲突了。
  • 【约定】在Git中,用HEAD表示当前版本,上一个版本就是HEAD,上上一个版本就是HEAD,当然往上100个版本写100个比较容易数不过来,所以写成HEAD~100。
  • 【版本回退】如回到上一个版本:git reset --hard HEAD^,如果又想回到之前最新的版本怎么办?只要命令行窗口还没有被关掉,就可以找到前面的那个版本的commit id,再reset回去就好了。但万一命令窗口关了,会话没了怎么办,也是有后悔药可以吃的,Git提供了一个命令git reflog用来记录你的每一次命令,通过这个指令也可以看到你想找的最新版本的commit id。

工作和暂存区

  • 【约定】git add命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行git commit就可以一次性把暂存区的所有修改提交到分支。

管理修改

  • 【约定】Git跟踪并管理的是修改,而非文件。
  • 【约定】每次修改,如果不用git add到暂存区,那就不会加入到commit中。

撤销修改

  • 【场景1】当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file。
  • 【场景2】当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD ,就回到了场景1,第二步按场景1操作。
  • 【场景3】已经提交了不合适的修改到版本库时,想要撤销本次提交,参考前面版本回退说明即可,不过前提是没有推送到远程库。

删除文件

  • 命令git rm用于删除一个文件。如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容。

添加远程库

  • 【约定】要关联一个远程库,使用命令git remote add origin git@server-name:path/repo-name.git
  • 【约定】远程库的名字就是origin,这是Git默认的叫法
  • 【约定】第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。
  • 【比较】分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在,也就是有没有联网都可以正常工作,而SVN在没有联网的时候是拒绝干活的!当有网络的时候,再把本地提交推送一下就能完成同步,非常方便!

从远程库克隆

  • 【约定】要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone命令克隆。
  • Git支持多种协议,包括https,但通过ssh支持的原生git协议速度最快。(使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。)

分支管理

  • 【类比】分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习Git的时候,另一个你正在另一个平行宇宙里努力学习SVN。如果两个平行宇宙互不干扰,那对现在的你也没啥影响。不过,在某个时间点,两个平行宇宙合并了,结果,你既学会了Git又学会了SVN!
  • 【解决痛点】假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
  • 【优势】创建、切换和删除分支都很快,不像SVN

创建与合并分支

  • 【约定】HEAD指向的就是当前分支,分支名指向提交:一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点
  • 【Fast-forward】Fast-forward可以简单理解为合并分支时候直接移动当前分支的指针到另外分支的提交节点上,由于只修改指针就可以,速度非常快
  • 【查看分支】查看分支:git branch
  • 【创建分支】创建分支:git branch <name>
  • 【切换分支】切换分支:git checkout <name>或者git switch <name>
  • 【创建&切换】创建+切换分支:git checkout -b <name>或者git switch -c <name>
  • 合并某分支到当前分支:git merge <name>
  • 【删除分支】删除分支:git branch -d <name>
  • 【补充】详细图文看这里:跳转链接

合并冲突

  • 【定义】当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。
  • 【识记】合并过程中的打印信息会提示我们哪里合并冲突了,git status也可以告诉我们冲突的文件
  • 【约定】Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容
  • 【识记】用git log --graph命令可以看到分支合并图。

分支管理策略

  • 【经验】合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
  • 【原则】master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。图示如下:
    分支管理

bug修复

  • 【约定】修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
  • 【经验】当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场;
  • 【经验】在master分支上修复的bug,想要合并到当前dev分支,可以用git cherry-pick 命令,把bug提交的修改“复制”到当前分支,避免重复劳动。

详情参见:跳转链接

feature分支

  • 【经验】开发一个新feature,最好新建一个分支;
  • 【约定】如果要丢弃一个没有被合并过的分支,可以通过git branch -D 强行删除。

多人协作

  • 【约定】查看远程库信息,使用git remote -v;
  • 【约定】本地新建的分支如果不推送到远程,对其他人就是不可见的;
  • 【经验】从本地推送分支,使用git push origin branch-name,如果推送失败,先用git pull抓取远程的新提交;
  • 【约定】在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;
  • 【约定】建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name;
  • 【经验】从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。

Rebase

  • 【定义】rebase操作可以把本地未push的分叉提交历史整理成直线;
  • 【缘由】rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。

标签管理

  • 【定义】发布一个版本时,我们通常先在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。
  • 【区别】Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。
  • 【为什么tag】tag就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起。

创建标签

  • 【约定】命令git tag <tagname>用于新建一个标签,默认为HEAD,也可以指定一个commit id;
  • 【约定】命令git tag -a <tagname> -m "blablabla..."可以指定标签信息。如:git tag -a v0.1 -m "version 0.1 released" 1094adb,其中用-a指定标签名,-m指定说明文字,最后的一串hash码代表commit id
  • 命令git tag可以查看所有标签。

操作标签

  • 【约定】命令git push origin <tagname>可以推送一个本地标签;
  • 【约定】命令git push origin --tags可以推送全部未推送过的本地标签;
  • 【约定】命令git tag -d <tagname>可以删除一个本地标签;
  • 【约定】命令git push origin :refs/tags/<tagname>可以删除一个远程标签。

忽略特殊文件

  • 【约定】忽略某些文件时,需要编写.gitignore。
  • 【约定】.gitignore文件本身要放到版本库里,并且可以对.gitignore做版本管理!
  • 【注意】使用Windows的童鞋注意了,如果你在资源管理器里新建一个.gitignore文件,它会非常弱智地提示你必须输入文件名,但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。
  • 【操作】可以用git check-ignore命令检查gitignore是否写的有问题。
  • 【操作】如果你确实想添加某文件,可以用-f强制添加到Git,如:git add -f App.class。

最后

  • 【cheat sheet】[文档链接](