Git学习笔记

Git 是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。
Git 的作者是 Linus Torvalds（这位大神就不用多介绍了：）） ，Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，代替的原因，据说是BitKeeyper要收回Linux社区的免费使用权。于是，Trovalds决定着手研究许可证更为灵活的版本控制系统，花了一周左右的时间，开发出了Git。
最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是，现在在开源社区，已经有越来越多的项目使用了 Git。
Git站点的地址： http://git-scm.com/

从这里开始，就是在Git站点上学习Git过程中的笔记记录。遵照开源的精神，与大家一起分享。

1、初始化本地库 Initialize a Git repository

正如Git自己说的，Git是分布式的版本控制系统，可以让许多人同一时间基于同一文档（通常是代码）共同工作，而不会相互打扰（without stepping on each other’s toes）。
初始化本地库的命令如下:

git init

此命令运行后，Git会在当前的库目录创建一个 .git 文件夹.。这是一个隐藏文件夹，是Git用于管理库，跟踪过程中文档的变动等，而生成的，我们不要去手工修改里面的任何文件，尤其是在正式的工作环境中，以免带来不必要的麻烦。随意的修改会让Git失去库的配置信息，甚至破坏我们的Git库。

1. 检查 Git 库状态 Checking the Status

创建好本地库后，可以通过如下的命令，检查本地库的状态：
git status

命令运行后的显示结果如下：

# On branch master## Initial commit#nothing to commit (create/copy files and use "git add" to track)    

3、增加和提交文档 Adding & Committing

Git的线上教程中，在上面创建的版本库中，加入了一个文件名为 octocat.txt 的文件。这个时候，我们再运行 git status ，看看和上面比，有什么变化。
git status

命令运行后的显示结果如下：

# On branch master## Initial commit## Untracked files:#   (use "git add <file>..." to include in what will be committed)##   octocat.txtnothing added to commit but untracked files present (use "git add" to track)

我们刚才创建的 octocat.txt 被 Git 检查出来了，并被标记为 untracked files。

4、加入变更 Adding Changes

在上一步中，Git 把我们新增的文件标记为 untracked file，也就是说 Git 检测到了这个是新文件，但是并没有把这个变更记录到 Git 库中。
那么，如何让 Git 把这个文件记录到库中，并加以跟踪呢？答案是：向库中加入这个变更项。命令如下：
git add octocat.txt

命令运行后的显示结果如下：

不用揉眼睛了，不是你盯着屏幕时间长眼睛花了，真的是没有输出结果。很让人崩溃吧。这个大概就是应了那句名言：No news is good news。

5、再次检查 Git 库状态 Checking for Changes

既然没有输出，我们就自己来检查吧，看看这个 octocat.txt 文件，到底是有没有成功加入到 Git 库中。这次还是请出了神通广大的检查 Git 库状态的命令：
git status

命令运行后的显示结果如下：

# On branch master## Initial commit## Changes to be committed:#   (use "git rm --cached <file>..." to unstage)##    new file:   octocat.txt#

看到了，变更成功加入到 Git 库中了。

6、提交变更 Committing

在进行提交变更之前，我们先来看看 Git 对于 git add 之后的文档状态是如何处理的。Git 对于执行 git add 操作之后的文档处理为 staging 状态。这个其实是说 Git 只对文档的变更状态进行了记录，并没有把文件真正的加到库中。因此，在做完 git add 之后，我们需要通过如下的命令，把文档从 staging 区域，正式的加到库中。
git commit -m “Add cute octocat story”

解释下后面的 -m 参数，这个参数的作用是，对这次变更加上注释（comment），说明为什么要进行变更。这个参数是必须的。大家可能会觉得没有必要每次都加上注释和说明，但是，从开源项目的运作模式来说，各色人等一起干活，可能分布于世界各地，如果大家都不加注释，估计过不了多长时间，这个变更就不会再有人记得当初为什么要这么做，最后必然的结果是项目失控了。另一个方面来说，加上这个注释和说明，对其它和你一起工作的人来说，也是个不错的交流方式和展现码农专业素养的机会！：）

7、加入所有变更 Adding All Changes

