前言
这篇笔记主要是在看书时记录的自己觉得会用到的一些实用操作和涉及的相关概念。基本上讲每个操作的时候,都会给一个我觉得这个操作最常见使用情景,很多使用情景我已经亲身经历过了。
笔记
对现有的某个项目进行 git 管理,即从一个现有项目目录初始化项目仓库
在项目根目录下执行如下命令即可。git init
删除一个本地仓库
为什么要删除一个本地仓库,比如说我们把一个远端仓库 clone 到了错误的位置,又比如说这个仓库是一个临时创建的测试用的。这个直接删除文件夹就可以了,并不需要什么特殊的 git 命令。忽略某些文件
- 为什么要忽略某些文件,忽略某些文件会产生什么样的效果?
忽略某些文件是因为我们不需要对其进行版本控制,如项目每次生成的可执行文件。但默认情况下,这些文件又会出现在项目仓库的未跟踪文件列表中,那通过忽略这些文件,就可以在项目仓库的未跟踪列表中消灭他们。 - 怎么忽略?
忽略文件通过编辑 .gitignore 文件实现。.gitignore 文件位于项目仓库的根目录下,该文件使用的匹配模式为 glob 模式,是一种简化的正则表达式。找个时间我们可以定制一个我们常用的 .gitignore 文件。另外,gitignore.io 这个网站对 .gitignore 的编辑是一个非常大帮助,它可以根据语言,系统,IDE 生成特定的 .gitignore 文件,是一个非常好的参考。
- 为什么要忽略某些文件,忽略某些文件会产生什么样的效果?
撤销操作。
撤销操作包括以下 3 种常见的使用情景。修改最后一次的提交
为什么要修改最后一次的提交?可能的情况是想修改最后一次提交的注释,或者最后一次提交时少提交了一些文件,想把之前这些忘记提交的文件重新提交上去,但又不想产生一次新的提交操作。对于前者,直接运行下面这条命令即可,对于后者需要把那些之前忘记提交的文件加入到暂存区域后在运行下面这条命令。git commit --amend
取消已经暂存的文件
该操作就是将文件从已暂存状态恢复到已修改状态。主要目的就是将修改过的文件分批次提交。git reset HEAD <file>
取消对文件的修改
该操作将文件从已修改状态恢复到未修改状态。也就是说,我们之前对文件做的修改将彻底消失。执行这个操作一定要想清楚git checkout -- <file>
移除文件
移除文件分为以下两种情况删除文件
这个无论是通过git rm <file>
删除文件,还是不用这个命令直接删除文件,本质上并没有什么区别。想删就删,就这样。
从项目仓库的已跟踪清单中删除文件
这种情况下,文件本身并不会删除,只是不再被项目仓库跟踪,不再处于版本控制下。这种情况应该还是比较常见的,比如,我基于一个现有项目初始化了一个项目仓库,然后运行git add .
将该项目目录下的所有文件都加入到了项目仓库的已跟踪清单中,可是这其中有些文件并不需要版本控制,比如项目编译时产生的可执行文件,中间文件之类,所以我就需要将这些文件从项目仓库的已跟踪清单中删除掉。怎么做?方法如下:
git rm --cached <file>
重命名文件
重命名操作这个感觉还是用git mv <filename> <newfilename>
命令好。如果不用这个命令直接去重命名文件,git 并不会识别出我们对这个文件的重命名操作,它会认为被我们重命名的文件被删除了,然后项目目录下有一个新的文件。下面是我们将一个名为 test.md 的文件不用 git mv 命令重命名为 test2.md 后 git 显示的信息。
HDMMacBook-Pro:simplegit-progit HDM$ git status
On branch master
Your branch is ahead of ‘origin/master’ by 9 commits.
(use “git push” to publish your local commits)
Changes not staged for commit:
(use “git add/rm …” to update what will be committed)
(use “git checkout – …” to discard changes in working > directory)deleted: test2.md
Untracked files:
(use “git add …” to include in what will be committed)test.md
no changes added to commit (use “git add” and/or “git commit -a”)
标签
标签是跟某一次提交操作相关的。通常情况下,我们添加的标签是和最后一次提交操作关联起来的,这也是最常见的使用情况,比如现在我们完成了项目的第一个版本,代码也提交完毕,那现在我们就可以打一个标签,表示这次提交的代码就是项目的第一个版本;另一种使用情景是我们要给以前的某一次提交操作添加一个标签,比如在项目进程中,之前我们没有做好版本的划分,现在,我们想把之前某一次提交的代码看做版本 1,那我们也可以对这个以前的提交操作添加一个标签。应该说标签这个功能在维护一个大的,长久的项目,应该是非常有用的。自动补全
这个就是在终端中使用 Git 时自动补全命令的。就是一个配置的问题。如何查看某个提交对象对应的那个版本的代码
这是一个突然遇到的需求,书上也没说。想了想,想到了这样一个方法。比如说我们现在想查看 41688ce 代表的这个提交对象说对应的那个版本代码,那我们可以这样做。从 41688ce 表示的提交对象开始创建一个新的分支 temp
git branch temp 41688ce
切换到 temp 分支
git checkout temp
- 查看想看的代码
看完了想看的代码,删除 temp 分支
git branch -d temp
储藏
使用情景
假如我们现在在 master 分支做了一些修改,然后想切换到 temp 分支临时看一些东西,但问题是如果我们不提交 master 当前的这些修改的话,我们是无法切换到 temp 分支的。怎么办?怎么在不提交我们目前在 master 分支所做的修改的情况下切换到 temp 分支?答案就是储藏。上面这个例子应该是储藏最常见的一个使用情景了。我也是实际遇到过,才真真实实的感受到储藏的有用之处。
使用步骤
下面的使用步骤是基于上面的使用情景的。在 master 分支创建储藏
git stash
- 切换到 temp 分支,然后查看想要的代码
切换回 master 分支,应用储藏
git stash apply --index
丢弃储藏
git stash drop
文件标注
- 作用
会显示文件中对每一行进行修改的最近一次提交。 - 使用情景
这是我遇到过的可以使用这个功能的使用情景。具体情况是,当时我和同事争论这段有问题的代码是谁写的?这个功能简直可以完美回答这个问题。
- 作用
分支的衍和
- 使用衍和的目的
一般我们使用衍合的目的,是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者,但想帮点忙的话,最好用衍合:先在自己的一个分支里进行开发,当准备向主项目提交补丁的时候,根据最新的 origin/master 进行一次衍合操作然后再提交,这样维护者就不需要做任何整合工作(译注:实际上是把解决分支补丁同最新主干代码之间冲突的责任,化转为由提交补丁的人来解决。),只需根据你提供的仓库地址作一次快进合并,或者直接采纳你提交的补丁。
怎么理解上面这段话呢?下面是我的分析。
就上面这个例子来讲,衍和确实很有用,因为这里我们不是项目的维护者,也就是说,我们不能对项目的 master 分支做任何处理,我们不能把我们自己的分支合并到 master 分支上,那么当我们想把在我们自己的分支上开发的特性合并到 master 分支时,通常情况下,我们只能简单的 push 我们的分支,然后由项目的维护者合并我们的分支到 master 分支上,那这期间可能遇到的冲突也就需要维护者去处理,但通过衍和,那些可能的冲突其实是由我们解决了,维护者只需要简单的将我们的分支快速合并到 master 分支就可以了,因为衍和后,master 现在所指向的提交对象是我们的分支所指向的提交对象的直接上游,所以,这里的合并操作把 master 指针前移而已(有什么不明白的查下fast forward)。
- 使用衍和的目的