Git 学习笔记

本文最后更新于:2022年1月30日 上午

Git 学习笔记

整理作者:pkufzh (Small Shrimp)

本浓缩版 Git 学习笔记全部来自 廖雪峰老师 的官方网站:点击跳转

非常感谢廖老师生动有趣的 Git 教程!在此膜拜 Linus 大神!

Git 简介

Git 是什么?What is Git?

Git 是目前世界上最先进分布式版本控制系统(没有之一!)。

Git 有什么特点?简单来说就是:高端大气上档次!

安装 Git

最早 Git 是在 Linux 上开发的,很长一段时间内,Git 也只能在 Linux 和 Unix 系统上跑。不过,慢慢地有人把它移植到了 Windows 上。现在,Git 可以在 Linux、Unix、Mac 和 Windows 这几大平台上正常运行了。

要使用 Git ,第一步当然是安装 Git 了。根据你当前使用的平台进行安装:

具体步骤参考:Git 安装教程

最新发布版本:Git Newest Release

下面正式开始教程内容~

1 创建版本库

什么是版本库呢?版本库又名仓库,英文名 repository,你可以简单理解成一个目录,这个目录里面的所有文件都可以被 Git 管理起来,每个文件的修改、删除,Git 都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。

所以,创建一个版本库非常简单:

  • 首先,选择一个合适的地方,创建一个空目录:
1
2
3
4
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit

pwd 命令用于显示当前目录。

如果你使用 Windows 系统,为了避免遇到各种莫名其妙的问题,请确保目录名(包括父目录)不包含中文

  • 第二步,通过git init命令把这个目录变成Git可以管理的仓库:
1
2
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/

瞬间 Git 就把仓库建好了,而且告诉你是一个空的仓库(empty Git repository),细心的读者可以发现当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把 Git 仓库给破坏了。

如果你没有看到.git目录,那是因为这个目录默认是隐藏的,用ls -ah命令就可以看见。

把文件添加到版本库

使用Windows的童鞋要特别注意:

千万不要使用Windows自带的 记事本 编辑任何文本文件。原因是 Microsoft 开发记事本的团队使用了一个非常弱智的行为来保存 UTF-8 编码的文件,他们自作聪明地在每个文件开头添加了 0xefbbbf(十六进制)的字符,你会遇到很多不可思议的问题,比如,网页第一行可能会显示一个“?”,明明正确的程序一编译就报语法错误,等等,都是由记事本的弱智行为带来的。建议你下载 Visual Studio Code 代替记事本,不但功能强大,而且免费!

两个步骤:

  • 初始化一个Git仓库,使用git init命令。

  • 添加文件到Git仓库,分两步:

    • 使用命令git add,注意,可反复多次使用,添加多个文件;
    • 使用命令git commit -m,完成。

2 时光机穿梭

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

版本回退

  • HEAD指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id
  • 穿梭前,用git log可以查看提交历史,以便确定要回退到哪个版本。
  • 要重返未来,用git reflog查看命令历史,以便确定要回到未来的哪个版本。

工作区和暂存区

Git 和其他版本控制系统如 SVN 的一个不同之处就是有暂存区的概念。

工作区(Working Directory)

就是你在电脑里能看到的目录,比如我的learngit文件夹就是一个工作区:

版本库(Repository)

工作区有一个隐藏目录.git,这个不算工作区,而是 Git 的版本库。

Git 的版本库里存了很多东西,其中最重要的就是称为 stage(或者叫 index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD

分支和HEAD的概念我们以后再讲。

前面讲了我们把文件往 Git 版本库里添加的时候,是分两步执行的:

  • 第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;

  • 第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建 Git 版本库时,Git 自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。

你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。

管理修改

怎么提交第二次修改呢?你可以继续git addgit commit,也可以别着急提交第一次修改,先git add第二次修改,再git commit,就相当于把两次修改合并后一块提交了:

  • 第一次修改 -> git add -> 第二次修改 -> git add -> git commit

现在,你又理解了Git是如何跟踪修改的,每次修改,如果不用git add到暂存区,那就不会加入到commit中。

撤销修改

  • 场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file

  • 场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD,就回到了场景1,第二步按场景1操作。

  • 场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。

删除文件

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

3 远程仓库

  • 第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsaid_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:
1
$ ssh-keygen -t rsa -C "youremail@example.com"

你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。

如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsaid_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。

  • 第2步:登陆 GitHub,打开 “Account settings”,“SSH Keys” 页面:

然后,点 “Add SSH Key”,填上任意 Title,在 Key 文本框里粘贴id_rsa.pub文件的内容即可。

为什么 GitHub 需要SSH Key呢?因为 GitHub 需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub 只要知道了你的公钥,就可以确认只有你自己才能推送。

当然,GitHub 允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到 GitHub,就可以在每台电脑上往 GitHub 推送了。

最后友情提示,在 GitHub 上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。

如果你不想让别人看到Git库,有两个办法,一个是交点保护费,让 GitHub 把公开的仓库变成私有的,这样别人就看不见了(不可读更不可写)。另一个办法是自己动手,搭一个Git服务器,因为是你自己的Git服务器,所以别人也是看不见的。这个方法我们后面会讲到的,相当简单,公司内部开发必备。

“有了远程仓库,妈妈再也不用担心我的硬盘了。”——Git点读机

添加远程库

  • 要关联一个远程库,使用命令git remote add origin git@server-name:path/repo-name.git

  • 关联一个远程库时必须给远程库指定一个名字origin是默认习惯命名;

  • 关联后,使用命令git push -u origin master第一次推送 master 分支的所有内容;

  • 此后,每次本地提交后,只要有必要,就可以使用命令git push origin master推送最新修改;

分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在,也就是有没有联网都可以正常工作,而 SVN 在没有联网的时候是拒绝干活的!当有网络时,再把本地提交推送一下就完成了同步,真是太方便了!

从远程库克隆

要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone命令克隆。

当然,Git 支持多种协议,包括https,但ssh协议速度最快!

4 分支管理

分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习 Git 的时候,另一个你正在另一个平行宇宙里努力学习 SVN 。如果两个平行宇宙互不干扰,那对现在的你也没啥影响。不过,在某个时间点,两个平行宇宙合并了,结果,你既学会了 Git 又学会了 SVN!

分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。

现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。

创建与合并分支

Git 鼓励大量使用分支:

  • 查看分支:git branch

  • 创建分支:git branch

  • 切换分支:git checkout或者git switch

  • 创建+切换分支:git checkout -b或者git switch -c

  • 合并某分支到当前分支:git merge

  • 删除分支:git branch -d

解决冲突

当 Git 无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。

解决冲突就是把 Git 合并失败的文件手动编辑为我们希望的内容,再提交。

git log --graph --pretty=oneline --abbrev-commit命令可以看到分支合并图。

分支管理策略

合并分支 & 记录分支信息

通常,合并分支时,如果可能,Git 会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。

如果要强制禁用Fast forward模式,Git 就会在 merge 时生成一个新的 commit,这样,从分支历史上就可以看出分支信息。

准备合并dev分支,请注意--no-ff参数,表示禁用Fast forward

1
2
3
4
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)

