【Git学习1】

版本控制（Revision control）

【Git工作流程】

• Workspace：工作区
• Index / Stage：暂存区
• Repository：仓库区（或本地仓库）
• Remote：远程仓库
• 【工作区】
  程序员进行开发改动的地方，是你当前看到的，也是最新的。平常我们开发就是拷贝远程仓库中的一个分支，基于该分支进行开发。在开发过程中就是对工作区的操作。
• 【暂存区】
  .git目录下的index文件, 暂存区会记录git add添加文件的相关信息(文件名、大小、timestamp…)，不保存文件实体, 通过id指向每个文件实体。可以使用git status查看暂存区的状态。暂存区标记了你当前工作区中，哪些内容是被git管理的。当你完成某个需求或功能后需要提交到远程仓库，那么第一步就是通过git add先提交到暂存区，被git管理
• 【本地仓库】
  保存了对象被提交 过的各个版本，比起工作区和暂存区的内容，它要更旧一些。git commit后同步index的目录树到本地仓库，方便从下一步通过git push同步本地仓库与远程仓库的同步。
• 【远程仓库】
  远程仓库的内容可能被分布在多个地点的处于协作关系的本地仓库修改，因此它可能与本地仓库同步，也可能不同步，但是它的内容是最旧的。
  在 Git 内都只有三种状态：已修改（modified），已暂存（staged）和已提交（committed）

基本的 Git 工作流程如下：
1、在工作目录中修改某些文件。
2、对修改后的文件进行快照，然后保存到暂存区域。
3、提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。

【Git配置】

当安装完 Git 应该做的第一件事就是设置你的用户名称与邮件地址。 这样做很重要，因为Git是分布式版本控制系统，所以每个机器都必须自报家门，并且它会写入到你的每一次提交中，不可更改：

• $ git config --global user.name “Your Name”
• $ git config --global user.email “email@example.com"

再次强调，如果使用了 --global 选项，那么该命令只需要运行一次，因为之后无论你在该系统上做任何事情， Git 都会使用那些信息。 当你想针对特定项目使用不同的用户名称与邮件地址时，可以在那个项目目录下运行没有 --global 选项的命令来配置。

如果想要检查你的配置，可以使用 git config --list 命令来列出所有 Git 当时能找到的配置。

你可以通过输入 git config ： 来检查 Git 的某一项配置

• $ git config user.name

列出所有 Git 当时能找到的配置。

• $ git config --list

【git bash 操作文件和文件夹命令】

• mkdir: 新建一个目录,就是新建一个文件夹. 如mkdir src 新建src 文件夹.
• cd : 切换到哪个目录下， 如 cd d:\fff 切换 D 盘下面的fff 目录。
  　　 当我们用cd 进入文件夹时,我们可以使用 通配符*, cd f*, 如果E盘下只有一个f开头的文件夹,它就会进入到这个文件夹.
• cd … 回退到上一个目录， 注意，cd 和两个点点…之间有一个空格。
• pwd : 显示当前目录路径。
• ls:列出当前目录中的所有文件
• ll:列出当前目录中的所有文件(更详细)
• touch “文件名加后缀” : 新建一个文件 如 touch index.js 就会在当前目录下新建一个index.js文件。
• vi “文件名加后缀” : 新建一个文件
• rm “文件名加后缀” : 删除一个文件, rm index.js 就会把index.js文件删除.
• rm -r : 删除一个文件夹, rm -r src 删除src目录， 好像不能用通配符。
• mv 移动文件, mv index.html src index.html 是我们要移动的文件, src 是目标文件夹,当然, 这样写,必须保证文件和目标文件夹在同一目录下.
• reset 清屏，把git bash命令窗口中的所有内容清空。

【常用命令】