“要是我有好多文档都更新了，而且在不同的目录下，怎么办？总不能让我一个一个去加吧？”你当然不用一个一个去加，Git 提供了通配符来解决这个问题。
Git 的在线教程用了一个在不同目录下，增加 .txt 文本文件，然后一起提交的例子。具体的命令如下所列，通配符部分，需要用引号包括起来。
git add ‘*.txt’

8、提交所有变更 Committing All Changes

在把所有新增的文件 git add 到 staging 区域后，我们可以用 git status 命令查看下待批量加入 Git 库的文件的状态。然后，我们用如下的命令，把所有加入的变更正式提交到 Git 库中。
git commit -m ‘Add all the octocat txt files’

9、查看历史记录 History

日志是系统必不可少的功能，当出现问题时，我们总能找到问题出在哪里，还原事实，因为，真像只有一个。Git 也不例会，提供了功能强大的日志功能。任何时候，你只要执行如下命令，就可以查看到现在为止，在我们的 Git 库上发生过什么。
git log

命令运行后的显示结果如下：

commit 3852b4db1634463d0bb4d267edb7b3f9cd02ace1Author: Try Git <[e-mail]>Date:   Sat Oct 10 08:30:00 2020 -0500    Add all the octocat txt filescommit b652edfd888cd3d5e7fcb857d0dabc5a0fcb5e28Author: Try Git <[e-mail]>Date:   Sat Oct 10 08:30:00 2020 -0500    Added cute octocat story    

10、远程库 Remote Repositories

开源的宗旨，就是要分享代码。代码放在本地，独乐乐有个什么意思。那么，怎么才能众乐乐呢？从这节开始，我们需要用到一个当前非常流行的免费开放的代码库平台 GitHub。
平台地址： https://github.com/

写这个笔记时，用的是 git 的在线教程，那么就继续用这个教程的资源来说明如何创建远程库。下面要做的，就是在 GitHub 上创建一个远程的空的 Git 库 https://github.com/try-git/try_git.git。并且，把我们的本地库上传到远程的 GitHub 服务器上。要完成这些，还得请出 git add，不过，这次中间多了个 remote。
git remote add origin https://github.com/try-git/try_git.git

别等输出了，和之前一样，没有消息就是好消息，命令执行成功。

11、远程库推送 Pushing Remotely

远程库创建好了，接下来，就把我们本地的代码推送到远程库上，共享给开源社区吧。通过执行如下命令，实现把本地库上的内容，推送到远程库上。
git push -u origin master

其实，push命令的作用，是通知 Git 把我们准备要提交的文档放到远处的某个地方。在这个命令里，远程库的名字是origin，默认本地分支的名字是 master 。命令中 -u 参数的作用，是让 push 记住这二个参数。这样做是为了在下次推送的时候，我们只要简单运行 git push，而 push 自己会知道如何处理推送。

12、拉取远程库 Pulling Remotely

假设我们的项目一天天在开源社区变得活跃了，我们邀请一些已经在他们的本地修改，提交，再推送到我们的远程库中的热心人，加入我们，和我们一起开发。
这时，我们要检查我们的 GitHub 远程库做了哪些改动，该怎么办？那简单，拉回来就是了。通过执行以下命令，可以把远程库的内容下载到本地库中。
git pull origin master

命令运行后的显示结果如下：

Updating 3852b4d..3e70b0fFast-forward yellow_octocat.txt |    1 + 1 file changed, 1 insertion(+) create mode 100644 yellow_octocat.txt  

13、比较文档更新 Differences

代码拉下来后，我们发现，代码看上去别人做了不少增加和修改的工作，怎么才能知道具体是哪些改动呢？通过执行 git diff 命令，可以比较出文档做过的具体修改细节。
git diff HEAD

命令中用到了 HEAD 指针，HEAD 指针是指向默认分支 maater 的指针，也就是最近最新的提交。

14、查找缓存的文档差异 Staged Differences

git diff的另外一个强大功能是在已经缓存的准备提交的文件中查看差别。

首先，我们就先用 git add 命令增加一个octofamily/octodog.txt文档，
git add octofamily/octodog.txt

这时，文档已经存在于缓存区（staging area），接着，我们执行带 —staged 参数选项的 git diff 命令，来看看我们刚才缓存的文档变化。
你应该可以看到 octodog.txt 文件已经被创建出来了。

