Git学习笔记

此篇笔记是学习参考廖雪峰老师的Git教程,附上学习网址:https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

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

先说集中式版本控制系统,版本库是集中存放在中央服务器的,而干活的时候,用的都是自己的电脑,所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家自己改,改完了,再放回图书馆。

集中式版本控制系统最大的毛病就是必须联网才能工作,如果在局域网内还好,带宽够大,速度够快,可如果在互联网上,遇到网速慢的话,可能提交一个10M的文件就需要5分钟,这还不得把人给憋死啊。

那分布式版本控制系统与集中式版本控制系统有何不同呢?首先,分布式版本控制系统根本没有“中央服务器”,每个人的电脑上都是一个完整的版本库,这样,你工作的时候,就不需要联网了,因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库,那多个人如何协作呢?比方说你在自己电脑上改了文件A,你的同事也在他的电脑上改了文件A,这时,你们俩之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。

和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了。

在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。

1 安装Git

针对windows端,下载地址:https://git-scm.com/download/win

选择想要存放的地址,默认安装即可。安装成功后第一件事就是要让它知道自己的主人是谁,因为每一个Git的提交都会使用到这些信息,一旦确定不可更改。

安装完后进入安装目录,在命令行模式下输入以下命令:

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

可使用如下代码查看自己的注册成功与否:

git config --list

2 工作区、暂存区、版本库

Git的核心框架为:工作区域、暂存区域和Git仓库

在初始化git版本库之后会生成一个隐藏的文件 .git ,可以将该文件理解为git的版本库 repository,而我们自己建立的项目文件夹即工作区 working directory,在.git 文件夹里面还有很多文件,其中有一个index 文件 就是暂存区也可以叫做 stage,git还为我们自动生成了一个分支master以及指向该分支的指针head,如下图所示:

从图中可以看出来respository包括分支master和stage, working diretory 可以理解为我们打开开发环境如eclipse,里面的内容即工作区的内容,在工作区里面有的代码以及配置文件等我们需要提交到版本库里面,最终是到了分支master上面,暂存区只是一个临时保存修改文件的地方。

工作区域(Working Directory):就是你平时存放项目代码的地方

暂存区域(Stage):用于临时存放你的改动,事实上它只是一个文件,保存即将提交的文件列表信息。

Git仓库(Repository):就是安全存放数据的位置,这里有你提交的所有版本的数据,其中HEAD指向最新放入仓库的版本。

Git的工作流程如下: (1)在工作目录中添加、修改文件;

(2)将需要进行版本管理的文件放入暂存区域;

(3)将暂存区域的文件提交到Git仓库。

因此,Git管理的文件有三种状态:已修改(modified)、已暂存(staged)和已提交(committed),依次对应上面的每一个流程。有时你并不想把工作目录中的所有新功能都提交到最新版本,你就可以先添加一些本次需要提交的文件到暂存区,然后从暂存区中提交它们,所以暂存区又称“索引”。

3 创建版本库并添加文件

选择一个合适的地方,创建一个空目录。如下通过git init命令把这个目录变成Git可以管理的仓库:

当前目录下会多一个.git的目录,是Git用来跟踪管理版本库的,不要轻易改动,否则将会破坏Git仓库,该目录默认是隐藏的。

所有的版本控制系统其实只能跟踪文本文件的改动,如果要真正使用版本控制系统,就要以纯文本方式编写文件。建议使用Notepad++代替记事本进行编辑,记得把Notepad++的默认编码设置为UTF-8 without BOM即可。在MyGit文件夹下新建一个readme.md文件,内容如下:

Git is a version control system.
Git is free software.

接着我们把该文件放到Git仓库: (1)用命令git add告诉Git,把文件添加到仓库:

git add readme.md

(2)用命令git commit告诉Git,把文件提交到仓库:

git commit命令,-m后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样你就能从历史记录里方便地找到改动记录。git commit命令执行成功后会告诉你,1个文件被改动(我们新添加的readme.txt文件),插入了两行内容(readme.txt有两行内容)。为什么Git添加文件需要addcommit一共两步呢?因为commit可以一次提交很多文件,所以你可以多次add不同的文件,比如:

git add file1.txt
git add file2.txt file3.txt
git commit -m "add 3 files."

4 查看工作状态和历史提交

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

将readme.md文件修改如下:

Git is a distributed version control system.
Git is free software.

如下所示,git status告诉我们readme.md被修改了,但还没准备提交的修改,git diff告诉我们被修改的内容,显示的格式是Unix通用的diff格式。