• git init ---------------- 在现有目录中初始化仓库，仅仅是做了一个初始化的操作，项目里的文件还没有被跟踪。
• rm -rf .git ---------------- 删除当前目录下库
• git clone git@github.com:sayhiss/learngit.git ---------------- 克隆远程库
• git clone git@github.com:sayhiss/learngit.git mygit ---------------- 在克隆远程仓库的时候，自定义本地仓库的名字
• mkdir “目录名” ---------------- 创建一个空目录
• cd “目录名” ---------------- 进入文件夹
• git status ---------------- 检查当前文件状态
• git add readme.txt ---------------- 追踪新文件
• git add . ---------------- 追踪当前目录下所有文件
• git commit -m “描述信息” ---------------- 提交更新
• git commit -a -m “描述信息” ---------------- 跳过add直接提交更新
• git commit --amend -m “描述信息” ---------------- 覆盖暂存区文件（用于更新描述）
• git rm “文件加后缀” ---------------- 把文件删除，前提是git已经追踪这个文件
• git rm --cached “文件加后缀” ---------------- 让文件保留在磁盘，但不让 Git 继续跟踪
• git rm “文件加后缀” “文件名” ---------------- 移动文件,重命名
• git log ---------------- 查看提交历史，q退出

默认不用任何参数的话，git log 会按提交时间列出所有的更新，最近的更新排在最上面。 正如你所看到的，这个命令会列出每个提交的
SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。 一个常用的选项是 -p，用来显示每次提交的内容差异。 也可以加上 -x 来仅显示最近x次提交。如果你想看到每次提交的简略的统计信息，你可以使用 --stat 选项。另外一个常用的选项是 --pretty。
这个选项可以指定使用不同于默认格式的方式展示提交历史。 这个选项有一些内建的子选项供你使用。 比如用 oneline
将每个提交放在一行显示，查看的提交数很大时非常有用。 另外还有 short，full 和 fuller 可以用，展示的信息或多或少有些不同。

• git checkout – 文件名加后缀 ---------------撤销修改，在没有add到暂存区之前，其实是将版本库中版本替换工作区中的版本
• git remote add origin git@github.com:sayhiss/kingway.git --------------- 添加远程库
• git remote --------------- 查看远程库
• git remote -v ---------------查看所以远程库详细
• git remote show < remote name > ---------------查看远程库详细信息
• git remote rename < old name> < new name> --------------- 重命名指定远程库
• git remote rm < remote name> --------------- 删除指定远程库
• git fetch < remote name> --------------- 从远程库抓取
• git push < remote name> < branch name> --------------- 推送,第一次推送的时候要加-u

只有当你有所克隆服务器的写入权限，并且之前没有人推送过时，这条命令才能生效。
当你和其他人在同一时间克隆，他们先推送到上游然后你再推送到上游，你的推送就会毫无疑问地被拒绝。
你必须先将他们的工作拉取下来并将其合并进你的工作后才能推送。

• git tag < tag name> --------------- 设置标签

在 Git 中列出已有的标签是非常简单直观的。 只需要输入 git tag 。你也可以使用特定的模式查找标签。 例如，Git
自身的源代码仓库包含标签的数量超过 100 个。 如果只对 1.0 系列感兴趣，可以运行git tag -l “v1.0.*” 。

• git tag -a < tag name> -m “描述信息” --------------- 创建一个附注标签
• git show --------------- 查看对应标签信息和提交信息
• git tag -a < tag name> < commit id> --------------- 给对应版本打标签
• git reset --hard < commit id> --------------- 回退版本
• git reflog --------------- 查看回退信息

【Git常用命令速查表】

【Git 分支管理】

在进行提交操作时，Git 会保存一个提交对象（commit object）。该提交对象会包含一个指向暂存内容快照的指针。 该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象，
为了更加形象地说明，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。 暂存操作会为每一个文件计算校验和，然后会把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 对象来保存它们），最终将校验和加入到暂存区域等待提交：
$ git add README test.rb LICENSE
$ git commit -m ‘The initial commit of my project’
当使用 git commit 进行提交操作时，Git 会先计算每一个子目录（本例中只有项目根目录）的校验和，然后在 Git 仓库中这些校验和保存为树对象。 随后，Git 便会创建一个提交对象，它除了包含上面提到的那些信息外，还包含指向这个树对象（项目根目录）的指针。如此一来，Git 就可以在需要的时候重现此次保存的快照。
现在，Git 仓库中有五个对象：三个 blob 对象（保存着文件快照）、一个树对象（记录着目录结构和 blob 对象索引）以及一个提交对象（包含着指向前述树对象的指针和所有提交信息）。