git diff --staged

命令运行后的显示结果如下：

diff --git a/octofamily/octodog.txt b/octofamily/octodog.txtnew file mode 100644index 0000000..cfbc74a--- /dev/null+++ b/octofamily/octodog.txt@@ -0,0 +1 @@+[mwoof

16、重置缓存 Resetting the Stage

现在，我们 octodog 已经是 octofamily 文件夹的一部分了，但是 octocat 好像有些不开森了。我们也注意到了，我们好像喜欢 octocat 要比 octodog 多。因此，
我们决定重视 octocat 的意见，删除 octodog。（这里是 Ｇit 在线教程的直译，是教程用来构造的相关场景，便于我们学习和理解，老外还是很贴心的。）

你可以用 git reset 命令撤消缓存的文档.通过执行以下的命令，可以删除 octofamily/octodog.txt。
git reset octofamily/octodog.txt

1.17 回退更改 Undo

通过 git reset 命令，我们把 octodog.txt 文档从 Git 库的缓存中撤消了，但是，我们注意到 octodog.txt 还在工作区中存在，只是不在缓存区中了。如果能退回到 octodog 到来之前的样子就太好了了。

能过 git checkout —- 命令，我们可以把文档退回到它们最后一次被提交之前的样子。例如：执行以下命令，我们可以回退所有的更改直到 octocat.txt 最后一次被提交之前的状态。
git checkout – octocat.txt

18、创建分支 Branching Out

当开发人员进行功能开发和 bug 修改时，他们通常复制一份代码，这样他们可以对新增或修改后的代码，进行分别提交。当开发完成时，他们把这个复制的分支合并到原来的主分支上。

通过执行以下命令，我们创建一个 clean_up 分支，后续的工作，我们都将在这个分支上进行。
git branch clean_up

19、切换分支 Switching Branches

这个时候，如果你执行 git branch 命令，你就会看到有二个本地分支。一个是称为 master 的主分支，另一个是我们刚才创建的 clean_up 分支。ch named clean_up.

我们可以通过执行 git checkout clean_up 来从 master 分支切换到 clean_up 分支。
git checkout clean_up

20、从分支中删除 Removing All The Things

现在，我们可以通过执行 git rm 命令，删除所有我们不想要的文档。不过，这些删除操作，不仅会删除磁盘上的真实文件，而且，会把删对这些文档的删除进行缓存。
通过执行一个再次带上通配符的如下命令，删除之前我们创建的所有 octocat 的文件。
git rm ‘*.txt’

21、提交分支上的更改 Commiting Branch Changes

在分支上删除了那些烦人的文件后，我们需要把这些更改提交到库中。在提交之前，我们可以通过执行 git status 来预先检查下我们所作的更改。
如果一切无误，放心的执行如下的命令向你当前的分支提交更改，不要忘记加上注释。
git commit -m “Remove all the cats”

22、切换回主分支 Switching Back to master

在分支上，我们已经完成了所有的工作，接下来要做的，就是把 clean_up 分支合并回 master 主分支。
通常，我们通过执行以下命令，从当前工作分支切换回主分支。对，这个命令之前我们执行，就是从主分支 master 切换到 clean_up时用的命令。这个其实就是分支切换命令。
git checkout master

23、准备合并 Preparing to Merge

现在，我们要把 clean_up 分支上所做的工作合并回 master 主分支了。请大家做个深呼吸，见证奇迹的时候到了。

我们当前已经切换到了 master 主分支了，接下来要做的，就是告诉 Git 把 clean_up 分支上的所有工作成果合并过来。
git merge clean_up

24、清理库文档 Keeping Things Clean

到这里，我们几乎把平常代码开发过程中的基本操作全部做了一遍。剩下的工作，就是对库文档做一个全面的清理，包括过程中用到的临时分支，临时文档，缓存区的文档，以及最后提交到远程库中等工作。

通过执行以下命令，我们可以安全的删除 clean_up 分支。
git branch -d clean_up

25、完美收官 The Final Push

本地库的所有工作已经完成了，最后，我们要做的就是把我们的成果推送到远程库中，并和与我们一起工作的开发人员共享我们的成果，始终保持我们的开源的精神。
git push

感谢大家耐心的看完整个 Git 学习笔记！