@@ -114,12 +116,12 @@
# 一、译序
-这篇指南以大家在`SVN`中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的`Pull Request`功能，体系地讲解了各种工作流的应用。
-如果你`Git`用的还不多，可以从前面的讲的工作流开始操练。操作过程去感受指南的讲解：解决什么问题、如何解决问题，这样理解就深了，也方便活用。
+这篇指南以大家在`SVN`中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的`Pull Request`功能，系统地讲解了各种工作流的应用。
+如果你`Git`用的还不多，可以从前面的讲的工作流开始操练。在操作过程中去感受指南的讲解：解决什么问题、如何解决问题，这样理解就深了，也方便活用。
行文中实践原则和操作示例并重，对于`Git`的资深玩家可以梳理思考提升，而新接触的同学，也可以跟着step-by-step操练学习并在实际工作中上手使用。
-工作流其实不是一个初级主题，背后的本质问题其实是 有效的项目流程管理 和 高效的开发协同约定，而不仅是`Git`或`SVN`等[`VCS`](http://zh.wikipedia.org/wiki/%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6)或[`SCM`](http://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86)工具的使用。
+工作流其实不是一个初级主题，背后的本质问题是 有效的项目流程管理 和 高效的开发协同约定，而不仅仅是`Git`或`SVN`等[`VCS`](http://zh.wikipedia.org/wiki/%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6)或[`SCM`](http://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86)工具的使用。
关于`Git`工作流主题，网上体系的中文资料不多，主要是零散的操作说明，希望这篇文章能让你更深入理解并在工作中灵活有效地使用起来。
@@ -143,7 +145,7 @@
- :see_no_evil: [自己](http://weibo.com/oldratlee)理解粗浅，翻译中不足和不对之处，欢迎 :clap:
- 建议，[提交`Issue`](https://github.com/oldratlee/translations/issues/new)
- 指正，[`Fork`后提通过`Pull Requst`贡献修改](https://github.com/oldratlee/translations/fork)
-- 如有文章理解上有疑问 或是 使用过程中碰到些疑惑，请随意:raised_hands:[提交`Issue`](https://github.com/oldratlee/translations/issues/new) ，一起交流学习讨论！
+- 如有文章理解上有疑问 或是 使用过程中碰到些疑惑，请随时:raised_hands:[提交`Issue`](https://github.com/oldratlee/translations/issues/new) ，一起交流学习讨论！
----------------
@@ -161,10 +163,10 @@
如果你的开发团队成员已经很熟悉`Subversion`，集中式工作流让你无需去适应一个全新流程就可以体验`Git`带来的收益。这个工作流也可以作为向更`Git`风格工作流迁移的友好过渡。
-转到分布式版本控制系统看起来像个令人生畏的任务，但不改变已用的工作流你也可以用上`Git`带来的收益。团队可以用和`Subversion`完全不变的方式来开发项目。
+转到分布式版本控制系统看起来像个令人生畏的任务，但不改变已用的工作流，你也可以用上`Git`带来的收益。团队可以用和`Subversion`完全不变的方式来开发项目。
-但使用`Git`加强开发的工作流，`Git`有相比`SVN`的几个优势。
-首先，每个开发可以有属于自己的整个工程的本地拷贝。隔离的环境让各个开发者的工作和项目的其他部分修改独立开来 ——
+但使用`Git`加强开发的工作流，相比`SVN`，`Git`有以下两个优势:
+首先，每个开发者可以有属于自己的整个工程的本地拷贝。隔离的环境让各个开发者的工作和项目的其他部分修改独立开来 ——
即自由地提交到自己的本地仓库，先完全忽略上游的开发，直到方便的时候再把修改反馈上去。
其次，`Git`提供了强壮的分支和合并模型。不像`SVN`，`Git`的分支设计成可以做为一种用来在仓库之间集成代码和分享修改的『失败安全』的机制。
@@ -173,9 +175,9 @@
像`Subversion`一样，集中式工作流以中央仓库作为项目所有修改的单点实体。相比`SVN`缺省的开发分支`trunk`，`Git`叫做`master`，所有修改提交到这个分支上。本工作流只用到`master`这一个分支。
-开发者开始先克隆中央仓库。在自己的项目拷贝中像`SVN`一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
+首先，开发者克隆中央仓库。在自己的项目拷贝中，像`SVN`一样的编辑文件和提交修改；但修改是存在本地的，和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
-要发布修改到正式项目中，开发者要把本地`master`分支的修改『推』到中央仓库中。这相当于`svn commit`操作，但`push`操作会把所有还不在中央仓库的本地提交都推上去。
+然后，开发者发布修改到正式项目中，开发者要把本地`master`分支的修改『推』到中央仓库中。这相当于`svn commit`操作，但`push`操作会把所有还不在中央仓库的本地提交都推上去。
@@ -384,7 +386,7 @@ git push origin master
但不是直接提交本地历史到各自的本地`master`分支，开发者每次在开始新功能前先创建一个新分支。
功能分支应该有个有描述性的名字，比如`animated-menu-items`或`issue-#1061`，这样可以让分支有个清楚且高聚焦的用途。
-在`master`分支和功能分支之间，`Git`是没有技术上的区别，所以开发者可以用和集中式工作流中完全一样的方式编辑、暂存和提交修改到功能分支上。
+对于`master`分支和功能分支，`Git`是没有技术上的区别，所以开发者可以用和集中式工作流中完全一样的方式编辑、暂存和提交修改到功能分支上。
另外，功能分支也可以（且应该）`push`到中央仓库中。这样不修改正式代码就可以和其它开发者分享提交的功能。
由于`master`是仅有的一个『特殊』分支，在中央仓库上存多个功能分支不会有任何问题。当然，这样做也可以很方便地备份各自的本地提交。
@@ -392,10 +394,10 @@ git push origin master
### 2.2.2 `Pull Requests`
功能分支除了可以隔离功能的开发，也使得通过[`Pull Requests`](pull-request.md)讨论变更成为可能。
-一旦某个开发完成一个功能，不是立即合并到`master`，而是`push`到中央仓库的功能分支上并发起一个`Pull Request`请求去合并修改到`master`。
+一旦某个开发者完成一个功能，不是立即合并到`master`，而是`push`到中央仓库的功能分支上并发起一个`Pull Request`请求，将修改合并到`master`。
在修改成为主干代码前，这让其它的开发者有机会先去`Review`变更。
-`Code Review`是`Pull Requests`的一个重要的收益，但`Pull Requests`目的是讨论代码一个通用方式。
+`Code Review`是`Pull Requests`的一个重要的收益，而`Pull Requests`则是讨论代码的一个通用方式。
你可以把`Pull Requests`作为专门给某个分支的讨论。这意味着可以在更早的开发过程中就可以进行`Code Review`。
比如，一个开发者开发功能需要帮助时，要做的就是发起一个`Pull Request`，相关的人就会自动收到通知，在相关的提交旁边能看到需要帮助解决的问题。
@@ -517,8 +519,8 @@ git push
`Gitflow`工作流定义了一个围绕项目发布的严格分支模型。虽然比[功能分支工作流](workflow-feature-branch.md)复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。
-`Gitflow`工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。
-除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。
+`Gitflow`工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个明确的角色，并定义分支之间如何和什么时候进行交互。
+除了使用功能分支，在做准备、维护和记录发布时，也定义了各自的分支。
当然你可以用上功能分支工作流所有的好处：`Pull Requests`、隔离实验性开发和更高效的协作。
### 2.3.1 工作方式
@@ -526,7 +528,7 @@ git push
### 2.3.2 历史分支
-相对使用仅有的一个`master`分支，`Gitflow`工作流使用2个分支来记录项目的历史。`master`分支存储了正式发布的历史，而`develop`分支作为功能的集成分支。
+相对于使用仅有的一个`master`分支，`Gitflow`工作流使用两个分支来记录项目的历史。`master`分支存储了正式发布的历史，而`develop`分支作为功能的集成分支。
这样也方便`master`分支上的所有提交分配一个版本号。
@@ -547,7 +549,7 @@ git push
-一旦`develop`分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从`develop`分支上`fork`一个发布分支。
+一旦`develop`分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从`develop`分支上`checkout`一个发布分支。
新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上——
这个分支只应该做`Bug`修复、文档生成和其它面向发布任务。
一旦对外发布的工作都完成了，发布分支合并到`master`分支并分配一个版本号打好`Tag`。
@@ -568,7 +570,7 @@ git push
-维护分支或说是热修复（`hotfix`）分支用于生成快速给产品发布版本（`production releases`）打补丁，这是唯一可以直接从`master`分支`fork`出来的分支。
+维护分支或说是热修复（`hotfix`）分支用于给产品发布版本（`production releases`）快速生成补丁，这是唯一可以直接从`master`分支`fork`出来的分支。
修复完成，修改应该马上合并回`master`分支和`develop`分支（当前的发布分支），`master`分支应该用新的版本号打好`Tag`。
为`Bug`修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
@@ -672,13 +674,13 @@ git push --tags
```
`Git`有提供各种勾子（`hook`），即仓库有事件发生时触发执行的脚本。
-可以配置一个勾子，在你`push`中央仓库的`master`分支时，自动构建好对外发布。
+可以配置一个勾子，在你`push`中央仓库的`master`分支时，自动构建好版本，并对外发布。
#### 最终用户发现`Bug`
-对外发布后，小红回去和小明一起做下个发布的新功能开发，直到有最终用户开了一个`Ticket`抱怨当前版本的一个`Bug`。
+对外版本发布后，小红小明一起开发下一版本的新功能，直到有最终用户开了一个`Ticket`抱怨当前版本的一个`Bug`。
为了处理`Bug`，小红（或小明）从`master`分支上拉出了一个维护分支，提交修改以解决问题，然后直接合并回`master`分支：
```bash
@@ -1135,3 +1137,29 @@ git push origin some-branch
5. 若此次上线后，不久发现生产环境有 Bug 需要修复，则从 Tag 处新开分支 release_bugfix_20150731、dev_bugfix_20150731 ，开发人员从 dev_bugfix_20150731分支上进行开发，提测code review在 release_bugfix_20150731 分支上，具体步骤参考2-3，测试环境验证通过后，发布到线上，验证OK，合并到 Master 分支，并打 Tag0.2.3，此次 Bug 修复完毕，专为解 Bug 而生的这两个分支可以退伍了，删除release_bugfix_20150731、dev_bugfix_20150731两分支即可。（所有的历史 Commit 信息均已经提交到了 Master 分支上，不用担心丢失）
这样经过上面的1-5步骤，企业日常迭代开发中的代码版本控制基本上就 Ok 了，有问题欢迎 Issue 讨论。
+
+2016-11月 更新 **Git 分支开发部署模型** 的一些使用原则如下:
+
+
+
+- master：master永远是线上代码，最稳定的分支，存放的是随时可供在生产环境中部署的代码，当开发活动告一段落，产生了一份新的可供部署的代码时，发布成功之后，代码才会由 aone2 提交到 master，master 分支上的代码会被更新。应用上 aone2 后禁掉所有人的 master的写权限
+- develop：保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码，只对开发负责人开放develop权限。
+- feature: 功能特性分支，每个功能特性一个 feature/ 分支，开发完成自测通过后合并入 develop 分支。可以从 master 或者develop 中拉出来。
+- hotfix: 紧急bug分支修复分支。修复上线后，可以直接合并入master。
+
+
+
+Git-Develop 分支模式是基于 Git 代码库设计的一种需要严格控制发布质量和发布节奏的开发模式。develop 作为固定的持续集成和发布分支，并且分支上的代码必须经过 CodeReview 后才可以提交到 Develop 分支。它的基本流程如下：
+- 每一个需求/变更都单独从Master上创建一条Branch分支；
+- 用户在这个Branch分支上进行Codeing活动；
+- 代码达到发布准入条件后aone上提交Codereview，Codereview通过后代码自动合并到Develop分支；
+- 待所有计划发布的变更分支代码都合并到Develop后，系统再 rebase master 代码到Develop 分支，然后自行构建，打包，部署等动作。
+- 应用发布成功后Aone会基于Develop分支的发布版本打一个“当前线上版本Tag”基线；
+- 应用发布成功后Aone会自动把Develop分支的发布版本合并回master；
+
+# 四、开发工作流的讨论
+几篇业界的讨论文章
+- [Gitflow 有害论](http://insights.thoughtworkers.org/gitflow-consider-harmful/) 作者对 Gitflow 流程的使用过程中的吐槽，文章留言引起了强烈的讨论，可以关注下。
+- [GitHub Flow](http://scottchacon.com/2011/08/31/github-flow.html) scottchacon 讲述在 GitHub 工作中日常流程以及对每一点进行详细的介绍。
+- [谷歌的代码管理](http://www.ruanyifeng.com/blog/2016/07/google-monolithic-source-repository.html) 谷歌和 Facebook 都只有一个代码仓库，全公司的代码都放在这个库里，这里是阮一峰老师写的文章。
+- [Why Google Stores Billions of Lines of Code in a Single Repository](http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext)
diff --git a/how-to-use-github.md b/how-to-use-github.md
index d30ac07..c659667 100644
--- a/how-to-use-github.md
+++ b/how-to-use-github.md
@@ -1,29 +1,29 @@
说明
==============
-作为一名开发者，Github上面有很多东西值得关注学习，可是刚刚接触github，怎样一步步学习使用Github？怎样更高效的利用Github？
-在这里搜集整理网络上面的资料，汇总成这么一篇repo 《Github使用指南》，供大家一起学习。 :octocat:
+作为一名开发者，GitHub上面有很多东西值得关注学习，可是刚刚接触GitHub，怎样一步步学习使用GitHub？怎样更高效的利用GitHub？
+在这里搜集整理网络上面的资料，汇总成这么一篇repo 《GitHub使用指南》，供大家一起学习。 :octocat:
-- [github 入门使用教程-图文并茂](http://developer.51cto.com/art/201407/446249_all.htm) 很简洁的说明如何使用，看图即可明白。
-- [github help](https://help.github.com/) Sometimes you just need a little help. 中文翻译版在此[Github 帮助文档](https://github.com/waylau/github-help)。
-- [github 之 fork 简介指南](https://linux.cn/article-4292-1.html) 帮你理解清楚什么是fork，fork 的工作流有哪些。
-- [github-cheat-sheet](https://github.com/tiimgreen/github-cheat-sheet) 关于使用 git 和 github 的一些技巧汇总，中文版在此[GitHub秘籍](https://github.com/tiimgreen/github-cheat-sheet/blob/master/README.zh-cn.md)
-- [The GitHub Blog](https://github.com/blog) github 官方博客，关注最新动态。
-- [How to Build a GitHub](http://zachholman.com/talk/how-to-build-a-github/) Github一名早期员工介绍Github的历史，5年108名员工无人离职。
-- [阳志平：如何高效利用GitHub](http://www.yangzhiping.com/tech/github.html) 介绍的挺全，以及一些用法，如怎样利用Github来学习、演讲找工作等。
-- [github 支持的 emoji表情 emoji-cheat-sheet](http://www.emoji-cheat-sheet.com/) :v: :clap: 感觉不好找到需要的表情？试试[Emoji Searcher](http://emoji.muan.co/)
-- [github guides](https://guides.github.com/) 从`Contributing to Open Source on GitHub`、`Hello World`、`Forking Projects`、`Be Social`、`Making Your Code Citable`、`Mastering Issues`、`Mastering Markdown`、`Mastering Wikis`、`Getting Started with GitHub Pages` 等9个方面图文详细讲解每一步如何使用，以及能做哪些功能。
-- [fork-me-on-github](https://github.com/blog/273-github-ribbons) 个人博客、技术博客等如果需要添加github 的彩带，可以使用此方法。
-- [蒋鑫-GotGitHub](GotGitHub.md) 《Git权威指南》的作者，对Github有很深的了解。（由于首页打开太慢，放到了本文目录中，下面的文章既是）
+- [GitHub 入门使用教程-图文并茂](http://developer.51cto.com/art/201407/446249_all.htm) 很简洁的说明如何使用，看图即可明白。
+- [GitHub help](https://help.github.com/) Sometimes you just need a little help. 中文翻译版在此[GitHub 帮助文档](https://github.com/waylau/github-help)。
+- [GitHub 之 fork 简介指南](https://linux.cn/article-4292-1.html) 帮你理解清楚什么是fork，fork 的工作流有哪些。
+- [GitHub-cheat-sheet](https://github.com/tiimgreen/github-cheat-sheet) 关于使用 git 和 GitHub 的一些技巧汇总，中文版在此[GitHub秘籍](https://github.com/tiimgreen/github-cheat-sheet/blob/master/README.zh-cn.md)
+- [The GitHub Blog](https://github.com/blog) GitHub 官方博客，关注最新动态。
+- [How to Build a GitHub](http://zachholman.com/talk/how-to-build-a-github/) GitHub一名早期员工介绍GitHub的历史，5年108名员工无人离职。
+- [阳志平：如何高效利用GitHub](http://www.yangzhiping.com/tech/github.html) 介绍的挺全，以及一些用法，如怎样利用GitHub来学习、演讲找工作等。
+- [GitHub 支持的 emoji表情 emoji-cheat-sheet](http://www.emoji-cheat-sheet.com/) :v: :clap: 感觉不好找到需要的表情？试试[Emoji Searcher](http://emoji.muan.co/)
+- [x] [GitHub guides](https://guides.github.com/) 从`Contributing to Open Source on GitHub`、`Hello World`、`Forking Projects`、`Be Social`、`Making Your Code Citable`、`Mastering Issues`、`Mastering Markdown`、`Mastering Wikis`、`Getting Started with GitHub Pages` 等9个方面图文详细讲解每一步如何使用，以及能做哪些功能。
+- [fork-me-on-GitHub](https://github.com/blog/273-github-ribbons) 个人博客、技术博客等如果需要添加GitHub 的彩带，可以使用此方法。
+- [蒋鑫-GotGitHub](GotGitHub.md) 《Git权威指南》的作者，对GitHub有很深的了解。（由于首页打开太慢，放到了本文目录中，下面的文章既是）
-# Github Skills
+# GitHub Skills
- [Using Git blame to trace changes in a file](https://help.github.com/articles/using-git-blame-to-trace-changes-in-a-file/) 如果你想看某一个文件中每一行是谁修改的，为什么修改？那么尽情的使用 `blame` 按钮，发现文件的历史。
-- [Github 搜索技巧](https://help.github.com/categories/search/)
+- [GitHub 搜索技巧](https://help.github.com/categories/search/)
- [Closing issues via commit messages - 通过提交信息关闭Issues](https://help.github.com/articles/closing-issues-via-commit-messages/)
- [Update your forked code from original repository - 如何更新自己 Fork 的代码](https://github.com/ysc/APDPlat/wiki/%E5%A6%82%E4%BD%95%E6%9B%B4%E6%96%B0%E8%87%AA%E5%B7%B1Fork%E7%9A%84%E4%BB%A3%E7%A0%81)
-更多关于 Github 的内容请查看：[GithubHelp](https://help.github.com/) 查找需要的信息。
+更多关于 GitHub 的内容请查看：[GitHubHelp](https://help.github.com/) 查找需要的信息。
--------
@@ -180,7 +180,7 @@
6.3. 客户端工具
diff --git a/ixirong.com.md b/ixirong.com.md
index daefe03..1ed709b 100644
--- a/ixirong.com.md
+++ b/ixirong.com.md
@@ -4,7 +4,7 @@
> Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
-[git维基百科](http://zh.wikipedia.org/wiki/Git)上详细介绍了git的资料，包括git的创建、使用以及一些草考资料，已经挺全了，记住一点，最高效的学习方式就是**读文档**，找官方文档去阅读学习是最快的掌握git的方法。
+[git维基百科](http://zh.wikipedia.org/wiki/Git)上详细介绍了git的资料，包括git的创建、使用以及一些参考资料，已经挺全了，记住一点，最高效的学习方式就是**读文档**，找官方文档去阅读学习是最快的掌握git的方法。
既然是分布式版本管理，那么和我们平常使用的svn有什么区别？
1. 分布式 vs 集中管理 （多份版本库 vs 一份版本库，设想下版本服务器挂了？）
diff --git a/readme.md b/readme.md
index c62bce0..c5cb3c1 100644
--- a/readme.md
+++ b/readme.md
@@ -9,12 +9,12 @@
- [为什么开始使用 Git 版本管理，Git VS Svn 有哪些区别？](https://github.com/xirong/my-git/blob/master/why-git.md)
- [开篇：一篇适合入门学习git的资料汇总](https://github.com/xirong/my-git/blob/master/ixirong.com.md) 本人的拙笔，欢迎吐槽！
- [Github-cheat-sheet](https://github.com/tiimgreen/github-cheat-sheet) 关于使用 Git 和 Github 的一些技巧汇总，中文版在此[GitHub秘籍](https://github.com/tiimgreen/github-cheat-sheet/blob/master/README.zh-cn.md)
-- [Git for beginners: The definitive practical guide - from stackoverflow.com](http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide?rq=1) It's so useful to a beginner ,just open the url , read and practice .
+- [Git for beginners: The definitive practical guide - from stackoverflow.com](http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide?rq=1) It's so useful to a beginner ,just open the url , read and practice .
- [Visual Git Cheat Sheet](http://ndpsoftware.com/git-cheatsheet.html) 通过 Git 的几个工作区 Stash、Workspace、Index、Local Repository、Upstream Repository 来汇总日常使用的 Git 命令，备忘推荐。
# Git 客户端
-Mac 和 Linux 系统推荐使用终端即可，Git 一开始的命令的确很多，别无它法，熟能生巧，多练习即可能够掌握日常使用的一些名利，再配合[`常用命令的alias`](https://git-scm.com/book/tr/v2/Git-Basics-Git-Aliases)或者强大的 [`zsh 终端`](http://www.ixirong.com/2015/04/27/strong-bash-use-oh-my-zsh/)都能显著的提升效率，当然如果非得寻找图形化客户端，也不是没有；Windows下还是尽快熟悉客户端的使用吧，因为win下面的bash太难用了：
+Mac 和 Linux 系统推荐使用终端即可，Git 一开始的命令的确很多，别无它法，熟能生巧，多练习即可能够掌握日常使用的一些命令，再配合[`常用命令的alias`](https://git-scm.com/book/tr/v2/Git-Basics-Git-Aliases)或者强大的 [`zsh 终端`](http://www.ixirong.com/2015/04/27/strong-bash-use-oh-my-zsh/)都能显著的提升效率，当然如果非得寻找图形化客户端，也不是没有；Windows下还是尽快熟悉客户端的使用吧，因为win下面的bash太难用了：
- [GUI Clients](https://git-scm.com/downloads/guis) 官方推荐图形客户端，罗列的包括了Mac、Windows、Linux下的客户端，免费及付费的都有，你可以在这里面挑选一个就ok。
- [Git for windows](https://msysgit.github.io/) 针对 Window 系统发布的客户端，集成了 Shell 窗口，方便在 Win 下面使用命令操作。
@@ -22,17 +22,18 @@ Mac 和 Linux 系统推荐使用终端即可，Git 一开始的命令的确很
- [Tower2](http://www.git-tower.com/) 号称最好的 Git 客户端，只有 Mac 版本，收费，集成 Github、Gitlab、Xcode等服务。
- [SourceTree](https://www.sourcetreeapp.com/) 免费，功能齐全，Mac+Window 版本，集成 Github 等服务。
- [SmartGit](http://www.syntevo.com/smartgit/) 非商业用途免费，全平台支持，集成 Github服务。内置 SSH client ，文件比较与合并工具。
+- [Fork](https://git-fork.com) 免费，Mac+Window 版本，功能齐全，轻便流畅。
-# Git branch
+# Git branch
- [A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/) 介绍日常推荐的分支开发模型，基于此模型可以通过这个小游戏来进行学习 [Learn Git Branch](http://pcottle.github.io/learnGitBranching/)
-- [Git工作流指南](https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md)完整的对比目前使用的集中式（Svn）工作流、功能分支工作流、Gitflow 工作流、Forking 工作流、Pull Request 等几种不同的模式，通俗易懂，强烈推荐看一看，如果觉的排版不好，请查看原分页文章 [Git-workflow-translations](https://github.com/oldratlee/translations/tree/master/git-workflows-and-tutorials)
+- [Git工作流指南](https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md)完整的对比目前使用的集中式（Svn）工作流、功能分支工作流、Gitflow 工作流、Forking 工作流、Pull Request 等几种不同的模式，通俗易懂，强烈推荐看一看，如果觉的排版不好，请查看原分页文章 [Git-workflow-translations](https://github.com/oldratlee/translations/tree/master/git-workflows-and-tutorials)
- 熟悉的工作流后，你是否也想要在 Github 上与他人一起协同工作？那么问题来了，[Github全程指南-如何高效使用？](how-to-use-github.md)
- [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/index.html) This guide explains how and why GitHub Flow works 简单实用，更好的理解Github的模式。
- [Github 协同开发流程](http://www.ruanyifeng.com/blog/2015/08/git-use-process.html) 图片很赞，简洁易懂。
-# Git expert
+# Git expert
- 项目依赖其他项目，比如公共 Css、Dll 等等，强大的 Git-submodule 优雅的解决这类问题。理解阅读 [Git Tools - Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) ，备忘或者查看命令阅读 [Git Submodule Tutorial](https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial) 或者 [Git Submodule 使用完整教程](http://www.kafeitu.me/git/2012/03/27/git-submodule.html)
-
+- [Git Submodule 的一些注意事项](http://blog.devtang.com/blog/2013/05/08/git-submodule-issues/) 一些需要理解并注意的操作
# Git 书籍
- [Pro Git](http://git-scm.com/book/zh/v1) 作者Scott Chacon是 Github 的员工，Git 的布道者，这本书被誉为 Git 学习圣经，中间有好多插图描述的浅显易懂，挺适合详细学习下的，最新英文第二版《[Pro Git (Editon 2)](http://git-scm.com/book/en/v2)》；
@@ -45,20 +46,24 @@ Mac 和 Linux 系统推荐使用终端即可，Git 一开始的命令的确很
# Git 效率提升
- [Git flow 工具](https://github.com/petervanderdoes/gitflow)
- [Git flow 中文备忘清单](http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html)
-- 一个很有意思的学习 Git 的小游戏 http://pcottle.github.io/learnGitBranching/
+- 一个很有意思的学习 Git 的小游戏 http://pcottle.github.io/learnGitBranching/
- [Git completion](https://github.com/git/git/tree/master/contrib/completion) 终端 Git 命令的 Tab 键补全功能，比如打开终端，输入`git che`，按 Tab 键，则会出现`check-attr\check-ignore\checkout`等等的选项，支持 Bash、Zsh 等 Shell，使用方法(以 Bash Shell 为例)：下载链接中相应的版本到用户目录下，修改`~/.bashrc`文件 ，加入`source ~/git-completion.bash` ，使得每次打开终端时都执行一次`git-completion.bash`脚本，来完成git 命令的 Tab 补全。或者采用这种方法[Quick Tip: Autocomplete Git Commands and Branch Names in Bash](http://code-worrier.com/blog/autocomplete-git/)
-- [.gitignore template](https://github.com/github/gitignore) 各种语言、各种编辑器的`.gitignore`文件模板，当你进行某些语言的开发时候，直接使用相应的模板即可，省去自己写的时间（还不全），当然你也可以去贡献自己的模板，不知道`.gitignore`？ 简单讲就是不让git跟踪某些文件，详情阅读：http://git-scm.com/docs/gitignore
- **PS：** 推荐使用 `.gitignore_global` 文件进行全局过滤，比如mac下的 `.DS_Store` 文件，省去在每个 Repo 下进行设置 `.gitignore`文件了。全局模板参考：https://github.com/github/gitignore/tree/master/Global
+- [.gitignore template](https://github.com/github/gitignore) 各种语言、各种编辑器的`.gitignore`文件模板，当你进行某些语言的开发时候，直接使用相应的模板即可，省去自己写的时间（还不全），当然你也可以去贡献自己的模板，不知道`.gitignore`？ 简单讲就是不让git跟踪某些文件，详情阅读：http://git-scm.com/docs/gitignore
+ **PS：** 推荐使用 `.gitignore_global` 文件进行全局过滤，比如mac下的 `.DS_Store` 文件，省去在每个 Repo 下进行设置 `.gitignore`文件了。全局模板参考：https://github.com/github/gitignore/tree/master/Global
# Git extensions
- Git 的大文件支持[Git LFS](https://github.com/github/git-lfs) ： Git在对大文件进行版本管理的时候，速度上是很慢的，一个帮助处理大文件的扩展插件，在 GithubHelp [Working with large files](https://help.github.com/articles/working-with-large-files/) 中提到，不建议对大文件如日志、database等使用Git进行版本控制，如果非要有这种需求，则建议使用 Git LFS 。
# 实践备忘
-- 常用命令手册 [Git-cheat-sheet](command-handbook/) 、[Git 日常开发常用命令](useful-git-command.md)
+- 常用命令手册 [Git 日常开发常用命令整理](useful-git-command.md)，日常开发中的利器，可以当做备忘录来使用，推荐👍。
- 总是使用 `git merge --no-ff` 而不是 `git merge` ，记录下分支的变更历史。 详情 http://stackoverflow.com/questions/9069061/what-is-the-difference-between-git-merge-and-git-merge-no-ff
-- 恰当的使用 `git pull --rebase` 避免不必要的merge记录。 详情 http://stackoverflow.com/questions/2472254/when-should-i-use-git-pull-rebase
+- 恰当的使用 `git pull --rebase` 避免不必要的merge记录。 详情 http://stackoverflow.com/questions/2472254/when-should-i-use-git-pull-rebase 「You should use `git pull --rebase` when your changes do not deserve a separate branch」
+
- [Git-flight-rules](https://github.com/k88hudson/git-flight-rules) 一些日常使用中的场景，比如提交错了分支、提交时的用户名邮箱不对、丢弃某些提交、未提交的代码直接提交到另外一个分支等等，很实用。
-- [How to undo (almost) anything with Git](https://github.com/blog/2019-how-to-undo-almost-anything-with-git) 撤销一切，汇总各种回滚撤销的场景，加强学习。
+- [How to undo (almost) anything with Git](https://github.com/blog/2019-how-to-undo-almost-anything-with-git) 撤销一切，汇总各种回滚撤销的场景，加强学习。
- [怎样在一台电脑上同时使用公司 GitLab 和 Github 的服务？](use-gitlab-github-together.md) 由于公司团队使用 GitLab 来托管代码，同时，个人在 Github 上还有一些代码仓库，可公司邮箱与个人邮箱是不同的，由此产生的 SSH key 也是不同的，这就造成了冲突 ，文章提供此类问题的解决方案。
- [如何书写提交信息](http://chris.beams.io/posts/git-commit/) 当项目越来越大，提交信息越来越复杂的时候，如何书写好提交信息就变得至关重要，这篇文章的作者总结出7条准则。
+- [Commit message 和 change log编写规范-阮一峰](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html) 良好的 commit log 好处大大的多。 [AngularJS Git Commit Message Conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#heading=h.uyo6cb12dt6w)
+- [git-recipes](https://github.com/geeeeeeeeek/git-recipes/wiki) @童仲毅 整理翻译的一些优秀文章。
+- [githug](https://github.com/Gazler/githug) Git your game on. 使用通关游戏的形式来练习git的一些命令，非常有趣。
diff --git a/use-gitlab-github-together.md b/use-gitlab-github-together.md
index 67ba385..953f112 100644
--- a/use-gitlab-github-together.md
+++ b/use-gitlab-github-together.md
@@ -54,7 +54,7 @@
git config --global user.name 'xirong' && git config --global user.email 'ixirong.liu@gmail.com'
# 团队项目配置，每次新创建一个项目，需要执行下
-git config --local user.name 'xirong.liu' && git config --local user.email 'xirong.liu@corp.xxx.com'
+git config --local user.name 'xirong.liu' && git config --local user.email 'xirong.liu@corp.example.com'
```
### 2. 生成 ssh key 上传到 Github/Gitlab
@@ -63,7 +63,7 @@ ssh key 默认生成后保存在 `~/.ssh/`目录下 ，默认为 `id_rsa 和 id_
``` bash
# 生成公钥、密钥的同时指定文件名，Gitlab使用
-ssh-keygen -t rsa -f ~/.ssh/id_rsa.gitlab -C "xirong.liu@corp.xxx.com"
+ssh-keygen -t rsa -f ~/.ssh/id_rsa.gitlab -C "xirong.liu@corp.example.com"
# 生成默认，Github使用
ssh-keygen -t rsa -C "ixirong.liu@gmail.com"
@@ -75,12 +75,18 @@ ssh-keygen -t rsa -C "ixirong.liu@gmail.com"
在 `~/.ssh`目录下，如果不存在，则新建 `touch ~/.ssh/config`文件 ，文件内容添加如下：
``` bash
-Host *.corp.xxx.com
+Host corp.example.com
+ HostName git.corp.example.com
IdentityFile ~/.ssh/id_rsa.gitlab
User xirong.liu
```
-配置完成后，符合 `*.corp.xxx.com`后缀的 Git 仓库，均采取` ~/.ssh/id_rsa.gitlab` 密钥进行验证，其它的采取默认的。
+- `Host`参数是命令行给出的主机名，比如`ssh -T git@corp.example.com`，那么此时的主机(`Host`)就是`corp.example.com`
+- 只有`Host`匹配之后，`SSH`把`git@corp.example.com`转换成`git.corp.example.com`
+- `Host`不支持`*`和主机名混用，即`*.example.com`；单独`*`表示匹配所有主机，也就是默认规则
+- `HostName`应该是必须填写的内容，根据你使用的命令行内容来填写
+
+配置完成后，符合`git.corp.example.com`的 Git 仓库，均采取` ~/.ssh/id_rsa.gitlab` 密钥进行验证，其它的采取默认的。
### 4. 上传public key 到 Github/Gitlab
@@ -120,4 +126,4 @@ total 40
-rw------- 1 xirong staff 1679 Jun 22 11:42 id_rsa_gitcafe
-rw-r--r-- 1 xirong staff 407 Jun 22 11:42 id_rsa_gitcafe.pub
-rw-r--r-- 1 xirong staff 9139 Jul 29 15:08 known_hosts
-```
\ No newline at end of file
+```
diff --git a/useful-git-command.md b/useful-git-command.md
index 7e5f143..ebbadcc 100644
--- a/useful-git-command.md
+++ b/useful-git-command.md
@@ -1,6 +1,42 @@
说明
-=======
-Git 常用、不常用、实用的命令，这些命令都是在日常使用过程中遇到过整理下来的，留作备忘，如果对这些命令还不明白什么意思，请参考学习：[Git 新手入门](readme.md#新手入门) 。
+
+Git 常用、不常用、实用的命令，这些命令都是在日常使用过程中遇到过整理下来的，留作备忘，如果对这些命令还不明白什么意思，请参考学习：[Git 新手入门](https://github.com/xirong/my-git#新手入门) 。
+
+在日常开发中，由于采用 Git 作为版本控制，经常跟命令行打交道，记录整理下使用到的一些命令，方便回顾。
+
+[TOC]
+# Concept
+```
+master : default development branch
+origin : default upstream repository
+HEAD : current branch and commit
+HEAD^ : parent of HEAD
+HEAD~4 : the great-great grandparent of HEAD
+```
+# Alias
+下面的只是例子，想改成什么跟随自己的意愿即可。
+``` bash
+git config --global alias.st status //status 缩写成 st
+git config --global alias.co checkout //checkout 缩写成 co
+git config --global alias.br branch //branch 缩写成 br
+git config --global alias.ci commit //commit 缩写成 ci
+git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
+```
+如果不想使用了，删除掉的话，直接删除 conf 配置文件中的行即可，global 的在当前用户下`vim ~/.gitconfig` 删除` alias`下你配置的内容接口；若是当前仓库则在 `.git/config` 中。
+# Git Config
+Git 配置文件分为三级，系统级(--system)、用户级(--global)和目录级(--local)，三者的使用优先级以离目录 (repository)最近为原则，如果三者的配置不一样，则生效优先级 **目录级>用户级>系统级**，可以通过 `git config --help` 查看更多内容。
++ 系统级配置存储在 `/etc/gitconfig` 文件中，可以使用 `git config --system user.name "jim"` ,`git config --sytem user.email "jim.jim@gmail.com"` 来进行配置，该配置对系统上所有用户及他们所拥有的仓库都生效的配置值。
++ 用户级存储在每个用户的 `~/.gitconfig` 中，可以使用 `git config --global user.name "jim"` ,`git config --global user.email "jim.jim@gmail.com"` 来进行配置，该配置对当前用户上所有的仓库有效。
++ 目录级存储在每个仓库下的 `.git/config` 中，可以使用 `git config --local user.name "jim"` , `git config --local user.email "jim.jim@gmail.com"` 来进行配置，只对当前仓库生效。
+
+# Basic Usage
+- 添加文件到暂存区（staged）：`git add filename` / `git stage filename`
+- 将所有修改文件添加到暂存区（staged）： `git add --all` / `git add -A`
+- 提交修改到暂存区（staged）：`git commit -m 'commit message'` / `git commit -a -m 'commit message'` 注意理解 -a 参数的意义
+- 从Git仓库中删除文件：`git rm filename`
+- 从Git仓库中删除文件，但本地文件保留：`git rm --cached filename`
+- 重命名某个文件：`git mv filename newfilename` 或者直接修改完毕文件名 ，进行`git add -A && git commit -m 'commit message'` Git会自动识别是重命名了文件
+- 获取远程最新代码到本地：`git pull (origin branchname)` 可以指定分支名，也可以忽略。pull 命令自动 fetch 远程代码并且 merge，如果有冲突，会显示在状态栏，需要手动处理。更推荐使用：`git fetch` 之后 `git merge --no-ff origin branchname` 拉取最新的代码到本地仓库，并手动 merge 。
# Repository
- 检出（clone）仓库代码：`git clone repository-url` / `git clone repository-url local-directoryname`
@@ -11,18 +47,26 @@ Git 常用、不常用、实用的命令，这些命令都是在日常使用过
- 删除远程仓库：`git remote rm [name]`
- 修改远程仓库地址：`git remote set-url origin new-repository-url`
- 拉取远程仓库： `git pull [remoteName] [localBranchName]`
-- 推送远程仓库： `git push [remoteName] [localBranchName]`
+- 推送远程仓库： `git push [remoteName] [localBranchName]` 例: `git push -u orgin master ` 将当前分支推送到远端master分支
+- 将本地 test 分支提交到远程 master 分支: `git push origin test:master` (把本地的某个分支 test 提交到远程仓库，并作为远程仓库的 master 分支) 提交本地 test 分支作为远程的 test 分支 :`git push origin test:test `
-# Add/Commit/Rm/Pull/Merge
-- 添加文件到暂存区（staged）：`git add filename` / `git stage filename`
-- 将所有修改文件添加到暂存区（staged）： `git add --all` / `git add -A`
-- 提交修改到暂存区（staged）：`git commit -m 'commit message'` / `git commit -a -m 'commit message'` 注意理解 -a 参数的意义
-- 从Git仓库中删除文件：`git rm filename`
-- 从Git仓库中删除文件，但本地文件保留：`git rm --cached filename`
-- 重命名某个文件：`git mv filename newfilename` 或者直接修改完毕文件名 ，进行`git add -A && git commit -m 'commit message'` Git会自动识别是重命名了文件
-- 获取远程最新代码到本地：`git pull (origin branchname)` 可以指定分支名，也可以忽略。pull 命令自动 fetch 远程代码并且 merge，如果有冲突，会显示在状态栏，需要手动处理。更推荐使用：`git fetch` 之后 `git merge --no-ff origin branchname` 拉取最新的代码到本地仓库，并手动 merge 。
+# Checkout
+checkout命令用于从历史提交（或者暂存区域）中拷贝文件到工作目录，也可用于切换分支。
+ 
+**匿名分支**：如果既没有指定文件名，也没有指定分支名，而是一个标签、远程分支、SHA-1值或者是像 master~3 类似的东西，就得到一个匿名分支，称作 detached HEAD（被分离的 HEAD 标识）。
+
+
+
+当HEAD处于分离状态（不依附于任一分支）时，提交操作可以正常进行，但是不会更新任何已命名的分支。(你可以认为这是在更新一个匿名分支。)一旦此后你切换到别的分支，比如说 master，那么这个提交节点（可能）再也不会被引用到，然后就会被丢弃掉了。注意这个命令之后就不会有东西引用 2eecb。详细查看：[visual-git-guide#detached](http://marklodato.github.io/visual-git-guide/index-zh-cn.html#detached)
+但是，如果你想保存这个状态，可以用命令 `git checkout -b name` 来创建一个新的分支。
+
# Log
+> Description : Shows the commit logs.
+The command takes options applicable to the git rev-list command to control what is shown and how, and options applicable to the git diff-* commands to control how the changes each commit introduces are shown.
+> git log [options] [revision range] [path]
+
+常用命令整理如下:
- 查看日志：`git log`
- 查看日志，并查看每次的修改内容：`git log -p`
- 查看日志，并查看每次文件的简单修改状态：`git log --stat`
@@ -36,51 +80,199 @@ Git 常用、不常用、实用的命令，这些命令都是在日常使用过
+ 试试这个 ： `git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit` 感觉好用就加成 alias ，方便日后用，方法：`git config --global alias.aliasname 'alias-content'`
+ 更多用法：[Viewing the History -- 《Pro Git2》](http://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History)
+`log` 的目的就是为了查看改动点来排查问题，除了 ` git log` 还可以使用 `git show` 、`git blame` 来查看文件的改动。
+- Who changed what and when in a file : `git blame $file`
+- 查看一次 commit 中修改了哪些文件: `git show --pretty="" --name-only ` 或者 `git diff-tree --no-commit-id --name-only -r `
+
+
# Undo things
-- 上次提交msg错误/有未提交的文件应该同上一次一起提交，需要重新提交备注：`git commit --amend -m 'new msg'`
+- 上次提交 msg 错误/有未提交的文件应该同上一次一起提交，需要重新提交备注：`git commit --amend -m 'new msg'`
+- 修改上次提交的 author、email :`git commit --amend --author="newName "`
+- 修改整个历史记录中的某些错误的 author、email: `git rebase 或者 git filter-branch`
+ ``` bash
+ # git rebase 模式
+ git rebase -i -p 76892625a7b126f4772f8d7e331ada3552c11ce1
+ # 弹出编辑器，在需要修改的 commit 处 由 picked 改变为 edit ，然后 wq 退出 vim；
+ git commit --amend --author 'newName '
+ # 执行后即变更了相应的 author 和 email
+ git rebase --continue
+ ################################################################
+ # git filter-branch 模式 https://help.github.com/articles/changing-author-info/
+git filter-branch --env-filter '
+OLD_EMAIL="your-old-email@example.com"
+CORRECT_NAME="Your Correct Name"
+CORRECT_EMAIL="your-correct-email@example.com"
+if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
+then
+ export GIT_COMMITTER_NAME="$CORRECT_NAME"
+ export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
+fi
+if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
+then
+ export GIT_AUTHOR_NAME="$CORRECT_NAME"
+ export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
+fi
+' --tag-name-filter cat -- --branches --tags
+ ```
+
+
- 一次`git add -A`后，需要将某个文件撤回到工作区，即：某个文件不应该在本次commit中：`git reset HEAD filename`
- 撤销某些文件的修改内容：`git checkout -- filename` 注意：一旦执行，所有的改动都没有了，谨慎！谨慎！谨慎！
- 将工作区内容回退到远端的某个版本：`git reset --hard `
- + `--hard`：reset stage and working directory , 以来所有的变更全部丢弃，并将 HEAD 指向
- + `--soft`：nothing changed to stage and working directory ,仅仅将HEAD指向 ，所有变更显示在”changed to be committed”中
- + `--mixed`：default,reset stage ,nothing to working directory ，这也就是第二个例子的原因
-# Diff
+# Reset
+reset命令把当前分支指向另一个位置，并且有选择的变动工作目录和索引，也用来在从历史仓库中复制文件到索引，而不动工作目录。
+
+
+将工作区内容回退到远端的某个版本：`git reset --hard `
+- `git reset --hard HEAD^` reset index and working directory , 以来所有的变更全部丢弃，并将 HEAD 指向
+* `git reset --soft HEAD^` nothing changed to index and working directory ,仅仅将 HEAD 指向 ，所有变更显示在 “changed to be committed”中
+* `git reset --mixed HEAD^` default,reset index ,nothing to working directory 默认选项，工作区代码不改动，添加变更到index区
+
+# Revert
+> `git revert` will create a new commit that's the opposite (or inverse) of the given SHA. If the old commit is "matter", the new commit is "anti-matter"—anything removed in the old commit will be added in the new commit and anything added in the old commit will be removed in the new commit.
+> This is Git's safest, most basic "undo" scenario, because it doesn't alter history—so you can now git push the new "inverse" commit to undo your mistaken commit.
+
+```bash
+git revert [--[no-]edit] [-n] [-m parent-number] [-s] [-S[]] …
+git revert --continue
+git revert --quit
+git revert --abort
+```
+
+回滚撤销一系列 commit 中的一条，并且不影响后续提交的功能 ，```git revert c2```
+
+ (https://blog.csdn.net/u013066244/article/details/79920012) https://blog.csdn.net/u013066244/article/details/79920012
+
+# Restore
+分离 checkout 的功能，之前 checkout 可以切换分支，也可以恢复工作区的修改内容，现在这部分恢复修改内容由命令 restore来实现；
+git-restore[1] is about restoring files in the working tree from either the index or another commit. This command does not update your branch. The command can also be used to restore files in the index from another commit.
+
+
+## Revert VS Reset VS Restore
+
+想象一个简单的场景，分支 A，有 c1，c2，c3，c4，c5 五次 commit 提交，后来发现 c2 提交是有问题的，需要回滚，这个时候怎么解决？
+方案一 使用 reset 命令
+拉个新分支 A_bak ，复制现有分支， git reset --hard c2 ， c3，c4，c5 都没有了。 git cherry-pick c3，c4，c5 到 A 分支。
+
+方案二 使用 revert 命令
+```git revert c2``` 可能会出现冲突，解决冲突即可。 也可能 revert 的 commit 是个合并 merge 的分支，则需要多做个操作，即 ```git revert c2 -m 1 , git revert c2 -m 2``` ，详情参考：https://blog.csdn.net/u013066244/article/details/79920012
+
+现象：会创建一个新的 commit，即 c6 ，在 c6 的提交中，将 c2 里面的内容 反转掉 ，若有冲突，会展示冲突解决的文件内容。
+
+revert 可以说是就是为了这种场景而产生的，也应该是我们日常工作中经常使用的命令。
+
+
+# Diff
- 查看工作区（working directory）和暂存区（staged）之间差异：`git diff`
- 查看工作区（working directory）与当前仓库版本（repository）HEAD版本差异：`git diff HEAD`
- 查看暂存区（staged）与当前仓库版本（repository）差异：`git diff --cached` / `git diff --staged`
+- 不查看具体改动，只查看改动了哪些类:`git diff --stat`
# Merge
-- 解决冲突后/获取远程最新代码后合并代码：`git merge branchname`
-- 保留该存在版本合并log：`git merge --no-ff branchname` 参数`--no-ff`防止 fast-forward 的提交，详情参考：[the difference](http://stackoverflow.com/questions/9069061/what-is-the-difference-between-git-merge-and-git-merge-no-ff)
+
+
+
+- 解决冲突后/获取远程最新代码后合并代码：`git merge branchname` ，将 branchname 分支上面的代码合并到当前分支
+- 保留该存在版本合并log：`git merge --no-ff branchname` 参数 `--no-ff` 防止 fast-forward 的提交，详情参考：[the difference](http://stackoverflow.com/questions/9069061/what-is-the-difference-between-git-merge-and-git-merge-no-ff)，fast-forward：分支内容一致，指针直接移动，并未能看出分支信息
+
+# Rebase
+Rebase 同 Merge 的结果是一样的，就是合并本地、远程的改动，但过程中还有区别。
+``` bash
+git checkout mywork
+git rebase origin
+```
+这些命令会把你的"mywork"分支里的每个提交(commit)取消掉,并且把它们临时 保存为补丁(patch)(这些补丁 放到".git/rebase"目录中),然后把"mywork"分支更新 到最新的"origin"分支,最后把保存的这些补丁应用 到"mywork"分支上。
+一张图分清 rebase 和 merge 的区别
+
+
+在rebase的过程中,也许会出现冲突(conflict). 在这种情况,Git会停止rebase并会让你去解决冲突;在解决完冲突后,用 `git-add` 命令去更新这些内容的索引(index), 然后,你无需执行 git-commit,只要执行: `git rebase --continue` 这样git会继续应用(apply)余下的补丁。在任何时候,你可以用 --abort 参数来终止rebase的行动,并且"mywork" 分支会回到rebase开始前的状态。 `git rebase --abort`
+
+# Cherry Pick
+cherry-pick 命令"复制"一个提交节点并在当前分支做一次完全一样的新提交。
-# Branch
+
-- 查看分支：`git branch`
+# Branch workflow
+Aone2 Git 分支开发部署模型详细解读 [http://docs.alibaba-inc.com:8090/pages/viewpage.action?pageId=194872297](http://docs.alibaba-inc.com:8090/pages/viewpage.action?pageId=194872297)
+
+分支情况 origin
+- master
+- develop
+- release
+ - 20161129163217010_r_release_yingyongming
+ - 20161029163217010_r_release_yingyongming
+- feature
+ - 20161129_163448_newfeature_1
+ - 20161129_163448_newfeature_2
+- hotfix
+ - 20161129_163448_hotfix_1
+- tags
+ - 20161129163217010_r_release_newfeature_yingyongming
+创建分支的时候直接操作: `git checkout -b feature/20161129_163448_newfeature_1`
+
+
+
+- master：master永远是线上代码，最稳定的分支，存放的是随时可供在生产环境中部署的代码，当开发活动告一段落，产生了一份新的可供部署的代码时，发布成功之后，代码才会由 aone2 提交到 master，master 分支上的代码会被更新。应用上 aone2 后禁掉所有人的 master的写权限
+- develop：保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码，只对开发负责人开放develop权限。
+- feature: 功能特性分支，每个功能特性一个 feature/ 分支，开发完成自测通过后合并入 develop 分支。可以从 master 或者develop 中拉出来。
+- hotfix: 紧急bug分支修复分支。修复上线后，可以直接合并入master。
+
+
+
+Git-Develop 分支模式是基于 Git 代码库设计的一种需要严格控制发布质量和发布节奏的开发模式。develop 作为固定的持续集成和发布分支，并且分支上的代码必须经过 CodeReview 后才可以提交到 Develop 分支。它的基本流程如下：
+- 每一个需求/变更都单独从Master上创建一条Branch分支；
+- 用户在这个Branch分支上进行Codeing活动；
+- 代码达到发布准入条件后aone上提交Codereview，Codereview通过后代码自动合并到Develop分支；
+- 待所有计划发布的变更分支代码都合并到Develop后，系统再 rebase master 代码到Develop 分支，然后自行构建，打包，部署等动作。
+- 应用发布成功后Aone会基于Develop分支的发布版本打一个“当前线上版本Tag”基线；
+- 应用发布成功后Aone会自动把Develop分支的发布版本合并回master；
+
+
+## Branch 命令
+- 查看分支：`git branch` 、`git branch -v`、`git branch -vv` (查看当前分支 tracking 哪个远端分支)、`git branch --merged`、`git branch --no-merged`
- 创建分支：`git branch branchname`
+
+ 例： 基于 master 分支新建 dev 分支 ： `git branch dev`
- 基于之前的某个 Commit 新开分支： `git branch branchname `
+ 例： 基于上线的的提交 a207a38d634cc10441636bc4359cd8a18c502dea 创建 hotfix 分支 ： `git branch hotfix a207a38`
+ + 例: 基于 remoteBranch、localBranch、commitId、tag 创建分支均可以 `git checkout -b newbranch localBranch/remoteBranch/commitId/tag`
+ + 例: 创建一个空的分支
+ ``` bash
+ git checkout --orphan gh-pages # 创建一个orphan的分支，这个分支是独立的
+ Switched to a new branch \'gh-pages\'
+ git rm -rf . # 删除原来代码树下的所有文件
+ rm \'.gitignore\'
+ #注意这个时候你用git branch命令是看不见当前分支的名字的，除非你进行了第一次commit。添加新的文件，并且 commit 掉，就能看到分支了。
+ ````
- 切换分支： `git checkout branchname`
+
+ 例： 由分支 master 切换到 dev 分支：`git checkout dev`
- 创建新分支并切换到下面：`git checkout -b branchname` 或者 `git branch branchname && git checkout branchname`
+
+ 例：基于 master 分支新建 dev 分支，并切换到 dev 分支上： `git checkout -b dev` 或 `git branch dev && git checkout dev `
-- 查看分支代码不同：`git diff branchname`
-- 合并分支：`git merge branchname`
+- 查看分支代码不同：`git diff branchname` 比较 branchname 分支与当前分支的差异点，若只看文件差异，不看差异内容:`git diff branchName --stat`
+- 合并分支：`git merge branchname` 将 branchname 分支代码合并到当前分支
- 删除分支：`git branch -d branchname` 强制删除未合并过的分支：`git branch -D branchname`
-- 查看远程分支：`git branch -r` / `git branch -r -v`
+- 重命名分支: `git branch -m dev development` 将分支 dev 重命名为 development
+- 查看远程分支：`git branch -r` 或 `git branch -r -v`
- 获取远程分支到本地：`git checkout -b local-branchname origin/remote-branchname`
-- 推送本地分支到远程：`git push origin remote-branchname` / `git push origin local-branchname:remote-branchname`
- + 将本地 dev 代码推送到远程 dev 分支： `git push (-u) origin dev` / `git push origin dev:dev`
+- 推送本地分支到远程：`git push origin remote-branchname` 或 `git push origin local-branchname:remote-branchname`
+ + 将本地 dev 代码推送到远程 dev 分支： `git push (-u) origin dev` 或 `git push origin dev:dev`
+ （技巧）将本地 dev 分支代码推送到远程 master 分支： `git push origin dev:master`
-- 删除远程分支：`git push origin :remote-branchname` / `git push origin --delete remote-branchname`
+- 删除远程分支：`git push origin :remote-branchname` 或 `git push origin --delete remote-branchname`
+- 手动跟踪分支，master分支追踪origin/next分支: `git branch --track master origin/next` 或者 `git branch --set-upstream-to=origin/master` 看 git 的版本是否支持。
+- TrackingBranch，可以通过 `git branch -vv` 来查看当前 track 的分支情况。新建立分支时会自动 track 相应远程分支，`git checkout -b sf origin/serverfix` (Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'). 也可以手动 track: `git branch -u origin/serverfix` (Branch serverfix set up to track remote branch serverfix from origin). 等同于命令 `git checkout --track origin/serverfix`
+
+> “Checking out a local branch from a remote branch automatically creates what is called a “tracking branch” (or sometimes an “upstream branch”). Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type git pull, Git automatically knows which server to fetch from and branch to merge into.
+When you clone a repository, it generally automatically creates a master branch that tracks origin/master. However, you can set up other tracking branches if you wish – ones that track branches on other remotes, or don’t track the master branch. The simple case is the example you just saw, running git checkout -b [branch] [remotename]/[branch]. This is a common enough operation that git provides the --track shorthand:”
-# Tag
+# Tag
- 查看 tag：`git tag`
- 查找指定 tag，比如查找 V1.0.* ：`git tag -l 'V1.0.*'` 会列出匹配到的，比如 V1.0.1,V1.0.1.1,V1.0.2 等
- 创建轻量级 tag（lightweight tags）：`git tag tag-name` ，例如: `git tag v1.0`
-- 创建 tag（annotated tags）：`git tag -a tag-name -v 'msg'` ，例如：`git tag -a v1.0.0 -m '1.0.0版本上线完毕打tag'`
+- 创建 tag（annotated tags）：`git tag -a tag-name -m 'msg'` ，例如：`git tag -a v1.0.0 -m '1.0.0版本上线完毕打tag'`
+ annotated tags VS lightweight tags 可以通过命令真实查看下：`git show v1.0` / `git show v1.0.0`
+ “A lightweight tag is very much like a branch that doesn’t change – it’s just a pointer to a specific commit.
Annotated tags, however, are stored as full objects in the Git database. They’re checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). ”
@@ -91,4 +283,45 @@ Annotated tags, however, are stored as full objects in the Git database. They’
- 拉取远程 tag 到本地：`git pull remotename --tags` 例如：`git pull origin --tags`
- 推送 tag 到远程服务器：`git push remotename tagname` 例如：`git push origin v1.0.0`
- 将本地所有 tag 推送到远程：`git push remotename --tags` 例如：`git push origin --tags`
-- 删除远程 tag ：`git push origin :tagname` 或者 `git push origin --delete tagname`
+- 删除远程 tag ：`git push origin :tagname` 或者 `git push origin --delete tagname` 或者 `git push origin :refs/tags/v0.9`
+
+# Submodule
+添加子模块：$ git submodule add [url] [path]
+ 如：$ git submodule add git://github.com/soberh/ui-libs.git src/main/webapp/ui-libs
+初始化子模块：$ git submodule init ----只在首次检出仓库时运行一次就行
+更新子模块：$ git submodule update ----每次更新或切换分支后都需要运行一下
+删除子模块：（分4步走哦）
+ 1) $ git rm --cached [path]
+ 2) 编辑“.gitmodules”文件，将子模块的相关配置节点删除掉
+ 3) 编辑“ .git/config”文件，将子模块的相关配置节点删除掉
+ 4) 手动删除子模块残留的目录
+
+# Stash
+经常有这样的事情发生，当你正在进行项目中某一部分的工作，里面的东西处于一个比较杂乱的状态，而你想转到其他分支上进行一些工作。问题是，你不想提交进行了一半的工作，否则以后你无法回到这个工作点。解决这个问题的办法就是 `git stash` 命令。
+`stash` 可以获取你工作目录的中间状态，也就是你修改过的被追踪的文件和暂存的变更，并将它保存到一个未完结变更的堆栈中，随时可以重新应用。
+
+```
+usage: git stash list [] 查看当前 stash 的列表
+ or: git stash show [] 查看某一个版本的详细内容
+ or: git stash drop [-q|--quiet] [] 删除 stash 中内容
+ or: git stash ( pop | apply ) [--index] [-q|--quiet] [] 将 stash 中的代码应用到工作区中
+ or: git stash branch []
+ or: git stash [save [--patch] [-k|--[no-]keep-index] [-q|--quiet]
+ [-u|--include-untracked] [-a|--all] []]
+ or: git stash clear 清空 stash 中所有内容
+```
+
+# oh-my-zsh 常用命令
+```
+alias g='git'
+alias ga='git add'
+alias gco='git checkout'
+alias gcb='git checkout -b'
+alias gcm='git checkout master'
+alias gcd='git checkout develop'
+alias gd='git diff'
+alias gf='git fetch'
+alias gfo='git fetch origin'
+alias gl='git pull'
+alias gp='git push'
+```
diff --git a/video b/video
new file mode 100644
index 0000000..81cc581
--- /dev/null
+++ b/video
@@ -0,0 +1 @@
+https://www.youtube.com/watch?v=BCQHnlnPusY&t=2s
diff --git a/why-git.md b/why-git.md
index 3eb1860..046d88a 100644
--- a/why-git.md
+++ b/why-git.md
@@ -120,3 +120,4 @@ PS： `git`可以只提交一个文件修改的一部分而非全部（`git add
- `svn`：需要从服务拉取。
一旦用了`git`后，等待`svn`日志（包括查看2个版本间的`diff`）过程简直让我发狂。
+duide