Git——版本控制为王

矫情吗；* 2022-05-23 12:48 192阅读 0赞

**     前言**

单枪匹马，独闯天下的时代已经过去，团队，组织间的协同开发已然成为了主流。那么如何最大化的加快开发时间？如何确保个体差异性得以解决不冲突？svn,git等一系列版本控制软件应运而生，其中git以其优良的本地版本控制脱颖而出，成为了开发人员的必备技能。

## 1.1  git概述 ##

### 1.1.1  git前世今生 ###

同生活中的许多伟大事件一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002 年，整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。

到了 2005 年，开发 BitKeeper的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标：

\* 速度 \* 简单的设计 \* 对非线性开发模式的强力支持（允许上千个并行开发的分支）

\* 完全分布式 \* 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统，可以应付各种复杂的项目开发需求。

### 1.1.2  git开发环境 ###

**第一步、下载Git，默认安装**

下载网址https://git-scm.com/downloads

(开始菜单 -- Git --Git bash， 输入 git --version 查看版本)

**第二步、下载 TortoiseGit 图形化客户端安装**

下载网址：https://tortoisegit.org/

(必须和系统位数一致)

**第三步、登陆码云(国内最大远程仓库)，创建在线项目**

网址：[https://gitee.com/][https_gitee.com]

(复制项目所在URL：https://gitee.com/winallt/项目名，作为在线仓库位置)

**第四步、克隆在线仓库到本地：Git Clone**

**        ![70][]**

### 1.1.3  git开发流程 ###

1：从服务器上克隆数据库（包括代码和版本信息）到单机上。

2：在自己的机器上创建分支，修改代码。

3：在单机上自己创建的分支上提交代码。

4：在单机上合并分支。

5：新建一个分支，把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。

6：生成[补丁][Link 1]（patch），把补丁发送给主开发者。

7：看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。

8：一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

### 1.1.4  git工作原理 ###

Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容：

![70 1][]

其他系统在每个版本中记录着各个文件的具体差异

Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就如下图所示。

![70 2][]

Git 保存每次更新时的文件快照

这是 Git 同其他系统的重要区别。它完全颠覆了传统版本控制的套路，并对各个环节的实现方式作了新的设计。Git 更像是个小型的文件系统，但它同时还提供了许多以此为基础的超强工具，而不只是一个简单的 VCS。稍后会讨论 Git 分支管理的时候，我们会再看看这样的设计究竟会带来哪些好处：

**近乎所有操作都是本地执行**

在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。但如果用 CVCS 的话，差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。

举个例子，如果要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。所以任何时候你都可以马上翻阅，无需等待。如果想要看当前版本的文件和一个月前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算，而不用请求远程服务器来做这件事，或是把老版本的文件拉到本地来作比较。

用 CVCS 的话，没有网络或者断开 VPN 你就无法做任何事情。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程仓库。同样，在回家的路上，不用连接 VPN 你也可以继续工作。换作其他版本控制系统，这么做几乎不可能，抑或非常麻烦。比如 Perforce，如果不连到服务器，几乎什么都做不了（默认无法发出命令 p4 edit file 开始编辑文件，因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文件权限可以绕过这个限制，只是完成后还是无法提交更新。）；如果是 Subversion 或 CVS，虽然可以编辑文件，但无法提交更新，因为数据库在网络上。看上去好像这些都不是什么大问题，但实际体验过之后，你就会惊喜地发现，这其实是会带来很大不同的。

**时刻保持数据完整性**

在保存到 Git 之前，所有数据都要进行内容的校验和（checksum）计算，并将此结果作为数据的唯一标识和索引。换句话说，不可能在你修改了文件或目录之后，Git 一无所知。这项特性作为Git 的设计哲学，建在整体架构的最底层。所以如果文件在传输时变得不完整，或者磁盘损坏导致文件数据缺失，Git 都能立即察觉。

Git 使用 SHA-1 算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，作为指纹字符串。该字串由 40 个十六进制字符（0-9 及 a-f）组成，看起来就像是：

Git 的工作完全依赖于这类指纹字串，所以你会经常看到这样的哈希值。实际上，所有保存在 Git 数据库中的东西都是用此哈希值来作索引的，而不是靠文件名。

**多数操作仅添加数据**

常用的 Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作，比如删除数据，都会使回退或重现历史版本变得困难重重。在别的 VCS 中，若还未提交更新，就有可能丢失或者混淆一些修改的内容，但在 Git 里，一旦提交快照之后就完全不用担心丢失数据，特别是养成定期推送到其他仓库的习惯的话。

这种高可靠性令我们的开发工作安心不少，尽管去做各种试验性的尝试好了，再怎样也不会弄丢数据。至于 Git 内部究竟是如何保存和恢复数据的，我们会在后面讨论 Git 内部原理时再作详述。

**文件的三种状态**

好，现在请注意，接下来要讲的概念非常重要。对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库中了；已修改表示修改了某个文件，但还没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。

由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。

![70 3][]

工作目录，暂存区域，以及本地仓库

每个项目都有一个 Git 目录（如果 git clone 出来的话，就是其中 .git 的目录；如果 git clone --bare 的话，新建的目录本身就是 Git 目录。），它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。

从项目中取出某个版本的所有文件和目录，用以开始后续工作的叫做[工作目录][Link 2]。这些文件实际上都是从 Git 目录中的压缩对象数据库中提取出来的，接下来就可以在工作目录中对这些文件进行编辑。

所谓的暂存区域只不过是个简单的文件，一般都放在 Git 目录中。有时候人们会把这个文件叫做索引文件，不过标准说法还是叫暂存区域。

## 1.2  git常用命令 ##

\#\#\#git init

在本地新建一个repo,进入一个项目目录,执行git init,会初始化一个repo,并在当前文件夹下创建一个.git文件夹.

\#\#\#git clone

获取一个url对应的远程Git repo, 创建一个local copy.

一般的格式是git clone \[url\].

clone下来的repo会以url最后一个斜线后面的名称命名,创建一个文件夹,如果想要指定特定的名称,可以git clone \[url\] newname指定.

\#\#\#git status

查询repo的状态.

git status -s: -s表示short, -s的输出标记会有两列,第一列是对staging区域而言,第二列是对working目录而言.

\#\#\#git log

show commit history of a branch.

git log --oneline --number: 每条log只显示一行,显示number条.

git log --oneline --graph:可以图形化地表示出分支合并历史.

git log branchname可以显示特定分支的log.

git log --oneline branch1 ^branch2,可以查看在分支1,却不在分支2中的提交.^表示排除这个分支(Window下可能要给^branch2加上引号).

git log --decorate会显示出tag信息.

git log --author=\[author name\] 可以指定作者的提交历史.

git log --since --before --until --after 根据提交时间筛选log.

--no-merges可以将merge的commits排除在外.

git log --grep 根据commit信息过滤log: gitlog --grep=keywords

默认情况下, git log --grep --author是OR的关系,即满足一条即被返回,如果你想让它们是AND的关系,可以加上--all-match的option.

git log -S: filter by introduced diff.

比如: git log -SmethodName (注意S和后面的词之间没有等号分隔).

git log -p: show patch introduced at each commit.

每一个提交都是一个快照(snapshot),Git会把每次提交的diff计算出来,作为一个patch显示给你看.

另一种方法是git show \[SHA\].

git log --stat: show diffstat of changes introduced at each commit.

同样是用来看改动的相对信息的,--stat比-p的输出更简单一些.

\#\#\#git add

在提交之前,Git有一个暂存区(staging area),可以放入新添加的文件或者加入新的改动. commit时提交的改动是上一次加入到staging area中的改动,而不是我们disk上的改动.

git add .

会递归地添加当前工作目录中的所有文件.

\#\#\#git diff

不加参数的git diff:

show diff of unstaged changes.

此命令比较的是工作目录中当前文件和暂存区域快照之间的差异,也就是修改之后还没有暂存起来的变化内容.

若要看已经暂存起来的文件和上次提交时的快照之间的差异,可以用:

git diff --cached 命令.

show diff of staged changes.

(Git 1.6.1 及更高版本还允许使用 git diff --staged，效果是相同的).

git diff HEAD

show diff of all staged or unstated changes.

也即比较woking directory和上次提交之间所有的改动.

如果想看自从某个版本之后都改动了什么,可以用:

git diff \[version tag\]

跟log命令一样,diff也可以加上--stat参数来简化输出.

git diff \[branchA\] \[branchB\]可以用来比较两个分支.

它实际上会返回一个由A到B的patch,不是我们想要的结果.

一般我们想要的结果是两个分支分开以后各自的改动都是什么,是由命令:

git diff \[branchA\]…\[branchB\]给出的.

实际上它是:git diff $(git merge-base\[branchA\] \[branchB\]) \[branchB\]的结果.

\#\#\#git commit

提交已经被add进来的改动.

git commit -m “the commit message"

git commit -a 会先把所有已经track的文件的改动add进来,然后提交(有点像svn的一次提交,不用先暂存). 对于没有track的文件,还是需要git add一下.

git commit --amend 增补提交. 会使用与当前提交节点相同的父节点进行一次新的提交,旧的提交将会被取消.

\#\#\#git reset

undo changes and commits.

这里的HEAD关键字指的是当前分支最末梢最新的一个提交.也就是版本库中该分支上的最新版本.

git reset HEAD: unstage files from index and reset pointer to HEAD

这个命令用来把不小心add进去的文件从staged状态取出来,可以单独针对某一个文件操作: git reset HEAD - - filename, 这个- - 也可以不加.

git reset --soft

move HEAD to specific commit reference, index and staging are untouched.

git reset --hard

unstage files AND undo any changes in the working directory since lastcommit.

使用git reset —hard HEAD进行reset,即上次提交之后,所有staged的改动和工作目录的改动都会消失,还原到上次提交的状态.

这里的HEAD可以被写成任何一次提交的SHA-1.

不带soft和hard参数的git reset,实际上带的是默认参数mixed.

总结:

git reset --mixed id,是将git的HEAD变了(也就是提交记录变了),但文件并没有改变，(也就是working tree并没有改变). 取消了commit和add的内容.

git reset --soft id. 实际上，是git reset –mixed id 后,又做了一次git add.即取消了commit的内容.

git reset --hard id.是将git的HEAD变了,文件也变了.

按改动范围排序如下:

soft (commit) <mixed (commit + add) < hard (commit + add + local working)

\#\#\#git revert

反转撤销提交.只要把出错的提交(commit)的名字(reference)作为参数传给命令就可以了.

git revert HEAD: 撤销最近的一个提交.

git revert会创建一个反向的新提交,可以通过参数-n来告诉Git先不要提交.

\#\#\#git rm

git rm file: 从staging区移除文件,同时也移除出工作目录.

git rm --cached: 从staging区移除文件,但留在工作目录中.

git rm --cached从功能上等同于git reset HEAD,清除了缓存区,但不动工作目录树.

\#\#\#git clean

git clean是从工作目录中移除没有track的文件.

通常的参数是git clean -df:

-d表示同时移除目录,-f表示force,因为在git的配置文件中, clean.requireForce=true,如果不加-f,clean将会拒绝执行.

\#\#\#git mv

git rm - - cached orig; mv orig new; git add new

\#\#\#git stash

把当前的改动压入一个栈.

git stash将会把当前目录和index中的所有改动(但不包括未track的文件)压入一个栈,然后留给你一个clean的工作状态,即处于上一次最新提交处.

git stash list会显示这个栈的list.

git stash apply:取出stash中的上一个项目(stash@\{0\}),并且应用于当前的工作目录.

也可以指定别的项目,比如git stash apply stash@\{1\}.

如果你在应用stash中项目的同时想要删除它,可以用git stash pop

删除stash中的项目:

git stash drop: 删除上一个,也可指定参数删除指定的一个项目.

git stash clear: 删除所有项目.

\#\#\#git branch

git branch可以用来列出分支,创建分支和删除分支.

git branch -v可以看见每一个分支的最后一次提交.

git branch: 列出本地所有分支,当前分支会被星号标示出.

git branch (branchname): 创建一个新的分支(当你用这种方式创建分支的时候,分支是基于你的上一次提交建立的).

git branch -d (branchname): 删除一个分支.

删除remote的分支:

git push (remote-name) :(branch-name): delete a remote branch.

这个是因为完整的命令形式是:

git push remote-name local-branch:remote-branch

而这里local-branch的部分为空,就意味着删除了remote-branch

git branch --set-upstream dev origin/<branch>

修改本地分支与远程分支链接关系

\#\#\#git checkout

git checkout(branchname)   切换到一个分支.

git checkout -b (branchname): 创建并切换到新的分支.

这个命令是将git branch newbranch和git checkout newbranch合在一起的结果.

checkout还有另一个作用:替换本地改动:

git checkout --<filename>

此命令会使用HEAD中的最新内容替换掉你的工作目录中的文件.已添加到暂存区的改动以及新文件都不会受到影响.

注意:git checkout filename会删除该文件中所有没有暂存和提交的改动,这个操作是不可逆的.

\#\#\#git merge

把一个分支merge进当前的分支.

git merge \[alias\]/\[branch\]

把远程分支merge到当前分支.

如果出现冲突,需要手动修改,可以用git mergetool.

解决冲突的时候可以用到git diff,解决完之后用git add添加,即表示冲突已经被resolved.

\#\#\#git tag

tag a point in history as import.

会在一个提交上建立永久性的书签,通常是发布一个release版本或者ship了什么东西之后加tag.

比如: git tag v1.0

git tag -a v1.0, -a参数会允许你添加一些信息,即make anannotated tag.

当你运行git tag -a命令的时候,Git会打开一个编辑器让你输入tag信息.

我们可以利用commit SHA来给一个过去的提交打tag:

git tag -a v0.9 XXXX

push的时候是不包含tag的,如果想包含,可以在push时加上--tags参数.

fetch的时候,branchHEAD可以reach的tags是自动被fetch下来的, tags thataren’t reachablefrom branch heads will be skipped.如果想确保所有的tags都被包含进来,需要加上--tags选项.

\#\#\#git remote

list, add and delete remote repository aliases.

因为不需要每次都用完整的url,所以Git为每一个remote repo的url都建立一个别名,然后用git remote来管理这个list.

git remote: 列出remote aliases.

如果你clone一个project,Git会自动将原来的url添加进来,别名就叫做:origin.

git remote -v:可以看见每一个别名对应的实际url.

git remote add \[alias\] \[url\]: 添加一个新的remote repo.

git remote rm \[alias\]: 删除一个存在的remote alias.

git remote rename \[old-alias\] \[new-alias\]: 重命名.

git remote set-url \[alias\] \[url\]:更新url. 可以加上—push和fetch参数,为同一个别名set不同的存取地址.

\#\#\#git fetch

download new branches and data from a remote repository.

可以git fetch \[alias\]取某一个远程repo,也可以git fetch --all取到全部repo

fetch将会取到所有你本地没有的数据,所有取下来的分支可以被叫做remote branches,它们和本地分支一样(可以看diff,log等,也可以merge到其他分支),但是Git不允许你checkout到它们.

\#\#\#git pull

fetch from a remote repo and try to merge into the current branch.

pull == fetch + merge FETCH\_HEAD

git pull会首先执行gitfetch,然后执行git merge,把取来的分支的head merge到当前分支.这个merge操作会产生一个新的commit.

如果使用--rebase参数,它会执行git rebase来取代原来的git merge.

\#\#\#git rebase

--rebase不会产生合并的提交,它会将本地的所有提交临时保存为补丁(patch),放在”.git/rebase”目录中,然后将当前分支更新到最新的分支尖端,最后把保存的补丁应用到分支上.

rebase的过程中,也许会出现冲突,Git会停止rebase并让你解决冲突,在解决完冲突之后,用git add去更新这些内容,然后无需执行commit,只需要:

git rebase --continue就会继续打余下的补丁.

git rebase --abort将会终止rebase,当前分支将会回到rebase之前的状态.

\#\#\#git push

push your new branches and data to a remote repository.

git push \[alias\] \[branch\]

将会把当前分支merge到alias上的\[branch\]分支.如果分支已经存在,将会更新,如果不存在,将会添加这个分支.

如果有多个人向同一个remote repo push代码, Git会首先在你试图push的分支上运行git log,检查它的历史中是否能看到server上的branch现在的tip,如果本地历史中不能看到server的tip,说明本地的代码不是最新的,Git会拒绝你的push,让你先fetch,merge,之后再push,这样就保证了所有人的改动都会被考虑进来.

\#\#\#git reflog

git reflog是对reflog进行管理的命令,reflog是git用来记录引用变化的一种机制,比如记录分支的变化或者是HEAD引用的变化.

当git reflog不指定引用的时候,默认列出HEAD的reflog.

HEAD@\{0\}代表HEAD当前的值,HEAD@\{3\}代表HEAD在3次变化之前的值.

git会将变化记录到HEAD对应的reflog文件中,其路径为.git/logs/HEAD, 分支的reflog文件都放在.git/logs/refs目录下的子目录中.

### 1.3 git常用操作(用于idea) ###

**1、在idea中配置git**

**        第一步、配置git        ![70 4][]**

**第二步、下载gitee插件并配置**

![70 5][]

![70 6][]

**2、git基本流程**

![70 7][]

![70 8][]

**3、分支管理**

**     **   查看分支：(带\*为当前分支，红色为远程分支)

![70 9][]

创建分支：

**            ![70 10][]**

**       ** 删除分支：

![70 11][]

创建远程分支

![70 12][]

**4、解决冲突**

**               ** git pull :本地分支与远程分支对应时使用（建议使用工具而非命令行）

git merge  ---git fetch:本地分支与目标远程分支不一致

（解决完毕后，需要git add 然后重新commit）

**5、版本回滚(当提交错误代码，或者解决冲突失败)**

**           **     git reset --hard head (使用需谨慎，该操作会冲掉上次提交后的改动)

**最后友情提示**

**    请善用**

**![70 13][]**

**  log日志**

[https_gitee.com]: https://gitee.com/
[70]: /images/20220523/5abea95d3f174c48aab694ae394b5f49.png
[Link 1]: https://baike.so.com/doc/2037224-2155525.html
[70 1]: /images/20220523/f7f45509e8cf4d6dad1cb0b770c518ec.png
[70 2]: /images/20220523/b3f51017b11c4cabbe6e48206d651a3e.png
[70 3]: /images/20220523/e78fe2dae0134f4889c13abeaa557010.png
[Link 2]: http://www.nowamagic.net/academy/tag/%E5%B7%A5%E4%BD%9C%E7%9B%AE%E5%BD%95
[70 4]: /images/20220523/79844050f8a44d01aaa6daefc614a6a1.png
[70 5]: /images/20220523/686cdbfe50784b538df75d08b7d3424c.png
[70 6]: /images/20220523/7549e6de94964d81be842da7f134910d.png
[70 7]: /images/20220523/c0d97c87a8a5421a9925c726ae84b615.png
[70 8]: /images/20220523/133258d7e630415ab8d178e4e67db65a.png
[70 9]: /images/20220523/20d691bfcf7f4efe8cc558fd2de0b4d1.png
[70 10]: /images/20220523/5f31302cd62342e4a026c79b8c7169af.png
[70 11]: /images/20220523/cf1095bc040a4cfbaebf61feb3d7e0e4.png
[70 12]: /images/20220523/92b28e3012534de0a8f2b1551868a779.png
[70 13]: /images/20220523/cf7c363dfdca4795a091d54ac93bf583.png