git学习使用

1、git处理分支的方式

在进行提交操作时，Git会保存一个提交对象（commit object）。知道了Git保存数据的方式，我们可以很自然的想到——该提交对象会包含一个指向暂存内容快照的指针。 但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象。

2、分支创建

创建一个 testing分支——git branch testing，两个指向相同提交历史的分支。

那么，Git又是怎么知道当前在哪一个分支上呢？ 也很简单，它有一个名为 HEAD 的特殊指针。 请注意它和许多其它版本控制系统（如 Subversion 或 CVS）里的 HEAD 概念完全不同。 在 Git中，它是一个指针，指向当前所在的本地分支（译注：将 HEAD 想象为当前分支的别名）。 在本例中，你仍然在master 分支上。 因为 git branch 命令仅仅 创建 一个新分支，并不会自动切换到新分支中去。

HEAD 指向当前所在的分支，你可以简单地使用 git log 命令查看各个分支当前所指的对象。 提供这一功能的参数是 --decorate。

3、分支切换

git checkout testing 这样 HEAD 就指向 testing 分支了。

上面的创建分支和切换分支命令可以合起来用下面这个命令来替代。

$ git checkout -b testing

那么，这样的实现方式会给我们带来什么好处呢？ 现在不妨再提交一次：

$ vim test.rb
$ git commit -a -m 'made a change'

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

$ git checkout master

检出时 HEAD 随之移动。
这条命令做了两件事。 一是使 HEAD 指回 master 分支，二是将工作目录恢复成 master 分支所指向的快照内容。 也就是说，你现在做修改的话，项目将始于一个较旧的版本。 本质上来讲，这就是忽略testing 分支所做的修改，以便于向另一个方向进行开发。
可以使用 git branch命令查看当前分支，注意前面带*的表示当前分支

分支切换会改变你工作目录中的文件
在切换分支时，一定要注意你工作目录里的文件会被改变。 如果是切换到一个较旧的分支，你的工作目> 录会恢复到该分支最后一次提交时的样子。 如果Git不能干净利落地完成这个任务，它将禁止切换分支。

4、合并分支（快速合并）

假如我们在testing上的工作完成了，就可以把testing合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向testing的当前提交，就完成了合并，这里你需要使用git merge命令。

$ git merge testing
Updating 64ba18a..760118b
Fast-forward
 hello.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 hello.txt

git merge命令用于合并指定分支到当前分支。合并后，再查看内容，就可以看到，和testing分支的最新提交是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向testing的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。

5、删除分支

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支,这里需要使用git branch -d命令来删除分支

6、分支合并冲突

准备新的dev分支，继续我们的新分支开发：

$ git checkout -b dev
Switched to a new branch 'dev'

修改README.md内容，添加一样内容”day day up~”，在dev分支上提交：

$ git commit -am "one commit"
[dev 6a6a08e] one commit
 1 file changed, 1 insertion(+)

切换到master分支：

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。
在master分支上把README.md文件的最后改为 good good study,然后提价

$ git commit -am "two commit"
[master 75d6f25] two commit
 1 file changed, 1 insertion(+)

现在，master分支和dev分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

我们可以直接查看README.md的内容：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存，再提交，用带参数的git log也可以看到分支的合并情况：

7、合并分支（普通合并）

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下–no-ff方式的git merge：
首先，仍然创建并切换dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'

修改README.md文件，并提交一个新的commit：

$ git commit -am 'submit'
[dev fee6025] submit
 1 file changed, 1 insertion(+)

现在，我们切换回master：

$ git checkout master
Switched to branch 'master'

目前来说流程图是这样：

准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 README.md | 1 +
 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

合并后，我们用git log看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit
*   b98f802 merge with no-ff
|\
| * fee6025 submit
|/
*   9a4d00b merge commit

可以看到，不使用Fast forward模式，merge后就像这样：

8、Git 取消所有本地修改

本地修改了许多文件，其中有些是新增的，因为开发需要这些都不要了，想要丢弃掉，或者是因为实现某个功能，但是没有成功，反而把代码搞得一团糟糕，这个时候我们可以取消本地所有的更改，回复到更改之前的状态，可以使用如下命令：

git checkout . #本地所有修改的。没有的提交的，都返回到原来的状态
git stash #把所有没有提交的修改暂存到stash里面。可用git stash pop回复。
git reset --hard HASH #返回到某个节点，不保留修改。
git reset --soft HASH #返回到某个节点。保留修改
 
git clean -df #返回到某个节点
git clean 参数
    -n 显示 将要 删除的 文件 和  目录
    -f 删除 文件
    -df 删除 文件 和 目录
 

总结

到此，Git分支管理就学完了，整理一下所学的命令，大体如下：

git branch           查看当前分支
git branch -v        查看每一个分支的最后一次提交
git branch -a        查看本地和远程分支的情况
git branch --merged  查看已经与当前分支合并的分支
git branch --no-merged 查看已经与当前分支未合并的分支
git branch -r        查看远程分支
git branch dev       创建分支 dev
git checkout dev     切换到分支dev
git checkout -b dev  创建并切换分支dev
git merge dev        名称为dev的分支与当前分支合并
git branch -d dev    删除分支dev

git命令
git干货系列：（五）多人协同工作之分支管理 | 嘟嘟独立博客