Git修炼之路(二)

工作区和暂存区

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

工作区 —— 本系列上一篇文章Git修炼之路(一) 提到的 git init 命令执行的目录就是一个工作区(Working Directory)。

版本库 —— 工作区中有个隐藏目录 .git,这不算工作区,而是Git的版本库(Repository),如下图所示。

版本库

在刚开始创建版本库时,Git就自动的创建了一个master分支,并且将HEAD指向master分支的最新提交点 —— 此时工作区和版本库中的master保持一致,并且暂存区(版本库中的stage)为空(因为还没有进行 git add)。

然后我们进行的一些修改都是在工作区进行的,修改完后(新增、删除或修改文件)就通过 git add 命令添加到暂存区。

暂存区是个很重要的概念,弄懂了暂存区就能明白Git的很多操作

通常一个新手修改了某个文件,并执行了 git add 操作,然后又修改了某些文件,最后执行 git commit 命令,却发现第二次的修改没有提交到本地版本库,这都是未能正确理解暂存区而造成的(此时可以再次执行 git  add 命令 ,最后再执行 git commit 操作,相当于将两次修改合并提交了)。

撤销修改

之所以Git相比其他版本控制系统如此优秀,是因为Git跟踪管理的是修改,而并非文件。本系列上一篇文章讲到了版本回退,但有时候我们需要更细粒度的控制

还记得 git checkout 吗?使用 git checkout 版本号的前几位就可以回退到指定版本,而使用 git checkout -- 文件名 可以丢弃修改至某个存档的状态(执行 git add 或 git commit 后就相当于这里的一次存档)。

考虑下面三个场景

  1. 改乱了工作区的内容并且没有执行git add 添加到暂存区,此时直接使用 git checkout -- 文件名(注意 -- 和 文件名之间有空格,没有--,就变成了切换分支的命令了)。
  2. 改乱了工作区的内容并且添加到了暂存区,此时使用上一步骤的命令发现没有任何变化。想丢弃修改有两个步骤 —— 第一,使用 git reset HEAD 文件名 将暂存区的修改撤销,重新放回工作区;第二,使用上一步骤的命令(因为此时就相当于回到了上一场景了)。
  3. 改乱了工作区的内容并且添加到了暂存区,最后还使用了 git commit 提交到了本地版本库,请参考本系列上一篇文章的版本回退。

分支管理

每次提交到本地版本库,都会产生一个版本(又叫节点),将这些节点串成一条时间线,就是一个分支。刚开始Git默认会创建master分支,并且将HEAD指向master最新的提交节点,如下图所示。

Git分支01

当我们不管是个人使用还是团队协作时最好都别在master分支上直接修改,因此需要新建分支。常见的分支有dev分支(日常开发使用)、feature分支(开发新功能使用)、hotfix分支(修复BUG使用)。

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

Git分支02

当我们在dev分支上开发并提交到版本库时,此时dev分支的内容就会提前master分支,当合并到master分支时,直接将master指针指向dev的最新提交点即可,如下图所示。

Git分支03

使用 git branch -d dev 就可以将dev分支删除,也就是删除上图红色的部分。

一些分支相关的命令:

  • git branch 会列出所有的分支,并在当前分支前面标上*号。
  • git branch 分支名 创建新的分支。
  • git checkout -b 分支名 创建并转到新的分支。
  • git checkout 分支名 切换到指定分支。
  • git merge 分支名 将分支与当前分支合并。
  • git branch -d 分支名 删除指定分支。

小结

本文介绍了Git的一些强大特性,特别是分支管理,简直是团队管理的利器,当然个人使用也有点必要。

IntelliJ IDEA、Pycharm对分支管理都有强大的支持,合理利用可以进一步提高效率。

参考

Git:合并分支----git merge命令应用的三种情景

合并分支到master上

Git修炼之路(一)

评论或私信站长


  1. #该文章暂时没有评论