知道了作了什么修改后,可提交修改,同3所示。

5 版本回退

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

6 管理修改

Git管理的是添加到暂存区里面的修改,而非文件。包括增删改等等都算是可以跟踪的文件变动,也可以说git只管理我们变动的部分变动的我们才往暂存区提交,这也是git比其他版本系统设计优秀的一点。

举例说明,在readme.md中加入一行:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.

通过add添加后,再修改最后一句为:

Git tracks changes of files.

通过commit提交后发现第二次的修改没有被提交,原因是因为Git管理的是修改,当你用git add命令后,在工作区的第一次修改被放入暂存区,准备提交,但是,在工作区的第二次修改并没有放入暂存区,所以,git commit只负责把暂存区的修改提交了,也就是第一次的修改被提交了,第二次的修改不会被提交。

每次修改,如果不add到暂存区,那就不会加入到commit中。

7 撤销修改

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

8 删除文件

新建一个test.txt文件到Git并提交,如果直接在文件管理器中删除了该文件,或者使用rm/del命令删除,此时删除的是工作区的文件。Git知道你删除了文件,因此,工作区和版本库就不一致了,可通过git status查看哪些文件被删除了。

此时版本库中还存在该文件,则使用git rm命令删除,并且通过git commit提交。

rm只是删除了你想删除的文件,是在工作区操作的,还没有把这个修改放到暂存区,然后你用“git rm”命令,就是把工作区删除文件的操作放到了暂存区的。

但是如果你直接用“git rm”命令,就相当于直接完成了“rm”和“git rm”这两个命令,前一个命令被自动执行了。这时候你再“git status”一下,你就会发现,你已经把删除工作区文件这个操作放到了暂存区,只等你提交到版本库里去了。注意看以上的代码的第四行“ (use "git add/rm <file>..." to update what will be committed)”。当你“rm”操作以后,再进行“git rm”,其实和“git add”的作用是等同的。

如果在工作区中误删除了文件,版本库仍然存在该文件,所以可以使用git checkout版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。

git checkout -- test.txt

9 远程仓库

Github网站提供Git仓库托管服务,只要注册一个Github账号,就可以免费获得Git远程仓库。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:

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

$ ssh-keygen -t rsa -C "youremail@example.com"

你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsaid_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。

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

然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容,点“Add Key”,你就应该看到已经添加的Key。

为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。

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

9.1 添加远程库

如何使本地的Git仓库和Github中的Git仓库远程同步?

首先,登录Github,右上角点击New repository,创建一个新仓库,填入仓库名称MyGit,其他保持默认设置即可。

在本地的MyGit仓库的命令行下运行如下命令:

git remote add origin git@github.com:Github账户名/MyGit.git

添加后,远程库的名字就是origin,这是Git的默认叫法,也可以更改。

下一步就可把本地库的所有内容推送到远程库上:

git push -u origin master

第一次推送时会出现警告,根据提示输入yes回车即可。

由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。第一次推送后,只要本地作了提交,就可以通过命令:

git push origin master

把本地master分支的最新修改推送至GitHub,现在,你就拥有了真正的分布式版本库!

9.2 从远程库克隆

上次我们讲了先有本地库,后有远程库的时候,如何关联远程库。现在,假设我们从零开发,那么最好的方式是先创建远程库,然后,从远程库克隆。首先,登陆GitHub,创建一个新的仓库,名字叫gitskills。勾选Initialize this repository with a README,这样GitHub会自动为我们创建一个README.md文件。创建完毕后,可以看到README.md文件。

现在,远程库已经准备好了,下一步是用命令git clone克隆一个本地库:

在Git Bash中使用git clone克隆一个本地库,或者在命令行模式下选择你要放置的文件夹,输入相同的命令:

Git支持多种协议,包括https,但通过ssh支持的原生git协议速度最快。

10 分支管理

10.1 创建与合并分支

因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master分支上工作效果是一样的,但过程更安全。

查看分支:git branch

创建分支:git branch <name>

切换分支:git checkout <name>

创建+切换分支:git checkout -b <name>

合并某分支到当前分支:git merge <name>

删除分支:git branch -d <name>

在版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支。HEAD严格来说不是指向提交,而是指向mastermaster才是指向提交的,所以,HEAD指向的就是当前分支。

一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:

每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。

当我们创建新的分支,例如dev时,Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上:

你看,Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化!

不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变:

假如我们在dev上的工作完成了,就可以把dev合并到master上。Git怎么合并呢?最简单的方法,就是直接把master指向dev的当前提交,就完成了合并:

