Git 学习笔记

简单记录,以便之后复习。学习的是廖雪峰 Git 教程,浅显易懂,不要太赞!
Git 官网 有中文文档,有更详细的说明。常用的命令运用熟练已足够,若需要更复杂更高级的操作,就要去查文档了。

什么是 Git?

Git 是目前世界上最先进的 分布式版本控制系统

Git 的诞生:

Linus 在 1991 年创建了开源的 Linux,在全世界的热心志愿者参与下,Linux 不断发展壮大,已经成为最大的服务器系统软件。

Linux 靠世界各地的大牛贡献代码,但代码的管理始终是个问题。
在 2002 年之前,志愿者们通过 diff 方式将代码发给 Linus,然后由他本人手工合并代码。

Linus 为什么不用当时已有版本控制系统呢?

  1. CVS 和 SVN,这些集中式版本控制系统速度慢,且必须联网;
  2. 一些商业的版本控制系统虽然好用,但要付费,和 Linux 的开源精神不符。

到了 02 年,Linux 系统已发展十年,代码库之大已经很难通过手工方式管理,于是不得不选择一个版本控制系统,Linus 选择了商业的 BitKeeper,而 BitKeeper 的公司 BitMover 出于人道主义精神,授权 Linux 社区免费使用。

好景不长,2005 年时,Linux 社区的 Andrew 试图破解 BitKeeper 的协议,被 BitMover 公司发现,于是收回了 Linux 社区的免费使用权。

Linus 没有重新选择另一个版本控制系统,而是花了 2周时间 自己用 C 写了一个分布式版本控制系统,便是 Git!一个月之内,Linux 系统的源码已经由 Git 管理了。

Git 迅速成为最流行的分布式版本控制系统,到了2008年,GitHub 网站上线,它为开源项目免费提供 Git 存储,无数开源项目开始迁移至 GitHub,包括 jQuery,PHP,Ruby 等。

集中式 vs 分布式

  • 集中式:版本库存放在中央服务器,每次干活前,先从中央服务器取得最新的版本,干完活后再推送给中央服务器。
    最大的问题是必须联网才能工作,如果网速慢的话,非常费时间。一旦中央服务器崩溃,所有人都无法工作。

  • 分布式:每个人的电脑上都是完整的版本库,所以就不用联网了。多人协作时,只需将自己的修改互相推送。而这里的“中央服务器”只是方便大家交换修改,没有它照样可以工作,只是有了它交换更方便而已。
    另外,Git 的优势还有强大的 分支管理

常见的版本控制系统有:
集中式:CVS(最早,不稳定)、SVN(最流行)、ClearCase(IBM的,商用,大,慢)、VSS(微软自己的)等
分布式:Git(最快,最流行)、BitKeeper、Mercurial、Bazaar 等

安装 Git

Git 最开始只能在 Linux 和 Unix 系统上运行,现在也可以在 Mac 和 Windows 上运行。

Windows 上安装:

下载 Git 安装,包含了 Git Bash 和 Git GUI。
下载 msysgit 安装,msysgit 已将所需模拟环境和 Git 打包,默认安装即可。
下载 GitHub 安装,包含了可视化工具 GitHub 和命令行窗口 Git Shell 。

创建版本库

版本库(Repository),库里的每个文件都能被 Git 跟踪

> 创建库

  1. 先创建一个空目录(如 …\GitHub\study)

    1
    2
    3
    mkdir study
    cd study
    pwd // 显示当前目录
  2. 将这个目录变成 Git 可管理的仓库

    1
    git init

于是建成了一个空的仓库,此时 study 目录下多了一个 .git 的隐藏目录

> 添加文件入库

1
2
git add readme.txt
git commit -m "add a readme.txt"

可以多次 add,只需一次 commit

时空穿梭

> 基本操作

1
2
3
4
5
6
7
8
git status      // 查看工作区状态
git diff readme.txt // 查看不同

git add readme.txt
git status

git commit -m "add word distributed"
git status

版本回退