【图】首次提交对象及其树结构

做些修改后再次提交，那么这次产生的提交对象会包含一个指向上次提交对象（父对象）的指针。

【图】提交对象及其父对象

Git 的分支，其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master。 在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支。 它会在每次的提交操作中自动向前移动。

【图】分支及其提交历史

【Git分支创建】

Git 是怎么创建新分支的呢？ 很简单，它只是为你创建了一个可以移动的新的指针。 比如，创建一个 testing 分支， 你需要使用 git branch 命令：
$ git branch testing
这会在当前所在的提交对象上创建一个指针。

【图】两个指向相同提交历史的分支

那么，Git 又是怎么知道当前在哪一个分支上呢？ 也很简单，它有一个名为 HEAD 的特殊指针。 指向当前所在的本地分支（译注：将 HEAD 想象为当前分支的别名）。 在本例中，你仍然在 master 分支上。 因为 git branch 命令仅仅 创建 一个新分支，并不会自动切换到新分支中去。

【图】指向当前所在的分支

你可以简单地使用 git log 命令查看各个分支当前所指的对象。 提供这一功能的参数是 --decorate。
$ git log --oneline --decorate
f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #1328 - stack overflow under certain conditions
98ca9 initial commit of my project
正如你所见，当前 “master” 和 “testing” 分支均指向校验和以 f30ab 开头的提交对象。

【分支切换】

要切换到一个已存在的分支，你需要使用 git checkout 命令。 我们现在切换到新创建的 testing 分支去：
$ git checkout testing
这样 HEAD 就指向 testing 分支了。

那么，这样的实现方式会给我们带来什么好处呢？ 现在不妨再提交一次：
$ vim test.rb
$ git commit -a -m ‘made a change’

如图所示，你的 testing 分支向前移动了，但是 master 分支却没有，它仍然指向运行 git checkout 时所指的对象。 这就有意思了，现在我们切换回 master 分支看看：
$ git checkout master

这条命令做了两件事。 一是使 HEAD 指回 master 分支，二是将工作目录恢复成 master 分支所指向的快照内容。 也就是说，你现在做修改的话，项目将始于一个较旧的版本。 本质上来讲，这就是忽略 testing 分支所做的修改，以便于向另一个方向进行开发。

我们不妨再稍微做些修改并提交：
$ vim test.rb
$ git commit -a -m ‘made other changes’
现在，这个项目的提交历史已经产生了分叉。 因为刚才你创建了一个新分支，并切换过去进行了一些工作，随后又切换回 master 分支进行了另外一些工作。 上述两次改动针对的是不同分支：你可以在不同分支间不断地来回切换和工作，并在时机成熟时将它们合并起来。 而所有这些工作，你需要的命令只有 branch、checkout 和 commit。

你可以简单地使用 git log 命令查看分叉历史。 运行 git log --oneline --decorate --graph --all ，它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。
$ git log --oneline --decorate --graph --all

• c2b9e (HEAD, master) made other changes
  | * 87ab2 (testing) made a change
  |/
• f30ab add feature #32 - ability to add new formats to the
• 34ac2 fixed bug #1328 - stack overflow under certain conditions
• 98ca9 initial commit of my project
  由于 Git 的分支实质上仅是包含所指对象校验和（长度为 40 的 SHA-1 值字符串）的文件，所以它的创建和销毁都异常高效。 创建一个新分支就相当于往一个文件中写入 41 个字节（40 个字符和 1 个换行符），如此的简单能不快吗？
  这与过去大多数版本控制系统形成了鲜明的对比，它们在创建分支时，将所有的项目文件都复制一遍，并保存到一个特定的目录。 完成这样繁琐的过程通常需要好几秒钟，有时甚至需要好几分钟。所需时间的长短，完全取决于项目的规模。而在 Git 中，任何规模的项目都能在瞬间创建新分支。 同时，由于每次提交都会记录父对象，所以寻找恰当的合并基础（译注：即共同祖先）也是同样的简单和高效。 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。

