常用链接
常用命令可查表：Git-CheatSheet
官方文档 也是很好的学习的手段。
前言
先说一个概念：Git 是目前最流行的版本管理系统，学会 Git 几乎成了开发者的必备技能。
如果你看不懂这句话，你可以从字面意思理解“版本管理系统”：多个开发者在同一个软件的基础上，开发了不同的版本，他们可以通过 Git 方便、严谨的实现上传、下载、比对、合并代码间的冲突等操作。
而我们最常用的把代码放到 GitHub（或其他 Git 服务器）上的操作，可以把远程服务器也看做一个开发者（虽然他什么也不会修改），我们每次开发完以后，就会将代码上传给他。
Git 入门
在本地 Git 新建仓库
入门，首先就是新建一个仓库了。对于这第一个概念，仓库，可以从字面理解为存代码的仓库，往往将一个项目的完整代码放在一个仓库。
有两种方法：一是在本地新建一个 Git 仓库，另一种是在 GitHub 上新建库，然后下载到本地。
如果你打算将代码放到 GitHub 上，这里推荐第二种方法。因为在 GitHub 新建了库以后，可能会有一些初始文件、初始设置，可能和本地不同。如果使用使问题更复杂，在初学阶段，可以先跳过这些麻烦的东西。
首先假设你已经在 GitHub 网站上建立了库（或者你想把别人的库下载到本机），链接为 https://github.com/lyh543/lyh543.github.io/。现在想要在当前文件夹中，新建 lyh543.github.io 文件夹，并将仓库下载到本地：
1 | git clone https://github.com/lyh543/lyh543.github.io/ |
本地就多了一个文件夹 lyh543.github.io，内容和网站上的一致。
你也可以使用不同于 HTTPS 协议的 SSH 协议（如果你明白这是什么），将上面 clone 的 HTTPS 链接修改为 SSH 链接即可。
顺便提一下，在本地新建仓库的方法如下：
1 | mkdir lyh543.github.io |
Git 上传三连
在建立好库以后，每次写完代码，就可以按照下面的上传三连了。如果该项目只有你的一台设备进行开发（即不会出现不同步的情况），在 99% 的情况，你只会用到以下三条语句。
1 | # 如果本地、服务器端不一致，需要先 git pull，将服务器的内容拉取下来 |
上传完以后，你就可以看到 GitHub 上的代码已经更新。
一键三连
在很熟悉三连操作以后，就会感到有点麻烦了。于是用 alias 实现了一个命令缩写。
1 | alias commit='git_commit() { git add --all && git commit -m "$1" && git push;}; git_commit'` |
但是因为 alias 不是开机自启的，要想开机自启，可以看 另一篇博客，此略。
Git 使用 SSH 协议
Git for Linux 如果操作 HTTPS 协议链接的仓库，是不能保存密码的，每次 push 都需要输入账号密码，很烦。（Git for Windows 貌似可以走网页认证，好像可以保存）
一个选择是 ssh 协议，使用这个协议可以保存用户信息，很方便。
第二个方案是走 https，不过让 Git 明文保存密码（不推荐）
多 ssh 秘钥部署可以看链接：https://www.awaimai.com/2200.html
在 Linux 下 Git 使用 ssh 密钥
大概分为三步走：
- 本地生成密钥对；
- 设置 GitHub 上的公钥；
- 修改 Git 的 remote url 为
SSH协议。
Linux 下本地生成密钥对
$ ssh-keygen -t rsa -C "lyh543@github.com"
passphrase 可留空因为太懒，不然以后每次 push 都要输这个 passphrase
The key fingerprint is: SHA256:QtXXXXXXXXXXXXXXXXXXXXXXXXXXXXlk lyh543@github.com
设置 github 上的公钥
- 查看你的公钥
1 | $ cat ~/.ssh/id_rsa.pub |
- 登陆你的
github帐户。然后Account Settings-> 左栏点击SSH Keys-> 点击Add SSH key - 然后你复制上面的公钥内容，粘贴进“Key”文本域内。
title域，你随便填一个都行。 - 完了，点击
Add key。 - 测试一下这个key。
1 | $ ssh -T git@github.com |
看到最后一句就是OK了。
修改 Git 的 remote url 从 https 改为 ssh
查看当前（git仓库下的）的remote url
1 | # 需要到仓库根目录下 |
修改 remote url
1 | git remote set-url origin git@github.com:lyh543/lyh543.github.io.git |
题外话：把 ssh 密钥给服务器
使用 ssh 远程登录服务器的时候，每次都要输入密钥。其实也可以使用 ssh 密钥进行登录。而且甚至没有 git 这么麻烦，还要去官网上加入公钥。
直接一句：
1 | ssh-keygen |
即可。
Windows 下 git 使用 ssh 密钥
Windows 下也可以生成 ssh 密钥对，但是需要使用第三方软件：PuTTYgen，在 Tortoise Git 中自带。由于方法不同，可以在 Windows 和 Linux 使用不同的 ssh Key。
- 本地生成密钥对；
- 设置github上的公钥；
- 设置本地git使用的密钥。
Windows 下本地生成密钥对
进入软件，点Generate，然后就开始生成。由于生成时的随机数据是采集鼠标指针的移动，因此务必在生成过程中移动鼠标。
大约1分钟以后，生成完成，如图2。
然后 Save Private Key 把密钥文件存下来。
文本框中的内容是公钥，按照上面的方法设置github上的密钥。
设置本地 git 使用的密钥
由于笔者使用 Tortoise Git，在一个 reporisitory 中 push 的时候选中自动加载 PuTTY密钥即可。
命令行 Git 另有实现方法。
(Linux) Git 保存密码
参考博客：https://blog.csdn.net/xx326664162/article/details/49686241
https://www.crifan.com/git_remember_record_user_and_password_no_need_input_again/
Git的凭据存储有 cache、store、manager 三种方式。可以通过
1 | git config --global credential.helper store |
切换。
其中，如果使用 store，密码将被会明文保存在 ~/.git-credentials。感觉不大好。
如果使用 cache 密码会在内存中保存一段时间。密码永远不会被存储在磁盘中，并且默认在15分钟后从内存中清除。不过时间是可以修改的。
于是，就有人想到把这个时间设置为一个月 2592000 。
注销以后密码也会被清除，毕竟是存在内存里的。不过每次开机输一次密码也能接受。
1 | git config --global credential.helper cache |
还有一种在 remote.url 中加入自己的用户名和密码，更危险，就不表了。
Git 代理
经常会有挂上代理，浏览器访问 Github 快到飞起的，但是 Git Clone 却慢死的经历。awsl。
以下方法收集自知乎的同一问题：git clone一个github上的仓库，太慢，经常连接失败，但是github官网流畅访问，为什么？
Shadowsocks 对 Github 进行 HTTPS 代理
1 | git config --global http.https://github.com.proxy socks5://127.0.0.1:1080 |
也要注意 1080 是 Shadowsocks 代理的端口，可能需要根据自己的代理配置进行修改。
另外使用该方法以后，需要用 HTTPS 协议（而不是 SSH）进行传输。
ssh 代理
Linux/WSL 1
Linux 的 ssh 代理可以通过macOS 给 Git(Github) 设置代理（HTTP/SSH）的方法。
WSL 2
注意如果是 wsl 2，因为 wsl 2 实际上是一个 Hyper-V 虚拟机，因此 Windows 上的代理如果想要被 Linux 使用，上面填 ip 的地方应该填 Windows 在 wsl 网络下的 ip（命令行输入 ipconfig，看到 以太网适配器 vEthernet (WSL) 的就是）。另外还需要代理软件“允许局域网的连接”。
而且目前 wsl 2 由于是由 Hyper-V 实现的，每次重启 windows，windows 和 wsl 的 ip 都会变，目前没有方法改为静态 ip，只能每次改 ip 了。（
Windows
如果是 Windows 下的 Git，可以参考：git clone一个github上的仓库，太慢，经常连接失败，但是github官网流畅访问，为什么？ - 戈登走過去的回答 - 知乎
不过注意，如果你的 OpenSSH 是通过 Windows 10 设置 - 应用与功能 - 可选功能 安装的，此法可能会使 Windows 下 ssh 出现如下错误：
1 | C:\Tools\Git\>ssh -T git@github.com |
这个 bug 不影响 Git 的使用，并且可以通过卸载后从此处安装解决：https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH
bug 相关可参见：https://github.com/microsoft/vscode-remote-release/issues/1887
改 hosts
还有一个方法是修改 Hosts 文件。对于没有代理的开发者，会有一点帮助（都是开发者了为什么还没有代理）。
1 | 151.101.72.249 github.http://global.ssl.fastly.net |
Git 基础
对于刚入门 Git 的萌新，clone pull add commit push 已经够用了。然而，如果要发挥 Git 全部的功能，还需要了解更多的东西。
回溯版本
git status/diff/checkout 查看当前状态
学习链接：https://www.liaoxuefeng.com/wiki/896043488029600/896954074659008#0
下面只是对上述博客的一些简短的笔记。
使用 git status 可查看目前 Git 的状态（什么文件被修改过之类的……）
使用 git diff readme.txt 可查看 readme.txt 的还没有被 commit 的修改。
对于只是修改了 readme.txt 文件，还没有进行任何 Git 操作的，可以 git checkout -- readme.txt 恢复为之前 add 过的文件。
更多的情况可看Git 之 恢复修改的文件
git log/reflog/reset 版本回退
使用 git log 可查看当前分支的所有 commit 日志。
可搭配 --pretty=oneline 简略显示。
1 | $ git log --pretty=oneline |
前面的一串是 SHA1 值。
回退到上一个版本：git reset --hard HEAD^
回退到上两个版本：git reset --hard HEAD^^ 或 HEAD~2
回退/前进到指定版本：git reset --hard a4a3（到 append GPL 版本）
如果回退以后想再前进，却忘了 SHA1 值，可以使用 git reflog。
注意至少要写四位，否则会报错：
1 | $ git reset --hard 65a |
相关概念浅析：工作区、暂存区
- 工作区
working tree：（对于 test 项目）test 文件夹（tree翻译成目录比较好） - 版本库
Repository：test/.git文件夹 - 暂存区
stage/index：在版本库中（Git 文档中凡是出现stage和index都是暂存区的意思） master：第一个分支，也在版本库中HEAD：指向master的指针
其逻辑关系如下：
1 | test 文件夹 |
git add：将文件修改添加进暂存区git commit：将暂存区的东西 commit 到当前分支。（在这之后用git status会显示working tree clean）
git diff/checkout/reset 笔记
diff 只能比较两份文件，如果是操作中是新建文件/删除文件，git diff 会提示“没有差异”。
各 diff 的区别：
git diff：显示工作区和暂存区的差异（即未 add 的内容）git diff --cached：显示暂存区和HEAD的差异（即未 commit 的内容）git diff HEAD：显示工作区和HEAD的差异（即未 add 或 commit 的内容）
在命令后可加文件名，指定比对某文件。
git checkout -- <file>可以认为是反向 add，是将暂存区的文档修改覆盖工作区的文档；- 使用不带参数的
git checkout可以查看工作区和暂存区的文件差异。 --表示这条命令要无视--后的所有参数（实战中貌似也是可以去掉的）
- 使用不带参数的
git reset HEAD <file>可以认为是反向 commit，是用当前分支的文档覆盖暂存区。（并不会覆盖工作区）- 加上
--hard参数，git reset --hard HEAD <file>就会覆盖工作区了
- 加上
远程库操作
在本地 git init 了一个库以后，如果需要上传到远程库，就需要设置远程库的地址（地址可以在 GitHub 网页上获取）：
1 | git remote add origin git@github.com:lyh543/test.git |
Git 规定，要给每一台远程主机命名。这里的 origin 就是 Git 给远程库的默认名字。虽然可以用别的名字，但是推荐 origin。
然后，进行 push：
1 | git push -u origin master |
push 命令将本地的当前分支上传到 origin 的 master 分支（简写 origin/master）。-u（或 --set-upstream）参数，还顺便将本地的 master 分支和 origin/master 分支进行关联（track），以后就不用指定。
branch 分支管理
其他版本控制系统如 SVN 等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。
但 Git 的分支 branch 是与众不同的，无论创建、切换和删除分支，Git 在 1 秒钟之内就能完成！无论你的版本库是 1 个文件还是 1 万个文件。
创建和合并分支
相关概念
复习一下，master 是 Git 默认创建的分支，HEAD 是指向 master 的一个指针。
其实，分支，是一条 commit 线。
也就是说，Git 中的每一个状态，其实指的是每一次 commit，而分支就是将 commit 串起来了（然后 HEAD 又指向了当前分支的头）。
所以创建分支的本质就是添加一条线，更改一下 HEAD，很快的。而删除分支，就是删一条线（并不删除 commit），也很快。
代码
新建 dev 分支并切换到该分支：
1 | git branch dev # 从当前分支新建 dev 分支 |
上述两个过程也可以用一行替代：
1 | git checkout -b dev |
实现的效果如图：
顺便一提， git checkout 的确是有两个功能，一是切换分支，二是将暂存区的某文件修改覆盖工作区的对应文件，不过二需要使用 git branch --。
这之后，就可以在 dev 分支上修改，然后三连了。
1 | echo "We are working on a new branch" >> readme.txt |
这之后，我们的仓库状态如下图：
接下来，将 dev 上的 commit merge 进 master。
由上图可以看到，直接将 master 分支线延长至 dev 即可，所以 Git 能够轻松完成 merge 操作。
这种 merge 又叫 fast-forward merge：
A fast-forward merge can occur when there is a linear path from the current branch tip to the target branch.
Instead of “actually” merging the branches, all Git has to do to integrate the histories is move (i.e., “fast forward”) the current branch tip up to the target branch tip. – Git Merge | Atlassian Git Tutorial
When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the default behavior. –
git merge --help
1 | git checkout master # 从 dev 切回 master 分支 |
提一句，merge 本质也是一次 commit，其也可以使用 -m <msg> 来设定 commit 信息，而不是在弹出的文本编辑器中。
最后删除 dev 分支：
1 | git branch -d dev # 删除已经完成合并的 dev 分支 |
no-fast-forward merge
fast-forward merge 的好处是相当快，并且 commit 线简洁，但是简洁的坏处就是丢失了一些信息。
在这种模式下，删除分支后，会丢掉分支信息。
git merge 默认使用 fast-forward 模式。如果要强制禁用 fast-forward 模式，Git就会在 merge 时生成一个新的 commit，这样，从分支历史上就可以看出分支信息。
使用方法很简单，就是在 git merge 时增加一个参数：
1 | git merge --no-ff dev |
2020.8.26 更新：在团队合作时，将自己写的代码
merge到合作的分支（如master或dev）上时，推荐使用--no-ff，这样 commit 线上会出现分叉，不同人的 commit 会更加明显。
删除分支
有三种情况：在本地删除某分支；在远端删除某分支（即将本地删除分支的操作 push 到远端）；在本地删除远端分支（即远端的已经被其他小伙伴删除，需要删除之前拉取到本地的远端分支）。
1 | # 在本地删除分支 |
解决冲突
上面的分支图都是很简单的(linear)，如果复杂一点，比如两个分支都有自己的提交，git merge 就不能进行 fast-forward merge 了。
对于简单的情况（两个分支只有文件增添，没有文件修改的冲突），Git 仍然可以实现自动合并，如：
- 在
feature1删除了 a.txt - 在
master新增了 b.txt
将 feature1 合并进 master 后，master 分支会呈现删除 a.txt，新增 b.txt 的状态。
但是，也会有复杂的情况。如两个分支的某文件内容不同：
在 master 分支的 branch.txt 如下：
1 | branch: |
在 dev 分支的 branch.txt 如下：
1 | branch: |
在 master 分支下进行 git merge dev 会报失败：
1 | $ git merge dev |
这时查看 branch.txt，会是这样：
1 | branch: |
上面标注了两个版本的区别。
现在我们有两个方案：一是放弃合并操作；二是进行合并。
如果想放弃合并操作，只需一句 git merge --abort，就可以回到 git merge dev 之前的状态（一切都没发生过.jpg）；
如果想进行合并，只需要在当前状态下，修改 branch.txt 到想要的样子，然后 add 和 commit：
1 | git add branch.txt |
就完成了 merge 和解决冲突。如何验证呢？可以用带图的 git log
1 | git log --graph --pretty=oneline |
分支管理策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在 dev 分支上，也就是说，dev 分支是不稳定的，到某个时候，比如 1.0 版本发布时，再把 dev 分支合并到 master 上，在 master 分支发布 1.0 版本；
你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev分支上合并就可以了（向 dev 合并自己的代码的时候推荐 --no-ff，从 dev 分支将小伙伴的代码合并到自己的代码时推荐默认的 --ff）。
所以，团队合作的分支看起来就像这样：
而对于一个小 bug 或者一个 issue-101，也可以通过开一个 issue-101 临时分支，写完、merge 以后，再将临时分支删掉。
git stash 工作区暂存
在当前分支的修改还有没 commit 的情况下，切换到其他分支后，这些修改会依然存在。
git checkout [<branch>]
To prepare for working on <branch>, switch to it by updating the index and the files in the working tree, and by pointing HEAD at the branch. Local modifications to the files in the working tree are kept, so that they can be committed to the <branch>.
– git checkout
如果我们既不想 commit（当前工作还没做完），也不想将当前分支的修改带到别的分支里，应该怎么做呢？
1 | git stash |
使用这句命令，我们就可以把工作区的修改暂存起来，然后让工作区呈现修改前的状态。这之后，使用 git status 会显示 working tree clean。
然后我们就可以用 git checkout 切换分支，在别的分支进行工作了。
在别的分支工作完，并切回该分区以后，如何找回来呢？
1 | git stash list # 列出当前的 stash |
remote 远端管理
这一节的内容其实和分支管理有一些交集，毕竟远端管理其本质也是在管理远端的分支。
git remote 查看远程库的信息
查看远程库的信息：
1 | $ git remote |
上面显示了可以抓取 fetch 和推送 push 的 origin 的地址。如果没有推送权限，就看不到 push 的地址。
git push 推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。
推送时，要指定本地分支，这样，Git 就会把该分支推送到远程库对应的远程分支上：
1 | git push origin master |
如果要推送其他分支，比如 dev，就改成：
1 | git push origin dev |
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复 bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个 bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
总之，就是在 Git 中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
git fetch 从远端拉取
git clone 只会获取远程的 master 分支，如果要获取 dev 分支，我们应该从 origin/dev 新建 dev 分支：
1 | git checkout dev |
git checkout [<branch>]
If<branch>is not found but there does exist a tracking branch in exactly one remote (call it<remote>) with a matching name and –no-guess is not specified, treat as equivalent to$ git checkout -b <branch> --track <remote>/<branch>
– git-checkout Documentation - Git
这也太贴心了吧~ 那就不用记麻烦的了。
然后就可以愉快的在 dev 分支上进行修改了。
如果远端的内容更新了（比如你的小伙伴向远端 commit 了），但本地还没有更新，可以使用
1 | git fetch |
来进行拉取（fetch）。
如果 merge 或 pull 中有冲突，需要按照 解决冲突 的套路来合并冲突。
git rebase 变基
git rebase 通过修改 commit 的顺序使得某些情况下的分支图更简洁。
比如以下场景：
小伙伴 A 和 B 在合作开发同一个项目。
- 小伙伴 A 添加了
a.txt，并进行了 commit 和 push； - 小伙伴 B 在没有 fetch 的情况下添加了
b.txt，并进行了 commit 和 push。当然，这里 push 会失败，提示需要 fetch。 - 小伙伴 B fetch 并 merge，完成了 merge 的过程，可以进行 pull 了。但是……
此时的 git log --graph --pretty=oneline 出现了分叉！
1 | $ git log --graph --pretty=oneline |
这也没什么问题。
但是，从理论上，这个分叉完全可以避免：只要 B 能在 commit 前进行 fetch 就可以少一次 merge 了。
于是，这时 B 拍出了 git rebase：
1 | $ git rebase |
（这里的 rebase 过程比较简单，如果 A B 对同一文件进行了修改，rebase 过程会稍微复杂，但同样能达到效果）
之后，工作区和暂存区都没有什么变化，但是 git log --graph --pretty=oneline 发生变化了：
1 | $ git log --graph --pretty=oneline |
分支线的分叉消失了！
也就是说，git rebase 能通过修改 commit 顺序，使得分支线简单，但是会减少一个 merge 的 commit。
接下来就可以 push 了。
tag 标签管理
Git 可以给历史中的某一个提交打上标签，以示重要。
比较有代表性的是人们会使用这个功能来标记发布结点（v1.0 等等）。
标签也是一个指针，指向 commit 的。
标签有 轻量标签 lightweight 和 附注标签 annotated。
一个轻量标签很像一个不会改变的分支——它只是一个特定提交的引用。
然而，附注标签是存储在 Git 数据库中的一个完整对象。 它们是可以被校验的；其中包含打标签者的名字、电子邮件地址、日期时间；还有一个标签信息；并且可以使用 GNU Privacy Guard （GPG）签名与验证。 通常建议创建附注标签，这样你可以拥有以上所有信息；但是如果你只是想用一个临时的标签，或者因为某些原因不想要保存那些信息，轻量标签也是可用的。
添加轻量标签：
1 | git tag v1.0 # 为 HEAD 添加 v1.0 的标签 |
添加附注标签，加一个 -a 开关就可以。
1 | git tag -a v1.4 -m "my version 1.4" |
列出已有标签：git tag
查看标签对应的 commit：git show v1.0
注意，标签默认不会被 push 至远程服务器（clone 和 fetch 时是会获得的）。
需要显式地 push 标签：git push origin v1.0
或 push 时带上 --tags：git push origin --tags
删除标签可以使用 git tag -d v1.0。
但是，将删除标签推送至远端就有点复杂了： git push origin :refs/tags/v1.0。
查看标签所指的文件版本： git checkout v1.0
注意这之后会进入 detached HEAD 的状态，不再有 HEAD 的概念。
在这个状态下会进行 commit 有一定副作用（具体见手册），推荐新开一个 branch 来进行操作。
看完了？
如果看完了，推荐去看看 git-scm.com 的教程和手册，这里有官方对命令的解释，你对命令和概念的理解会更加精确。如 git checkout
Git 小技巧
git rm
以下三种命令等价，都是从工作区删除并提交到暂存区
rm readme.txtgit add readme.txtrm readme.txtgit rm readme.txtgit rm readme.txt
而从工作区删除，但是想恢复，只能在使用 rm readme.txt 的前提下 git checkout -- readme.txt。
–amend 修改上次 commit
可以使用 git commit --amend -m "xxx" 以修改上次的 commit。
如果已经 push 了，下次就需要 git push -f 强制推送。如果还没有 push，就相当于之前的 commit 没发生过，直接 git push 就行。
git 修改设置
1 | git config [--local] --list # 查看设置；--local 用于本地库 |
git 修改远端
1 | git remote -v # 查看所有远端 |
更多的命令，可以随便敲一个不存在的命令，如 git remote hhh 来查看所有命令。
当你在 branch 外 commit 后
如果你在 branch 外 commit，然后立即切回 branch，你的 commit 就会掉。
有两个解决方案：
- 将 commit 的内容变为一个新的 branch，然后在原来的 branch 中 merge 新的 branch；
- 用下面的 cherry-pick 命令在 branch 中把对应的 commit 捡回来。
cherry-pick 捡 commit
git cherry-pick 是一个“捡” commit 的命令。可以把任意（非当前 branch 的） commit 拉到本 branch 来。
非当前 branch 的 commit 可以通过 git reflog 查看。
Git 大文件版本管理：git-lfs
Git LFS 是 Github 开发的一个 Git 的扩展，他能够处理 Git 仓库里的大文件（如图片、视频等等），其原理是将 Git 仓库中的大文件替换为一个指针，然后将大文件存在另一个服务器上。这样做的好处有：
- 可让您存储最大 2 GB 的文件
- 使得 Git 仓库的容量更大
- 更快的 Cloning 和 Fetching（大概用的服务器更快）
- 操作和工作流等和原来完全一样
以上是官方的，个人感觉可能还会使得每次更新大文件时，他不会再保存在 .git 文件夹，占取大量硬盘空间了。
git-lfs 安装
Windows 上官网就行。Ubuntu 下：
1 | sudo apt install git-lfs |
git-lfs 配置
对于每个仓库下，第一次需要配置一下（如需要用 git-lfs 管理 psd 和 mp4 文件）
1 | git lfs install |
以后就和常规 git 上传三连 相同了。
1 | git add file.psd |
GitHub 使用技巧
下载最新的 release
阅读他人的教程博客时，经常会看到给出 GitHub Release 的某版本的下载链接（下面第一行），但该版本可能已经过时。实际上，GitHub 提供了能重定向到最新版的链接（下面第二行）：
1 | https://github.com/canton7/SyncTrayzor/releases/download/v1.1.24/SyncTrayzorSetup-x64.exe |
在写下这篇博客时，第二行链接能正确地被重定向到第一行：
1 | $ curl -I https://github.com/canton7/SyncTrayzor/releases/latest/download/SyncTrayzorSetup-x64.exe |