每 commit 一次,就在 git 里保存了一个「快照」

1
2
3
4
5
6
7
git log      // 查看版本历史记录,从最近的版本到最远排列
git log --pretty==oneline // 添加参数简化信息
/*
d1e563cda89f530ac466e3c0ed216a9f814ad700 append GPL
c5e16db582973fcaf9e1b7ab534c83b22d206221 add word distributed
18010d7984d1b9e693ad98a15372da6177f54366 add a readme.txt
*/

如上,每个版本对应一个 commit id(经过特殊处理,防止冲突)

可用 reset 来回退到指定版本:

1
git reset --hard HEAD^

HEAD 表示当前版本,HEAD^ 表示上一个,HEAD^^ 表示上上一个,HEAD~10 表示往上10个版本
回退到上一个版本后再查看:

1
2
3
4
5
git log
/*
c5e16db582973fcaf9e1b7ab534c83b22d206221 add word distributed
18010d7984d1b9e693ad98a15372da6177f54366 add a readme.txt
*/

发现”append GPL”版本没有了,怎么办?
如果还知道那个版本的 id,则:

1
git reset --hard d1e563cd(版本号没必要写全)`

如果找不到版本的id了,则

1
2
3
4
5
6
7
git reflog
/*
c5e16db HEAD@{0}: reset: moving to HEAD^
d1e563c HEAD@{1}: commit: append GPL
c5e16db HEAD@{2}: commit: add word distributed
18010d7 HEAD@{3}: commit (initial): add a readme.txt
*/

又能找到版本的 id 了

工作区和暂存区

工作区(working directory):在你的电脑里能看到的目录
版本库(repository):工作区中隐藏的目录 .git,就是版本库

.git 里存了很多东西,最重要的就是 stage(或叫 index)的暂存区,还有自动创建的 master 分支,以及指向 master 的指针 HEAD

暂存区如何工作?(详看教程文档p25-27)
将工作区的修改,添加到 stage,再将 stage 的所有修改提交到分支。

管理修改

Git 管理的是修改,而不是文件。删除内容、增添内容、修改内容、新增文件、删除文件等等,都算修改。

所有工作区的修改都必须先 add 到 stage,才能提交成功。

如果没有 add,那只会提交 stage 中的修改,而不是工作区的修改。
比如:
第一次修改 > add > 第二次修改 > commit
因为只有第一次修改添加到 stage,所以只提交了第一次修改
第一次修改 >add > 第二次修改 > add > commit
这样两次修改都提交了

查看工作区和最新版本的区别:

1
git diff HEAD -- readme.txt

! git diff 说明:

1
2
3
git diff      比较工作区和暂存区
git diff HEAD 比较工作区和版本库
git diff --cached 比较暂存区和版本库

> 撤销修改
工作区的修改,怎么撤销?

1
2
3
git checkout -- readme.txt    // 特定文件
git reset --hard HEAD // 所有修改
git clean -f // 未追踪的文件(即新增的文件),常与上一个命令配合使用

已添加到暂存区的修改,怎么撤销?

1
git reset HEAD readme.txt

这样便把暂存区的修改撤销(unstage),重新放到工作区

如果已经提交,怎么办?
版本回退,回退到上一个版本,前提是没有推送到远程库。

> 删除文件
先添加一个 test.txt 并提交
删除:rm test.txt

若是误删想恢复,同撤销修改相同:

1
git checkout -- test.txt

确实要删:

1
2
git rm test.txt
git commit -m "remove test.txt"

远程仓库

Git 是分布式版本控制系统,同一个 Git 仓库,可以分布到不同的机器上。怎么分布呢?

最早,肯定只有一台机器有一个原始版本库,此后,别的机器可以“克隆”这个原始版本库,而且每台机器的版本库其实都是一样的,并没有主次之分。

其实一台电脑上也是可以克隆多个版本库的,只要不在同一个目录下。不过,现实中是不会有人在一台电脑上搞几个远程库玩,完全没有意义。

实际情况往往是,找一台电脑充当服务器的角色,全天开机,其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上,并且各自把各自的提交推送到服务器仓库里,也从服务器仓库中拉取别人的提交。

为了学 Git 先搭建个服务器绝对是小题大做,好在有很多代码托管网站,比如 GitHub,免费提供托管服务,免费获得 Git 远程仓库。

因为本地 Git 仓库和 GitHub 仓库之间是通过 SSH 加密,所以,要先设置:

  • 创建 SSH Key:

    1
    ssh-keygen -t rsa -C "yixvan6@163.com"

    一路回车,使用默认值,也无需设置密码。
    如果成功,会在用户主目录里找到 .ssh 目录,里面有 github_rsagithub_rsa.pub 两个文件,一个是私钥,不能泄露,一个是公钥,可以公开。
    如果已经有这两个文件,那直接第二步。

  • 添加 SSH Key 到 GitHub:
    登录 GitHub,Settings > SSH and GPG keys
    点”New SSH key”,Title 任意填写,Key 文本框里粘贴 github_rsa.pub 文件的内容,然后确认。

  • 测试 ssh key 是否成功:

    1
    ssh -T git@github.com

    如果出现 You’ve successfully authenticated, but GitHub does not provide shell access 。这就表示已成功连上github,否则会显示 access denied。

为什么要 SSH Key 呢?
为了安全,防止冒充。

可添加 多个 Key,使你在不同的电脑上都能推送到自己的 GitHub

提示:
GitHub 免费托管 Git 仓库,但任何人都能看到(只有自己能改),是公开的。
若想不让别人看到,i.付费;ii.自己搭建 Git 服务器。

添加远程库

登陆 GitHub,> New repository,创建新库。
目前是空的,可以把已有的本地库与之关联,然后,把本地库的内容推送到 GitHub 库

1
2
3
git remote add origin git@github.com:yixvan6/study.git    // origin是代表远程库的名称
git push -u origin master // 推送所有内容,实际是推送当前分支master
// -u 是首次推送时与分支关联

以后提交,就通过 git push origin master

从远程库克隆

克隆到本地:

1
git clone git@github.com:yixvan6/gitskills.git

Git 支持多种协议,包括 https,但 ssh 最快。

> 从远程库同步修改
有时候修改是在远程库完成的,需要把远程的修改拉到本地库,使之相同
介绍两种方式:

  • fetch 或 merge

    1
    2
    3
    4
    5
    6
    7
    8
    9
    git remote -v      // 查看有哪些远程仓库,本例为一个
    /*
    origin git@github.com:yixvan6/yixvan6.github.io.git (fetch)
    origin git@github.com:yixvan6/yixvan6.github.io.git (push)
    */

    git fetch origin master // 从远程获取最新版本到本地

    git merge origin/master // 将远程下载的代码合并到本地库
  • pull

    1
    git pull origin master      // 下载并合并

分支管理

分支之间各自独立,互不干扰,既安全,又不影响别人工作。自己的开发完毕之后,可以一次性合并到原来的分支上。

其他的版本控制系统如 SVN 等也有分支管理,但分支的创建和切换非常慢,几乎成了摆设。
但 Git 的分支无论是创建、切换还是删除,都能迅速完成,无论你的版本库是1个文件还是上万个文件。

创建与合并分支

Git 的每次提交,都把它们串成一条时间线,这条时间线就是一个分支。目前我们只有一条时间线,默认为 master 分支,也称为主分支。
HEAD 严格来说不是指向提交,而是指向 master,而 master 才指向提交,所以,HEAD 指向当前分支。

每次提交,master 分支都向前移动一步,随着不断提交,分支的线也越来越长。
当创建新分支,例如 dev,Git 新建了一个指针叫 dev,指向 master 相同的提交,再把 HEAD 指向 dev,就表示当前在 dev 分支上:

从现在起,修改和提交就是针对 dev 分支了,dev 指针向前移动,而 master 指针不变:

假如我们在新分支上的工作完成了,可以将其合并到主分支上。最简单的方法,就是把 master 指向 dev 的当前提交,完成合并:

合并完成后,如果要删除 dev 分支,只要删除这个分支对应的指针就可以了,删除后,只剩下了主分支:

> 具体命令
理解了原理,我们来了解具体的命令来实现。
创建分支:

1
2
3
4
git checkout -b dev      // 加上 -b 参数表示创建并切换,相当于下面两条命令

git branch dev
git checkout dev

然后,查看当前分支:

1
git branch      // 列出所有分支,并用 * 号标出当前分支

这时做一次新的提交,再切换到主分支查看,会发现没有变化,因为那个提交是在 dev 分支上,不会影响到 master 分支。

现在,将 dev 分支上的工作成果合并到 master 分支上:

1
git merge dev

git merge 用于将指定分支合并到当前分支,这时再查看修改,会发现与 dev 分支的最新提交是一样的。
合并完成,可以放心删除了:

1
2
3
4
git branch -d dev

// 如果没有合并想直接删除
git branch -D dev

!因为 Git 的分支操作只是改变指针,所以速度非常快,所以「鼓励」使用分支完成某个任务,合并后再删除分支,这跟直接在主分支上工作效果是一样的,但过程更安全。

解决冲突

先创建一个新分支来演示:

1
git checkout -b feature1

修改 readme.txt 文件,然后提交。
切换到主分支,修改 readme.txt,提交。
合并 feature1 分支,因为两次修改并不相同,所以出现冲突:

1
2
3
4
git checkout master
...
git merge feature1
git status // 可查看冲突的文件


解决:
先查看文件,发现 Git 帮我们标记出来了冲突,用 <<<<<<<=======>>>>>>> 标记不同分支的内容:

手动修改后保存,提交。这样就解决了冲突,分支关系如下:

最后即可删除 feature1 分支。

分支管理策略

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

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

我们创建一个新分支 dev,并做一次提交。然后切换回主分支用普通模式(即非’ff’模式)来合并:

1
git merge --no-ff -m "merge with no-ff" dev

因为本次合并要创建一个新的 commit,所以加上 -m 参数,把 commit 描述写进去。
不使用 Fast forward 模式,合并后像这样:

> 分支策略
实际开发中,应该按照这个原则进行分支管理:
首先,master 分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;

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

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

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

Bug 分支

软件开发中,bug 就像家常便饭。在Git中,由于分支是如此的强大,所以,每个 bug 都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。

通常会碰到一种情况:当收到任务要立即修复某 bug,但当前正在进行的工作还没有完成,没法提交。
Git 提供了一个 stash 功能,可以把当前工作现场暂存起来,等修复完 bug 再回来恢复现场继续工作。

具体流程:

1
2
3
4
5
6
7
8
9
10
11
git stash      // 暂存当前工作
git checkout master // 切换回 master 分支(假定需要在 master 分支上修复该 bug)
git checkout -b bug-x // 从 master 分支创建临时分支

// 修复完成,提交后,切换回 master 分支,合并,最后删除 bug-x 分支

git checkout dev // 切换到之前工作的分支
git stash list // 查看 stash 列表
git stash pop // 恢复工作现场并删除 stash,等同于下面两个命令
git stash apply // 恢复
git stash drop // 删除

可以多次 stash,恢复时,先查看,然后用对应标号恢复

1
git stash apply stash@{0}

{Note}在 dev 分支的修改,无论是否 add 到 stage,切换回 master 分支时都可以看到修改;
无论是否 add,都可以进行 stash 暂存。

Feature 分支

同 bug 临时分支一样,在开发新功能时,以防一些实验性质的代码搞乱了主分支,最好新建一个 feature 分支,等新功能开发完成后,合并,这个 feature 分支就可以删除了。

多人协作

当从远程库克隆时,Git 会把本地 master 分支和远程的 master 分支对应起来,远程的仓库默认名称为 origin
查看远程库的信息:

1
2
git remote
git remote -v // 会显示抓取和推送的地址,如果没有推送权限,就看不到 push 的地址

> 推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git 就会把该分支推送到远程库对应的远程分支上:

1
2
3
4
git push origin master

// 推送其他分支,比如 dev
git push origin dev

但是,并不一定要把本地所有分支推送到远程,那么,哪些分支需要推送,哪些不需要呢?

  • master 分支是主分支,因此要时刻与远程同步;
  • dev 分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
  • bug 分支只用于在本地修复 bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个 bug;
  • feature 分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
    总之,在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!

> 抓取分支
多人协作时,大家都会往 master 和 dev 分支上推送各自的修改。

模拟一下场景:假设现在有 C 君,要在另一台电脑上克隆项目。

{Note} 从远程库克隆时,默认情况下,只能看到本地的 master 分支。

C 君要在 dev 分支上开发,先要创建远程 dev 分支到本地:

1
git checkout -b dev origin/dev

现在,他可以在 dev 分支上工作了,并时不时地把分支 push 到远程。

C 君已向远程推送了提交,恰巧,你也做了修改,并试图推送:

1
git push origin dev

但却推送失败,因为 C 君的最新提交和你要推送的提交有冲突。要解决冲突,先要把最新的提交抓取下来,然后在本地合并,解决冲突,再推送:

1
git pull

但抓取也失败了,原因是没有指定本地 dev 分支和远程 origin/dev 的链接,根据 Git 的提示,设置链接:

1
git branch --set-upstream-to=origin/dev dev

这时再 git pull,抓取成功,但合并有冲突,需要手动修改冲突。
解决冲突后提交,最后 push

总结 一下过程:

  1. 试图 git push origin dev 推送修改;
  2. 若推送失败,则因为远程分支比你本地的更新,先用 git pull 抓取并合并;
  3. 若抓取失败,并提示 no tracking information,则是没有建立本地分支与远程的链接,先设置链接再 pull
  4. 若合并有冲突,则先解决冲突,解决后再推送。

Rebase

多人在同一分支上协作时,很容易出现冲突。即使没有冲突,后推送的童鞋不得不先 pull,在本地合并,才能推送成功。
每次合并再推送后,分支线就变得很凌乱,如下:

Git 有一种 rebase 操作,可以将提交历史变为一条直线!所以有人亲切地将其称为「变基」

举例说明:
查看提交历史,远程的最新提交是 init hello,而自上次推送后我们又在本地新增了两次提交,add commentadd author,即本地比远程提前两个提交。

1
2
3
4
5
6
$ git log --graph --pretty=oneline --abbrev-commit
* 582d922 (HEAD -> master) add author
* 8875536 add comment
* d1be385 (origin/master) init hello
* e5e69f1 Merge branch 'dev'
...

现在我们要去推送这两次提交:git push origin master
但是失败了,说明有人先于我们推送,应该先抓取合并一下:git pull
没有冲突,抓取合并成功。
再查看一下提交历史,加上刚才合并的提交,现在本地比远程提前三个提交:

1
2
3
4
5
6
7
8
9
$ git log --graph --pretty=oneline --abbrev-commit
* e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit
|\
| * f005ed4 (origin/master) set exit=1
* | 582d922 add author
* | 8875536 add comment
|/
* d1be385 init hello
...

唉,怎么多了个分叉?如果现在提交,强迫症表示不能接受,那怎么办?
rebase 来变基操作:

1
git rebase

变基后,再来查看提交历史:

1
2
3
4
5
6
$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master) add author
* 3611cfe add comment
* f005ed4 (origin/master) set exit=1
* d1be385 init hello
...

分叉没了!这下清爽多了,可以开心推送了:git push origin master
再来看看效果,远程分支也是一条直线:

1
2
3
4
5
6
$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master, origin/master) add author
* 3611cfe add comment
* f005ed4 set exit=1
* d1be385 init hello
...

总结:
有了 rebase 可以把本地「未推送」的分叉提交历史整理成直线,这样看起来会更直观。但变基之后相关推送的 commit id 会发生改变。
另外,在 rebase 过程中还可能发生冲突,就需要其他操作了,这篇文章可作为参考:rebase

标签管理

发布一个版本时,通常会在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签时刻的历史版本取出来。所以,标签也是版本库的一个快照。

Git 的标签虽然是版本库的快照,但其实它就是指向某个 commit 的指针(跟分支很像,但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。

有了 commit,为什么还要引入 tag
因为 commit id 是一串字符串,不好查找。有了标签,可以迅速找到对应的 commit

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

创建标签

1
2
3
git tag <name>      // 创建标签

git tag // 查看所有标签

默认标签对应到最新提交,如果要在历史提交上打标签,需要先找到对应提交的 commit id:

1
git tag <name> <commit id>

{Note} 查看标签时,标签不是按时间顺序列出,而是按字母排序的

1
git show <tagname>      // 查看标签信息

还可以创建有说明的标签:

1
git tag -a v0.3 -m "version 0.3 released" 1094adb

注意
标签总是和某个 commit 挂钩。如果这个 commit 既出现在 master 分支,又出现在 dev 分支,那么在这两个分支上都可以看到这个标签。

操作标签

1
git tag -d v0.3      // 删除标签

标签只存储在本地,不会自动推送到远程。若要推送标签:

1
2
git push origin v1.0      // 推送单个标签
git push origin --tags // 推送所有未推送过的本地标签

若标签已推送到远程,要删除远程标签:

1
2
git tag -d v0.9      // 需要先删除本地标签
git push origin :refs/tags/v0.9 // 然后再删除远程标签,命令也是 push

使用GitHub

GitHub 不仅是个远程仓库,还是一个开源协作社区。

利用 Git 强大的克隆和分支功能,人们可以自由参与各种开源项目。

如何参与?
访问相关项目的 GitHub 主页,点 Fork 就在自己的账号下克隆一个相同仓库,然后再从自己的仓库克隆到本地
(!必须从自己的仓库克隆,不然没有权限推送)

推送修改到自己的仓库,如果想让项目官方接受你的修改,就可以发起一个 pull request,是否接受就是对方的权限了。

自定义 Git

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

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

1
$ git config --global color.ui true

这样,Git 会适当地显示不同的颜色,比如 git status 命令,文件名就会标上颜色。

忽略特殊文件

有时候,某些文件并不需要放入版本库进行管理,但工作目录又少不了它们,比如配置文件,这时就要创建一个 .gitignore 文件来让 Git 忽略它们。

在项目根目录或者特定目录中新建 .gitignore 文件,将要忽略的文件名写入即可。可以是某个文件,某个文件夹。
github/gitignore 提供了很多示例,可以参考。
当然,别忘了提交 gitignore 文件。

> 忽略文件的原则:

  1. 忽略操作系统自动生成的文件,比如缩略图等;
  2. 忽略编译生成的中间文件、可执行文件等。也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
  3. 忽略带有敏感信息的文件,比如存放口令的配置文件。

另外,如果某个文件已被忽略,但确实想添加,可以用 -f 强制添加:

1
git add -f .env

配置别名

配置别名可以有效地「偷懒」
比如,之前学到的命令 git reset HEAD file,将暂存区的内容撤销,重新放回工作区,可以配置为 unstage

1
git config --global alias.unstage 'reset HEAD'

比如,配置一个命令来查看最近一次提交:

1
git config --global alias.last 'log -1'

比如,将复杂的命令简化,用 git lg 查看漂亮可视化的提交历史:

1
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

配置文件
在配置时若加上 --global 参数,表示全局配置所有仓库,但只对当前用户起作用;
如果不加,只对当前仓库起作用。

如果加上全局参数,配置文件在用户主目录下的 .gitconfig 文件;
如果不加,会在对应仓库的 .git/config 文件中。

配置文件可以自定义修改,别名配置也可以在其中修改,如果改错了,可以删除配置文件重新通过命令配置。

搭建 Git 服务器

搭建 Git 服务器很简单,主要在于权限的管理。
现在还用不到,就不记录了。

0%
Title - Artist
0:00