动笔写GitHub不是因为我对其了解，恰恰是对其太不了解。
在我的《Git权威指南》 [1] 一书中，涉及到GitHub的只有区区三页纸，这显然回答不了读者对于GitHub的诸多疑问。
记得在《Git权威指南》刚刚完稿之际，机械工业出版社华章公司的杨福川编辑就鼓动我写一本关于GitHub的书，我用了好多理由推辞了。
头条理由就是我真的累着了。在每一章节开始动笔之时，都好像是坐在了中学语文考试的考堂上写作文，时间快到了可仍然动不了笔，
再写一本书无疑要重复这一痛苦的经历。
第二个理由是我更喜欢编程，而不是写文档，尤其写GitHub会有大量截图、图像处理的琐碎工作。
第三个理由彻底让编辑投降，那就是GitHub是一个国外网站，也许书一出，【此句已被原作者删除】。
让我最终决定动笔，是源于CSDN蒋总在美国拜访GitHub总部后告诉我的一些见闻，我对GitHub如此成功运作产生了兴趣，于是开始研究GitHub的博客，愈发发现GitHub是一群有趣的人在做的有趣的事，如果只把GitHub当作一个Git服务器，实在是暴殄天物。GitHub已经并将继续获得成功，若真能凭借此书把GitHub尽量全面地展现，让每一个Git使用者用好GitHub也是一件幸事。
这本书将采用GitHub的方式进行撰写和发布 [2] ，任何人都可以看到本书（包括源码），更可以用GitHub的方法参与本书的撰写和纠错。网络出版对于我和杨福川编辑都是一个全新的体验。感谢Git，让我在一年内拥有了两种不同的出版体验。
– 蒋鑫, 2011.12
================================================
FILE: ixirong.com.md
================================================
原文出自：http://ixirong.com/2014/11/19/the-way-to-learn-git/
## 一、什么是git？
> 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的方法。
既然是分布式版本管理，那么和我们平常使用的svn有什么区别？
1. 分布式 vs 集中管理 （多份版本库 vs 一份版本库，设想下版本服务器挂了？）
2. 无需网络，随时随地进行版本控制，在没有网络的情况下你想回退到某个版本svn基本没戏；
3. 分支的新建、合并非常方便、快速，没有任何成本，基本不耗时，svn的版本基本上等同于又复制了一份代码；
**stackoverflow** 上关于svn和git的区别的讨论，说的很详细，请参考 [Why is Git better than Subversion?](http://stackoverflow.com/questions/871/why-is-git-better-than-subversion)
**github** 上通过版本库结构、历史、子项目（submudle）的不同来对比两者，请参考 [What are the differences between SVN and Git?](https://help.github.com/articles/what-are-the-differences-between-svn-and-git/)
## 二、git 安装
《pro git》一书中已经写明白了[各个平台上怎么安装git](http://git-scm.com/book/zh/v1/%E8%B5%B7%E6%AD%A5-%E5%AE%89%E8%A3%85-Git),如果感觉晦涩，就看这个[廖雪峰安装git](http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/00137396287703354d8c6c01c904c7d9ff056ae23da865a000)
## 三、git 初使用
- 对于已经熟悉svn的用户可以直接查看此文档 [Git - SVN Crash Course](http://git.or.cz/course/svn.html)，通过对比两个工具对同样的操作采取不同的命令来快速认识git的一些常用命令
- 对于一个新手来说，我不需要知道git的原理，不需要知道git那么多的命令，我只想用git完成一次仓库的从初始化、commit、push、branch、tag等一个流程，越简单越好，图文教程，以window下使用git为例，一步步走完整个流程，推荐 [手把手教你使用Git](http://blog.jobbole.com/78960/)
- 比较全面讲述的git的系列文章 [号称史上最浅显易懂的Git教程！](http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000)
- 看完上面的几步内容，想你习对git基本上可以使用了，要掌握还得多多练习，熟能生巧，你是不是想去看看关于git的全部内容 ，[官方中文电子版书籍](http://git-scm.com/book/zh/v1)即可满足你，当然你可以查看最新[V2版英文](http://git-scm.com/book/en/v2)或者下载epub pdf等本地阅读；
## 四、git 分支、tag
git 最帅气的就是对分支的处理，方便快速，你只需要一个简单的
``` bash
git branch branch-name
```
就能开出一个叫branch-name的分支，毫秒钟搞定，但也正是因为方便，如果使用不合理就会造成**分支混乱，分不清脉络**， 推荐看一下阮一峰写的文章 [Git分支管理策略](http://www.ruanyifeng.com/blog/2012/07/git.html) ，最原始的文章就是这篇老外写的[A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)，[@萌面大叔的乌托邦]()提到开源中国已经翻译成了中文，感兴趣的可以去看看[介绍一个成功的 Git 分支模型](http://www.oschina.net/translate/a-successful-git-branching-model)
## 五、git 常见命令
一个比较好的汇总了git的一些基本命令的pdf，可以经常看看，或者当成命令手册，推荐 [Git Cheat Sheet](http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf) ，还有一张图片 [Git常用命令](http://www.cnblogs.com/1-2-3/archive/2010/07/18/git-commands.html) 也不错；最近我整理了一份xmind的导图，将**这两份**资料都放到了画布里面，[百度网盘](http://pan.baidu.com/s/1c052yVu) 密码：`6x7u` 存储了，不断更新，有需要的可以下载，预览图片如下：
最强大的**命令手册**还得属于终端，* man git * 或者 * man git 命令 * 或者 * git --help * 或者 * git 命令 --help *，在这里可以找到任何你想要的。
## 六、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)》；
-《[Git Community Book](http://gitbook.liuhui998.com/)》汇聚了Git社区的很多精华, 并对git的对象模型原理等做了解释，可以深入的了解下git原理；
2015-01-22 增加
- 推荐的工作流程 [git workflow](http://documentup.com/skwp/git-workflows-book)
2015-04-05 增加 git flow 工具
- [git flow 工具](https://github.com/nvie/gitflow)
- [git flow 中文备忘清单](http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html)
- 一个很有意思的学习 git 的小游戏 http://pcottle.github.io/learnGitBranching/
- [图解 git](http://marklodato.github.io/visual-git-guide/index-zh-cn.html) 将书籍中很多
术语用图片的方式进行讲解，很容易就懂了
- [图文并茂-猴子都能懂的git入门教程](http://backlogtool.com/git-guide/cn/) 全面，生动形象，图文并茂，简单易懂，强烈推荐！
关于日常中使用git来版本管理的流程写的很不错的一本书，日常工作模式、流程怎样更合理的工作！
** 最后，当你开始使用git的时候，学会用终端，比如你想看关于branch，那么大胆的时候 *git branch --help * 查看相应的命令！ **
================================================
FILE: readme.md
================================================
# 说明
这整个 Repository 是关于分布式版本管理工具 Git 及托管商 Github 的使用，大部分都是网友写的内容，在这里只是做一个资源的汇总和合理的安排，希望能成为最好的学习 Git 的资源，从开始入门使用，到慢慢的提高，再到理解各种原理，希望能够达成这个目标。
网络上面已经有了那么多的关于 Git 的文章，为什么还要弄一个repo来专门记录？网上的文章都是片面的，稍微全点的讲解的不够全面、深入，没能满足我对于文章的想象，所以决定自己来写。
如果你要有一些资源，希望和我一起，把这个搞起来，很简单，`Fork-修改- Pull Request` 就 ok。
# 新手入门
- [为什么开始使用 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 .
- [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太难用了：
- [GUI Clients](https://git-scm.com/downloads/guis) 官方推荐图形客户端，罗列的包括了Mac、Windows、Linux下的客户端，免费及付费的都有，你可以在这里面挑选一个就ok。
- [Git for windows](https://msysgit.github.io/) 针对 Window 系统发布的客户端，集成了 Shell 窗口，方便在 Win 下面使用命令操作。
- [TortoiseGit - The coolest Interface to Git Version Control](https://code.google.com/p/tortoisegit/) 在window下使用git，那就不得不提“乌龟”，安装了 Tortoise 后，右键图形化操作根本分辨不出来哪是 Git，哪是 Svn，很方便使用 Svn 的用户过度过来。
- [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
- [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)
- 熟悉的工作流后，你是否也想要在 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
- 项目依赖其他项目，比如公共 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)》；
- [Git-internals-pdf](https://github.com/pluralsight/git-internals-pdf) 老外写的，很给力，从目录上面包括安装使用以及设计原理都有讲解，有机会看看。Pdf 电子版本直接下载地址 [Git-internals.pdf](ebooks/git-internals.pdf)
- [Git Community Book](http://gitbook.liuhui998.com/) 汇聚了 Git 社区的很多精华, 并对 Git 的对象模型原理等做了解释，可以深入的了解下 Git 原理。pdf电子版本直接下载地址 [Git Community Book.pdf](ebooks/Git Community Book.pdf)
- [Git权威指南](http://book.douban.com/subject/6526452/) 国内版本控制咨询顾问蒋鑫先生的原创书籍，原生中文叙述，更容易理解，查看[作者写书的缘由](http://www.worldhello.net/gotgit/)
- [Git Reference](http://gitref.org/) [中文](http://gitref.org/zh/index.html) 为学习与记忆 Git 使用中最重要、最普遍的命令提供快速翻阅，可作为参考资料。
- [Git Magic - a guide from standord](https://github.com/blynn/gitmagic) 斯坦福大学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 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
# 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 日常开发常用命令整理](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 「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) 撤销一切，汇总各种回滚撤销的场景，加强学习。
- [怎样在一台电脑上同时使用公司 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的一些命令，非常有趣。
================================================
FILE: use-gitlab-github-together.md
================================================
说明
====================
由于公司团队使用 GitLab 来托管代码，同时，个人在 Github 上还有一些代码仓库，可公司邮箱与个人邮箱是不同的，由此产生的 SSH key 也是不同的，这就造成了冲突 ，文章提供此类问题的解决方案：**如何在一台机器上面同时使用 Github 与 Gitlab 的服务？**
# 问题产生场景
-------------
## 无密码与远程服务器交互的秘密 - SSH
如果采用`ssh 协议`或者`git 协议`通过终端命令对远程仓库进行`push`操作的时候，大概的过程如下：（前提在 Github 上已经配置的本机的 SSH Public Key）
1. 客户端发起一个 Public Key 的认证请求，并发送RSA Key的模数作为标识符。（关于 RSA Key 详细 [维基百科](https://en.wikipedia.org/wiki/RSA_(algorithm))）
2. 服务端检查是否存在请求帐号的公钥（Linux中存储在~/.ssh/authorized_keys文件中），以及其拥有的访问权限。
3. 服务端使用对应的公钥对一个随机的256位的字符串进行加密，并发送给客户端。
4. 客户端使用私钥对字符串进行解密，并将其结合session id生成一个MD5值发送给服务端。 结合session id的目的是为了避免攻击者采用重放攻击（replay attack）。
5. 服务端采用同样的方式生成MD5值与客户端返回的MD5值进行比较，完成对客户端的认证。
6. 将push的内容进行加密与服务端传输数据。
关于 SSH，请查看 [SSH原理简介](http://erik-2-blog.logdown.com/posts/74081-ssh-principle) ，更通俗易懂的文章请查看[阮一峰-SSH原理与运用（一）：远程登录](http://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html) 。
## 具体场景
无论使用哪种代码托管服务商，对于 Git 而言，`邮箱` 是识别用户的唯一手段，所以对于不同的服务商，由于邮箱不同，那么通过邮件名创建的 SSH Key 自然是不同的，这时候在不同的服务商之间进行 `push` 命令的时候，Git 是不知道使用哪个 SSH Key ，自然导致 `push` 的失败。场景如下：
1. 在公司团队使用搭建的 Gitlab 服务，提交邮箱`xirong.liu@corp.xx.com`， 个人 Github 服务，提交邮箱 `ixirong.liu@gmail.com` （Bitbucket 同理）。
2. 有两个Github账户，不同的账户提交不同的仓库内容。
# 解决方案
## 方案一：同一个邮箱
由于`邮箱`是识别的唯一手段，那么自然的，这两者采用同一个邮箱，生成的 public key 也会是同一个，上传到 Github 或者 Gitlab 上面，在 Git 的配置中 ，设置好 Global 的配置 ：` git config --global user.name 'xirong.liu' && git config --global user.email 'xirong.liu@corp.xx.com'` 进行日常的开发是没有问题的。
实际生活中采用同一个邮箱的可能性并不是太大，这就引出了方案二
## 方案二：基于config文件
所谓的方案二，原理上就是对 SSH 协议配置 config 文件，对不同的域名采用不同的认证密钥。
#### git config 介绍
Git有一个工具被称为git config，它允许你获得和设置配置变量；这些变量可以控制Git的外观和操作的各个方面。这些变量可以被存储在三个不同的位置：
1. /etc/gitconfig 文件：包含了适用于系统所有用户和所有库的值。如果你传递参数选项’`--system`’ 给 git config，它将明确的读和写这个文件。
2. ~/.gitconfig 文件 ：具体到你的用户。你可以通过传递 ‘`--global`’ 选项使Git 读或写这个特定的文件。
3. 位于 Git 目录的 config 文件 (也就是 .git/config) ：无论你当前在用的库是什么，特定指向该单一的库。每个级别重写前一个级别的值。因此，在 .git/config 中的值覆盖了在/etc/gitconfig中的同一个值，可以通过传递‘`--local`’选项使Git 读或写这个特定的文件。
由于采用了不同的邮箱，对不同的服务商进行提交，所以此时我们经常配置的 `git config --global` 就不能常用了，必须在每个仓库的目录下进行配置自己的用户名、邮箱。（嫌麻烦？xirong 是这么解决的，由于个人的 Github 上有较多的仓库，而自己团队的代码基本上都是稳定的，有数的几个，所以在 `git config --global user.email 'ixirong.liu@gmail.com'` 中全局配置的是个人邮箱，在团队的项目中配置）
### 1. 配置 Git 用户名、邮箱
如刚才所说，xirong 的配置如下：
``` bash
# 全局配置，Github仓库中默认使用此配置
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.example.com'
```
### 2. 生成 ssh key 上传到 Github/Gitlab
ssh key 默认生成后保存在 `~/.ssh/`目录下 ，默认为 `id_rsa 和 id_rsa.pub` 两个文件，由于我们需要分开配置，所以这么做：
``` bash
# 生成公钥、密钥的同时指定文件名，Gitlab使用
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"
```
命令执行完成后，这时`~/.ssh`目录下会多出`id_rsa.gitlab`和`id_rsa.gitlab.pub`两个文件，`id_rsa.gitlab.pub` 里保存的就是我们要使用的key，这个key就是用来上传到 Gitlab上的。
### 3. 配置 config 文件
在 `~/.ssh`目录下，如果不存在，则新建 `touch ~/.ssh/config`文件 ，文件内容添加如下：
``` bash
Host corp.example.com
HostName git.corp.example.com
IdentityFile ~/.ssh/id_rsa.gitlab
User xirong.liu
```
- `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
以Github为例，过程如下：
1. 登录github
2. 点击右上方的Accounting settings图标
3. 选择 SSH key
4. 点击 Add SSH key
在出现的界面中填写SSH key的名称，填一个你自己喜欢的名称即可，然后将上面拷贝的`~/.ssh/id_rsa.pub`文件内容粘帖到`key`一栏，在点击“`add key`”按钮就可以了。
添加过程github会提示你输入一次你的github密码 ，确认后即添加完毕。 上传Gitlab的过程一样，请自己操作。
### 5. 验证是否OK
由于每个托管商的仓库都有唯一的后缀，比如 Github的是 `git@github.com:*`，所以可以这样测试：
``` bash
➜ ~ ssh -T git@github.com
Hi xirong! You've successfully authenticated, but GitHub does not provide shell access.
➜ ~ ssh -T git@gitlab.dev
Welcome to GitLab, xirong.liu!
```
看到这些 `Welcome` 信息，说明就是 OK的了。
以后，如果还有任何的需求，都可以这么解决，看下 xirong 的几个托管仓库：
``` bash
➜ ~ ll ~/.ssh
total 40
-rw-r--r-- 1 xirong staff 264 Jul 10 14:42 config
-rw------- 1 xirong staff 3243 Jul 10 14:09 id_rsa
-rw------- 1 xirong staff 1675 Jan 28 20:39 id_rsa.gitlab
-rw-r--r-- 1 xirong staff 407 Jan 28 20:39 id_rsa.gitlab.pub
-rw-r--r-- 1 xirong staff 747 Jul 10 14:09 id_rsa.pub
-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
```
================================================
FILE: useful-git-command.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`
+ 例如，clone jquery 仓库到本地： `git clone git://github.com/jquery/jquery.git`
+ clone jquery 仓库到本地，并且重命名为 my-jquery ：`git clone git://github.com/jquery/jquery.git my-jquery`
- 查看远程仓库：`git remote -v`
- 添加远程仓库：`git remote add [name] [repository-url]`
- 删除远程仓库：`git remote rm [name]`
- 修改远程仓库地址：`git remote set-url origin new-repository-url`
- 拉取远程仓库： `git pull [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 `
# 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`
- 一行显示日志：`git log --pretty=oneline` / `git log --pretty='format:"%h - %an, %ar : %s'`
- 查看日志范围：
+ 查看最近10条日志：`git log -10`
+ 查看2周前：`git log --until=2week` 或者指定2周的明确日期，比如：`git log --until=2015-08-12`
+ 查看最近2周内：`git log --since=2week` 或者指定2周明确日志，比如：`git log --since=2015-08-12`
+ 只查看某个用户的提交：`git log --committer=user.name` / `git log --author=user.name`
+ 只查看提交msg中包含某个信息的历史，比如包含'测试'两个字的：`git log --grep '测试'`
+ 试试这个 ： `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'`
- 修改上次提交的 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 `
# 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` ，将 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 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` 比较 branchname 分支与当前分支的差异点，若只看文件差异，不看差异内容:`git diff branchName --stat`
- 合并分支：`git merge branchname` 将 branchname 分支代码合并到当前分支
- 删除分支：`git branch -d branchname` 强制删除未合并过的分支：`git branch -D branchname`
- 重命名分支: `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`
+ （技巧）将本地 dev 分支代码推送到远程 master 分支： `git push origin dev:master`
- 删除远程分支：`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：`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 -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). ”
- 查看指定 tag 信息：`git show tag-name`
- 基于历史某次提交（commit）创建 tag ：`git tag -a tagname `
+ 例：基于上线时的提交 a207a38d634cc10441636bc4359cd8a18c502dea 创建tag：`git tag -a v1.0.0 a207a38`
- 删除 tag ：`git tag -d tagname`
- 拉取远程 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` 或者 `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'
```
================================================
FILE: using-svn.md
================================================
说明
===========
在日常开发中使用的 Svn 相关的概念以及技巧方法整理 ……
[TortoiseSvn 使用](http://tortoisesvn.net/docs/release/TortoiseSVN_zh_CN/index.html)
================================================
FILE: video
================================================
https://www.youtube.com/watch?v=BCQHnlnPusY&t=2s
================================================
FILE: why-git.md
================================================
使用svn用的好好的，为什么要用git？git有哪些优势？又有哪些劣势？在日常使用中两者明显的差异是什么？
（关于 svn 的使用，一起来回顾一下 [How To Use Svn in Daily Work](using-svn.md)）
- [Why is Git better than Subversion?](http://stackoverflow.com/questions/871/why-is-git-better-than-subversion) stackoverflow 上关于svn和git的区别的讨论，说的很详细。
- [What are the differences between SVN and Git? ](https://help.github.com/articles/what-are-the-differences-between-svn-and-git/) github 上通过版本库结构、历史、子项目（submudle）的不同来对比两者。
- [蒋鑫：为什么 Git 比 SVN 好？](http://www.worldhello.net/2012/04/12/why-git-is-better-than-svn.html "蒋鑫 - Why `Git` is better than `SVN`")
以下内容出自 [@oldratlee](https://github.com/oldratlee) 的 [repo](https://github.com/oldratlee/software-practice-miscellany/blob/master/git/README.md)。
SVN 和 Git 在日常使用中的明显差异
=========================
:point_right: 自己在使用`git`过程中相对`svn`的感受强烈的变化。
:beer: 合并对提交过程的保留
-------------------
- `git`：合并操作保留原有的提交过程（即保留了合并来源的作者、提交次数、分离提交的内容）。
- `svn`：合并操作把来源多个提交合并成了一个合并提交，即在提交历史中Crash了自然的提交过程。
保留原有的提交过程，可以无需繁琐追踪历史就方便的
1. 跟踪修改过程。
1. 直接从提交中就可以看到原提交的作者信息，体现了对作者的尊重。
1. 自然的提交过程。这极大方便了代码细节演进过程的查看。
1. 极大方便查出那行提交是什么时间、谁做出的。
`svn`因为合并Crash了自然的提交过程，要追踪很痛苦。
:beer: 修正提交
-------------------
- `git`：可以修正提交。
使用功能分支工作流，在自己的分支可以方便修正提交而不会影响大家。
- `svn`：一旦提交就到服务器上，实际使用中就是不能修改。
（`svn`可以在服务器上修改，因为过程复杂需要权限实际上从不会这样做。）
实际使用中会有误提交的情况（如提交了一个不该提交的日志文件），对于`svn`来说，就是让大家一遍又一遍看到这个垃圾文件。
没有干净的提交，严重影响了`Code Review`，增加成本。
另外对于想了解演进过程的同学，垃圾提交影响了了解效果。
:beer: 廉价好用的本地分支
-------------------
- `git`：有本地分支
- `svn`：无本地分支
`git`可以方便创建本地分支，且创建分支的时间是`O(1)`，即瞬间就创建好了。由于分支可以是本地的，也就不存在`svn`目录权限的问题。
可以从想要工作点闪电般创建本地分支，本地实验不确定的修改，创建分支如此之廉价，`git`推荐创建分支来隔离修改。
:beer: 更强大智能的合并能力
----------------
- `git`：重命名（无论文件还有目录）提交 可以合并上 文件重命名前的这些文件的提交。
- `svn`：重命名（无论文件还有目录）提交后，你本地/或是分支上 有文件重命名前的这些文件的修改或提交，在做合并操作时，恭喜:see_no_evil:，你会碰上传说中难搞的***树冲突***！
因为惧怕`svn`***树冲突***，在包名调整（重命名目录）或类名调整（重命名文件）前，我不得不先向一起开发的组员广播：
1. 提交你的修改
1. 暂停相关类的修改
1. 我开始做调整
1. 等我修改好后:scream:，你再开始修改
OMG～ :confounded:～～
因为这个过程烦琐，结果就是影响了大家去做这样重构操作的积极性，进而影响项目的代码质量改进！
别忘了，如果你的项目是开源的，全球的人可以给你提交，可没有办法向全球的同学广播 :kissing:
:beer: 一等公民支持`tag`
-------------------
- `svn`在模型上是没有分支和`tag`的。`tag`是通过目录权限限制（对开发只读）来保证不变。
- `git`模型上一等公民支持`tag`，保证只读。
内心是不是有强烈的安全感？ :sparkles:
:beer: 完整配套的开发过程设施
-------------------
与`git`配套的`github`、`gitlab`（我们公司搭建了）提供了：
- `Markdown`：高效的文档编写和查看。
- `Issue` & `Milestone`：问题记录&跟踪，任务分配，版本规划&管理
- `Wiki`系统：体系的文档
- 评论：可以对代码提交（即是Code Review）& Issue做评论。
这个有记录交流的过程。
记住，上面的一切和代码一起集中管理，是以代码为中心的，可以方便的工程中的代码。
可运行并完成功能的代码（且叫目标代码） 才是整体项目真正生效的产出。
一切不为 目标代码 服务 的东东都是 **流氓**！
\# 是不是想到很多东西（比如下压式的排期计划）会觉得自己是生效的产出，好像剩下的事就是 码农搬砖一样把代码码好。
:beer: 热操作有闪电般的速度
-------------------
### 提交
- `git`提交是个本地操作，相对`svn`闪电一般。
- `git`提供了暂存区，可以方便指定提交内容，而不是全部。
PS： `git`可以只提交一个文件修改的一部分而非全部（`git add –p`），使用相对繁琐些。（实际上开发中我很少这么做 :grin:）
这让开发者更愿意整理提交，让每个提交更内聚自包含。进而有利于
- `Code Review`
- 线上`Bug`的快速准确的回滚式修复
### 查看日志
查看日志是个频繁的操作。
- `git`：本地包含了完整的日志，闪电的速度（并且无需网络）。
- `svn`：需要从服务拉取。
一旦用了`git`后，等待`svn`日志（包括查看2个版本间的`diff`）过程简直让我发狂。
duide