【分支的新建和合并】

让我们来看一个简单的分支新建与分支合并的例子，实际工作中我们即将会用到类似的工作流。 你将经历如下步骤：
1 开发某个网站。
2 为实现某个新的需求，创建一个分支。
3 在这个分支上开展工作。
正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理：
1 切换到你的线上分支（production branch）。
2 为这个紧急任务新建一个分支，并在其中修复它。
3 在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。
4 切换回你最初工作的分支上，继续工作。

【新建分支】

首先，我们假设你正在你的项目上工作，并且已经有一些提交。

现在，你已经决定要解决你的公司使用的问题追踪系统中的 #53 问题。 想要新建一个分支并同时切换到那个分支上，你可以运行一个带有 -b 参数的 git checkout 命令：
$ git checkout -b iss53
Switched to a new branch “iss53”
它是下面两条命令的简写：
$ git branch iss53
$ git checkout iss53

你继续在 #53 问题上工作，并且做了一些提交。 在此过程中，iss53 分支在不断的向前推进，因为你已经检出到该分支（也就是说，你的 HEAD 指针指向了 iss53 分支）
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]’

现在你接到那个电话，有个紧急问题等待你来解决。 有了 Git 的帮助，你不必把这个紧急问题和 iss53 的修改混在一起，你也不需要花大力气来还原关于 53# 问题的修改，然后再添加关于这个紧急问题的修改，最后将这个修改提交到线上分支。 你所要做的仅仅是切换回 master 分支。
但是，在你这么做之前，要留意你的工作目录和暂存区里那些还没有被提交的修改，它可能会和你即将检出的分支产生冲突从而阻止 Git 切换到该分支。 最好的方法是，在你切换分支之前，保持好一个干净的状态。 现在，我们假设你已经把你的修改全部提交了，这时你可以切换回 master 分支了：
$ git checkout master
Switched to branch ‘master’
这个时候，你的工作目录和你在开始 #53 问题之前一模一样，现在你可以专心修复紧急问题了。 请牢记：当你切换分支的时候，Git 会重置你的工作目录，使其看起来像回到了你在那个分支上最后一次提交的样子。 Git 会自动添加、删除、修改文件以确保此时你的工作目录和这个分支最后一次提交时的样子一模一样。
接下来，你要修复这个紧急问题。 让我们建立一个针对该紧急问题的分支（hotfix branch），在该分支上工作直到问题解决：
$ git checkout -b hotfix
Switched to a new branch ‘hotfix’
$ vim index.html
$ git commit -a -m ‘fixed the broken email address’
[hotfix 1fb7853] fixed the broken email address
1 file changed, 2 insertions(+)

你可以运行你的测试，确保你的修改是正确的，然后将其合并回你的 master 分支来部署到线上。 你可以使用 git merge 命令来达到上述目的：
$ git checkout master
$ git merge hotfix
Updating f42c576…3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
在合并的时候，你应该注意到了"快进（fast-forward）"这个词。 由于当前 master 分支所指向的提交是你当前提交（有关 hotfix 的提交）的直接上游，所以 Git 只是简单的将指针向前移动。 换句话说，当你试图合并两个分支时，如果顺着一个分支走下去能够到达另一个分支，那么 Git 在合并两者的时候，只会简单的将指针向前推进（指针右移），因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进（fast-forward）”。
现在，最新的修改已经在 master 分支所指向的提交快照中，你可以着手发布该修复了。

【图】master 被快进到 hotfix