所以Git合并分支也很快!就改改指针,工作区内容也不变!

合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支:

发现上述的命令即可在命令行的模式下进行,也可以在Git Bash下操作,以下操作在Git Bash下运行。

切换目录,首先创建dev,然后切换到dev:

git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

git branch命令会列出所有分支,当前分支前面会标一个*号。然后,我们就可以在dev分支上正常提交,比如对readme.txt做个修改,加上一行:

Creating a new branch is quick.

add并commit提交,dev分支的工作完成,可切换回master分支:

切换回master分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:

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

git merge命令用于合并指定分支到当前分支。合并后,再查看readme.txt的内容,就可以看到,和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。

当然,也不是每次合并都能Fast-forward,我们后面会讲其他方式的合并。

合并完成后,就可以放心地删除dev分支了:

10.2 解决冲突

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

git log --graph命令可以看到分支合并图。

10.3 分支管理策略

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

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

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

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

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

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

10.4 Bug分支

修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;

当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场。

10.5 Feature分支

开发一个新feature,最好新建一个分支;

如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>强行删除。

10.6 多人协作

  • 查看远程库信息,使用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,如果有冲突,要先处理冲突。

11 标签管理

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

Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。tag就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起。

11.1 创建标签

  • 命令git tag <name>用于新建一个标签,默认为HEAD,也可以指定一个commit id(使用git log --pretty=oneline --abbrev-commit查看历史提交的commit id,使用git tag <tagname> commit id即可打标签);
  • git tag -a <tagname> -m "blablabla..."可以指定标签信息,用命令git show <tagname>可以看到说明文字;
  • git tag -s <tagname> -m "blablabla..."可以用PGP签名标签;
  • 命令git tag可以查看所有标签。

11.2 操作标签

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

12 使用GitHub

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

13 使用码云

14 自定义Git

此节包含以下内容,可点击查看Git教程中的描述。

忽略特殊文件

配置别名

搭建Git服务器

15 Git Cheat Sheet

最后附上Git的常用命令总结的Git Cheat Sheet

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏草根专栏

Git -- 分支与合并 (命令行+可视化工具p4merge) Fast Forward 合并禁用 Fast Forward 合并自动合并解决合并的冲突

基本命令 把所有的变化都放在master分支并不是最好的做法. 建议的做法是把变化放在分支里面. ? 至少应该准备一个feature分支之类的, 把变化都隔离开...

3579
来自专栏草根专栏

Git -- 分支与合并 (命令行+可视化工具p4merge)

把所有的变化都放在master分支并不是最好的做法. 建议的做法是把变化放在分支里面.

6418
来自专栏iOS 开发杂谈

源码管理工具之git的使用

git是目前世界上被最广泛使用的现代软件版本管理系统。git本身亦是一个成熟并处于活跃开发状态的开源项目,它最初是由Linux操作系统内核的创造者Linus T...

2132
来自专栏古时的风筝

Maven 私服的简单使用

当我们再 pom 文件中依赖了某个包后,如果在没有做特殊配置(也就是使用 maven 的默认配置)的情况下,Maven 会首先到本地仓库去搜索,如果本地仓库没有...

1.7K9
来自专栏LanceToBigData

Git(一)之基本操作详解

前言   在这段时间的工作中一直都是用Git作为版本控制,只是知道简单的几个命令,没有去了解它的内部原理。所以周末有时间来系统学习。   现在的公司基本上都是用...

20410
来自专栏静默虚空的博客

分布式版本控制系统 Git 教程

简介 Git 是什么? Git 是一个开源的分布式版本控制系统。 什么是版本控制? 版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统...

2526
来自专栏我的博客

ES中的分布式搜索

一.查询阶段 查询会广播到索引的每个分片(主分片或者副本分片),每个分片搜索并构建一个匹配结果的优先队列(存储top-n文档有序列表) 步骤: 1.发送请...

37311
来自专栏企鹅号快讯

写在2018第一天:编程之路始于Git

git是目前世界上使用最广泛的分布式版本控制系统,由大名鼎鼎的Linus花了两周时间写成,同时在2008年使用给git作为唯一版本库格式托管平台gitHub网站...

1915
来自专栏腾讯DevOps

Git快速入门

git作为现在最为流行的版本管理系统,大部分公司都使用git进行版本控制,并且最大程序员交友网站github也是在git的基础上建立的。 很多人认为git难,在...

1994
来自专栏漫漫深度学习路

git 常用流程

git 常用流程 关于 ssh key 第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_r...

2165

扫码关注云+社区

领取腾讯云代金券