git

Posted on 2021-01-30 In 杂项 Views:

版本控制系统的作用就是方便的管理文件的各个版本，如果我们对比如文件的第99个版本不满意，可以令它轻易的回滚到第98个甚至第一个版本。另外，版本控制系统还方便了多人共同开发一个项目，因为它可以这个项目进行集中式的管理。

本博文为赵珊珊老师网课笔记。

1. git介绍

版本控制系统分为两类，第一类是集中式版本控制系统，如SVN，它是由【一个公共的】服务器进行版本控制，这种做法的弊端就是可靠性不高，如果出现单点故障很可能导致数据丢失。另外SVN只能逐步进行版本回滚，比如当前版本99，想回滚到版本1，只能99回到98，98回到97…

另一类是分布式管理系统，如git，它由【分布式的多个】服务器进行版本控制，相比SVN它的可靠性更高。且git可以直接回滚到任意版本。

git结构分为【本地库】，【暂存区】和【工作区】。用户在工作区编辑文件，通过git add命令将文件发送到暂存区，然后通过git commit命令将暂存区中的文件提交到本地库中，本地库中存储了该文件的各个历史版本。

接着，本地库要与远程库（代码托管中心）交互。

当局域网内部通过远程库合作时（即内部团队协作开发场景），可以选择搭建gitlab服务器作为远程库：

由项目经理首先创建自己的本地库，并写好项目架构文件，将其push到公司内部的远程库中。
开发人员向项目经理取得其架构文件的访问权，然后去远程库将架构文件clone到自己的本地库中
开发人员按照架构文件写好代码，将代码从自己的本地库push到远程库中
项目经理收到文件更新通知，去远程库将新版本的文件pull到自己的本地库中

当跨公司使用远程库合作时（多公司协作开发场景，每个公司各有自己的远程库），一般选择用github或者gitee作为远程库：

本地库与远程库在局域网内部的交互同上，特殊点在于当公司A和公司B的远程库进行交互时（假定公司A主管项目）

公司B将A公司的远程库fork到自己的远程库中，开始开发
开发完成，公司B对公司A的远程库发起pull request
公司A审核公司B提交的代码，如果通过，就将其代码merge到自己的远程库中

2. 初始化本地仓库

用git bash进入到自己的仓库目录下，使用git init命令，生成.git文件表明git仓库初始化成功。

3. 向本地仓库中提交文件

在仓库目录下，创建需要版本控制的文件，如first.txt
将需要版本控制的文件提交到暂存区：git add first.txt。（必须经过这一步才能最终将它提交到本地库）
将暂存区的文件commit到本地库中：git commit -m “这里是对本次提交的注释” first.txt

4. 查看暂存区和工作区中有没有未commit的文件

创建两个文件，一个unAdd.txt放在工作区（未add），一个unCommit.txt放在暂存区（未commit），使用 git status 查看状态：

5. 修改工作区文件内容后

我们将first.txt的内容更改后，查看状态

因此修改后要重新add并commit该文件。

6. 查看commit记录

接上一小节，将first.txt重新add并commit后，查看 git log

其中黄色commit之后的哈希值是key，这个key对应的value就是本地库的某一个版本

可以用加强版命令查看：git reflog

该命令显示的库版本哈希值精简了，HEAD@{num}中的NUM代表某一个版本在本地仓库中的存储索引（HEAD是操作指针）。该图第一行（蓝色HEAD所在行）就是我们当前工作区对应的本地库版本

7. 前进或后退到某版本

先用git reflog查看本地库所有版本以及它们的索引（就是HEAD后花括号中的数值）。

假设现在要后退到版本3，输入

git reset –hard 6a54aa7 //hard参数使得本地库和工作区以及暂存区的数据同步，必须要加

再查看git reflog

再更改first.txt，然后再add，commit，看reflog

8. 删除文件

删除工作区文件

rm test.txt
将删除操作同步到暂存区

git add test.txt
将删除操作同步到本地库

git commit -m “删除test.txt文件” test.txt

效果如下

9. 恢复文件

回滚到删除文件前的版本即可

10. 比对不同区域中所有文件的区别

【比对工作区和暂存区中所有文件的区别】使用命令：git diff

【比对暂存区和本地库中所有文件的区别】使用命令：git diff 历史某版本索引号文件名

11. 分支

在之前的图片中可以看到当前目录后标识了(master)，这意味着我们当前位于master（主干）分支上。一般情况下，公司机构的git主干分支上的项目版本都是稳定版，是已经投入使用的版本，也就是说，一般不会轻易的更新主干分支上的项目版本。在主干上【开分支】的情况通常有两种：1. 给项目加功能，2. 修复当前版本项目的bug。这两种情况都要对项目进行修改，而且这个修改的过程可能会对原版本产生一定的影响，为了确保万无一失，开一个分支，这个分支上克隆了当前版本项目的镜像，在这个分支上进行开发。这样做的好处是可以随时回滚（在分支上写实验版本，不想要了就丢掉，不影响主干），另外一个好处是在分支开发不会影响当前主干上最新版本的正常运行。分支开发完成后，可以将分支合并到主干，完成主干版本的更新。

11.1 查看分支

git branch -v

可以看到我们当前只有一个主干，该命令把主干上最新的提交信息做了展示。

11.2 创建分支

git branch {branchName}

* 代表我们当前在哪个分支上

可以看到刚创建的MyBranch的版本哈希和master最新的版本哈希相同，这是因为MyBranch镜像了master最新的版本号。

11.3 切换分支

git checkout {branchName}

可以看到目录后括号中内容变成了(MyBranch)，即当前位于MyBranch分支下

11.4 解决分支冲突问题

如果分支上某文件的版本更新了，主干上该文件的版本也更新了，这时如果在主干上输入命令 git merge MyBranch （表示将【MyBranch分支合并到主干上】，反之如果在分支上输入git merge master代表【将主干内容合并到分支上】），会提示错误

提示test.txt存在冲突问题，可以看到出现冲突问题时目录右侧的状态变为MERGING。

假设我们当前发生冲突的文件为test.txt，可以使用 cat {文件名} 命令来查看该文件内容，发现其内容已经变成

“========” 上方空行下方的内容是【当前分支】修改的该文件的内容，“========” 下方的内容是【待合并分支】修改的该文件的内容。

现实中如果出现这种冲突问题，就需要各分支的人员商讨，是舍弃掉某一个分支上的内容呢？还是直接合并两个分支上的内容呢？讨论完成后，直接对该冲突文件进行修改，然后将该文件add，commit更新到本地库

最后commit，注意解决冲突的commit后不能加文件名

12. 远程库

12.1 公司内部远程库交互

选用github作为远程库，先进行一下准备工作

创建Repository

现在远程库的地址就是GitResp仓库的url
为远程库url起别名

git remote add {alias} {url} 命令可以给仓库起别ing

git remote -v 命令查看远程仓库别名信息

之后就可以用别名访问远程库了，不用每次都输入很长的url