关于这个紧急问题的解决方案发布之后，你准备回到被打断之前时的工作中。 然而，你应该先删除 hotfix 分支，因为你已经不再需要它了 —— master 分支已经指向了同一个位置。 你可以使用带 -d 选项的 git branch 命令来删除分支：
$ git branch -d hotfix
Deleted branch hotfix (3a0874c).
现在你可以切换回你正在工作的分支继续你的工作，也就是针对 #53 问题的那个分支（iss53 分支）。
$ git checkout iss53
Switched to branch “iss53”
$ vim index.html
$ git commit -a -m ‘finished the new footer [issue 53]’
[iss53 ad82d7a] finished the new footer [issue 53]
1 file changed, 1 insertion(+)

【图】 继续在 iss53 分支上的工作

你在 hotfix 分支上所做的工作并没有包含到 iss53 分支中。 如果你需要拉取 hotfix 所做的修改，你可以使用 git merge master 命令将 master 分支合并入 iss53 分支，或者你也可以等到 iss53 分支完成其使命，再将其合并回 master 分支。
分支的合并
假设你已经修正了 #53 问题，并且打算将你的工作合并入 master 分支。 为此，你需要合并 iss53 分支到 master 分支，这和之前你合并 hotfix 分支所做的工作差不多。 你只需要检出到你想合并入的分支，然后运行 git merge 命令：
$ git checkout master
Switched to branch ‘master’
$ git merge iss53
Merge made by the ‘recursive’ strategy.
index.html | 1 +
1 file changed, 1 insertion(+)
这和你之前合并 hotfix 分支的时候看起来有一点不一样。 在这种情况下，你的开发历史从一个更早的地方开始分叉开来（diverged）。 因为，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git 不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并。

【图】一次典型合并中所用到的三个快照

和之前将分支指针向前推进所不同的是，Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。 这个被称作一次合并提交，它的特别之处在于他有不止一个父提交。

【图】一个合并提交

需要指出的是，Git 会自行决定选取哪一个提交作为最优的共同祖先，并以此作为合并的基础；这和更加古老的 CVS 系统或者 Subversion （1.5 版本之前）不同，在这些古老的版本管理系统中，用户需要自己选择最佳的合并基础。 Git 的这个优势使其在合并操作上比其他系统要简单很多。
既然你的修改已经合并进来了，你已经不再需要 iss53 分支了。 现在你可以在任务追踪系统中关闭此项任务，并删除这个分支。
$ git branch -d iss53

【遇到冲突时的分支合并】

有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关 hotfix 的修改都涉及到同一个文件的同一处，在合并它们的时候就会产生合并冲突：
$ git merge iss53

此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件：
$ git status

任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记，这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段，
这表示 HEAD 所指示的版本（也就是你的 master 分支所在的位置，因为你在运行 merge 命令的时候已经检出到了这个分支）在这个区段的上半部分（======= 的上半部分），而 iss53 分支所指示的版本在 ======= 的下半部分。 为了解决冲突，你必须选择使用由 ======= 分割的两部分中的一个，或者你也可以自行合并这些内容。 例如，你可以通过把这段内容换成下面的样子来解决冲突：
< div id=“footer”>
please contact us at email.support@github.com
</ div>
上述的冲突解决方案仅保留了其中一个分支的修改，并且 <<<<<<< , ======= , 和 >>>>>>> 这些行被完全删除了。 在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。
如果你想使用图形化工具来解决冲突，你可以运行 git mergetool，该命令会为你启动一个合适的可视化合并工具，并带领你一步一步解决这些冲突：
$ git mergetool
如果你觉得上述的信息不够充分，不能完全体现分支合并的过程，你可以修改上述信息，添加一些细节给未来检视这个合并的读者一些帮助，告诉他们你是如何解决合并冲突的，以及理由是什么。

以上大量资料和案例皆来源于《Pro Git》，链接地址：https://git-scm.com/book/zh/v2/
其实还是很多个git的知识没有讲到，但截至以上知识几乎可以胜任工作的所有内容。