因为本次合并要创建一个新的 commit,所以加上-m参数,把 commit 描述写进去。

合并后,我们用git log看看分支历史:

1
2
3
4
5
6
7
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
...

可以看到,不使用Fast forward模式,merge 后就像这样:

分支策略

在实际开发中,我们应该按照几个基本原则进行分支管理:

首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;

那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如 1.0 版本发布时,再把dev分支合并到master上,在master分支发布 1.0 版本;

你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。

所以,团队合作的分支看起来就像这样:

Git 分支十分强大,在团队开发中应该充分应用。

合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。

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 的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。

5 标签管理

tag 就是一个让人容易记住的有意义的名字,它跟某个 commit 绑在一起。

创建标签

  • 命令git tag用于新建一个标签,默认为HEAD,也可以指定一个 commit id;
  • 命令git tag -a -m "blablabla..."可以指定标签信息;
  • 命令git tag可以查看所有标签。

操作标签

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

6 使用 Github

  • 在 GitHub 上,可以任意 Fork 开源仓库;
  • 自己拥有 Fork 后的仓库的读写权限;
  • 可以推送 pull request 给官方仓库来贡献代码。

7 自定义 Git

安装 Git一节中,我们已经配置了user.nameuser.email,实际上,Git还有很多可配置项。

比如,让 Git 显示颜色,会让命令输出看起来更醒目:

1
$ git config --global color.ui true

忽略特定文件

在 Git 工作区的根目录下创建一个特殊的.gitignore文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件。

不需要从头写.gitignore文件,GitHub 已经为我们准备了各种配置文件,只需要组合一下就可以使用了。所有配置文件可以直接在线浏览:https://github.com/github/gitignore

  • 忽略某些文件时,需要编写.gitignore
  • 把指定文件排除在.gitignore规则外的写法就是!+文件名,所以,只需把例外文件添加进去即可。
  • .gitignore文件本身要放到版本库里,并且可以对.gitignore做版本管理!

配置别名

给 Git 配置好别名,就可以输入命令时偷个懒。我们鼓励偷懒。

  • 每个仓库的 Git 配置文件都放在.git/config文件中:
  • 当前用户的 Git 配置文件放在用户主目录下的一个隐藏文件.gitconfig中:
1
2
3
4
5
6
7
8
9
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = your@email.com

配置别名也可以直接修改这个文件,如果改错了,可以删掉文件重新通过命令配置。

搭建 Git 服务器

  • 搭建Git服务器非常简单,通常10分钟即可完成;
  • 要方便管理公钥,用Gitosis
  • 要像SVN那样变态地控制权限,用Gitolite

8 使用 SourceTree

使用 SourceTree 可以以图形界面(GUI界面)操作 Git,省去了敲命令的过程,对于常用的提交、分支、推送等操作来说非常方便。

注意:SourceTree 使用 Git 命令执行操作,出错时,仍然需要阅读 Git 命令返回的错误信息。

拓展资料

下面是一些与 Git 相关的学习教程:

其他有趣的 Git & Github 学习资料:

  • Github 中文社区

  • GitHub官方10分钟入门教程

    GitHub 官方出品~教学内容包含:新建仓库、新建分支、修改提交 (Commit) 以及请求拉取 (Pull Request)。 原文为英文版,中文翻译可以点击此处

  • GitHub秘籍

    主要包含gitgithub常用技巧,适合有一定基础的同学想要进一步掌握一些高级技巧~


^_^ This is the END of the page / document. Thank you for reading!

Finished by pkufzh (Small Shrimp) on 2022/01/19.


Who am I? A happy shrimp from Peking University!

本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!