译者：xqkuang，PCG 前端开发技师
Git 发展史和现况
Git 是 Linux 译者 Linus 的另两个经典作品。2002 年他还在采用 Bitkeeper 做为 Linux Mach的版管理工作，但因为它是 Copyright 有著作权的应用软件倍受批评，接着 Andrew Tridgell 对 Bitkeeper 展开逆向工程，引致 BitMover 要拆解 Linux 开发人员的 Bitkeeper 的完全免费所有权，Linus 一气之下花了 10 天写下了 Git。
英文名字的原意是：egotistical bastard
现如今 Git 早已正式成为大多数开发人员的优先选择， Tom Preston-Werner、Chris Wanstrath 和 PJ Hyett 在 2007 年 10 月面世的 Github 早已正式成为了亚洲地区最小的开发人员中文网站，他们厂在下面也是重大贡献颇多。
更有甚者，向来她们造车轮的的谷歌，也急于把巨达 300G 的 Windows 源码北迁到 Git 上展开管理工作，她们为 Git 提供更多了捷伊 GVFS 同时实现，有效地明显改善了 Git 对非常大标识符库房的操控性。
除此之外说一句：Docker 的十进制 image 管理工作，也是如前所述 git 同时实现的。
封闭式版管理工作和分布式系统版管理
Git 和 SVN 从结构设计经营理念上就不那样的版辅助工具，SVN 将标识符展开中心化管理工作，拥有更好的稳定性和安全性，但是去中心化的 Git 却从 Linux 操作系统的开发需求而来，更加适合多人协作的开源项目，可以以任何两个点为 remote 将他的标识符与本地标识符合并，随着时间发展，还衍生出了更多强大功能和一整套操纵流程，让它也可以适应了商业应用软件的开发。
SVN 的标识符发展史相对比较简单，即使它是中心化的，所有人的标识符都直接提交到某个 repository 上，所以它的 Reversion ID 号是两个按顺序增加的数字类型，一般情况下不能在两个数字之间插入别的 reversion。
Git 的看起来就是杂乱多了，它的 Reversion ID 号是两个 40 位长度的 hash 值，通常也可以缩写为 7 位，这样做的原因是即使 Git 的最小单位是标识符修改的发展史，即为补丁 Patch，而分支、 Tag、Remote（一会儿会说到这些概念）等都只是分支的集合，互相之间可以随意拆分、合并。
我更愿意把分支、Tag、Remote 想象成不同的平行宇宙，即使某些机缘引致产生了分裂，走向了不同的发展史，也可能即使某些机缘又合并到了一起，变得更加强大。
Git 基础命令
Git 按照场景可以分为以下场景（Scence）：
Workspace：当前工作区，修改的的最初状态。Staging：修改后，添加到准备提交的缓存状态。Local repository：本地的代码库房，只对她们的标识符生效。这也是和 svn 区别之一，svn commit 之后就直接提交到远程服务器了，git commit 之后只是到本地标识符库。Remote repository：远程标识符库，将她们的本地标识符库同步到远程标识符库上，这样可以供别的开发人员分享她们的成果。具体流程看图即可，下面对几个常用命令展开简单如是说
PS: 图中没有提到 rebase 和 cherry-pick 命令，这两个命令也非常强大，后面有提到，有时间可以关注一下。
补丁 diff之前有提到过，补丁是 Git/SVN 标识符版管理工作的基础概念，它其实是以行为单位的文件修改发展史，增加行以 + 号开头 ，删除行以 – 号开头，而修改一行，就是先 – 后 +。
在 Git 里可以通过 git diff 或者 Linux/Mac/Conemu 中，也可以通过 diff -Naur 来生成文件对比结果，有点类似下图。
这是整个标识符管理工作的基础概念，所有的分支、Tag、Remote 都是在此基础上衍生的。
$ git clone [REPOSITORY_URL]
对应到了 svn checkout 命令，用于把远程标识符克隆到本地，跟 svn 那样，REPOSITORY_URL 的协议非常灵活，之前流行用 ssh/scp 协议，但现在 https/http 协议渐渐流行起来了。
2. 更新标识符 – Status/Commit/Log刚有提到过 Git 的四种场景，其中前两种场景需要通过
$ git status
命令查看，标识符刚刚新建可以看到是 Untracked files（Workspace） 状态，执行 add 之后变成 Changes to be commited（Stage） 状态，修改了 Stage 中的文件，又会变成 Changes not staged for commit 状态。执行 commit 之后就从 Stage 中转移到了 Local repository 中，可以通过
$ git log
查看到标识符提交。
3. Branch 和 Tag如刚从所说，Branch 和 Tag 都可以看成是补丁的时序化集合，branch 可以互相合并，在 clone 完 repository 后有两个主线分支叫做 master。而 Tag 用于发布后标记版本，这两个只从英文名字上不那样，功能（我感觉同时实现上）并没有太大区别。
和 SVN 不同， SVN 的 Branch 和 Tag 都是把 Trunk 整个标识符库拷贝出来，Git 只是将补丁引用重新对当前标识符应用一下，所以 Git 的 Branch/Tag 都非常轻量，切换起来非常轻松，采用 Git 要尽量多采用它的分支来提高开发效率，一会儿提到 Git flow 时会描述一下如果用分支展开标识符功能开发管理。
3.1 新建分支的两种办法$ git checkout -b [BRANCH_NAME] # 在当前版切换并新建分支$ git branch [BRANCH_NAME] # 直接新建分支3.2 切换分支$ git checkout [BRANCH_NAME]
3.3 合并分支的两种办法$ git merge [BRANCH_NAME] # 将除此之外两个分支的标识符，打到当前分支之后。$ git rebase [BRANCH_NAME]# 不推荐，对标识符展开比较，将本分支修改后的标识符打到除此之外两个分支之后rebase 通常情况下不推荐采用，即使 rebase 完下游分支，再从上游分支 merge 的时候会丢失分支合并的 commit，但是对于部分有 history mysophobia 的人来说，它是保持标识符提交发展史记录干净的神器，那个 Merge branch xxx of http://git.code.oa.com/xxx into yyy 的 commit 看起来也挺讨厌的。
对于早已推到 remote repository 的 commit，是不建议 rebase 的，即使一旦 rebase 了，别人再 pull 就会出一大堆的冲突 conflict，而且基本没法修，通常情况下还是建议用 merge 稳妥一些。
PS: rebase 还有两个强大的功能是配合 –interactive 参数修改之前的补丁，具体她们查一下，但是改完了 push –force 上去，别人再 pull 回来出 conflict 是必然的，但是这招是修改 Github 上的 Pull request（后面有提到）必备技能。
3.4 删除分支$ git branch -d [BRANCH_NAME] # 早已合并到 master$ git branch -D [BRANCH_NAME] # 该分支未合并到 master，强制删除PS: 即使删除了分支等，也可以用 git reflogs 找回来喔
3.5 取消修改git stash # 取消全部修改，很强大的是它可以恢复过来，具体她们查一下git reset —soft [REV]# 保留修改内容，从 Local repository 中撤销，也可以用于回退发展史记录git reset —hard [REV] # 丢掉修改内容，从 Local repository 中撤销，也可以用于回退发展史记录推送本地标识符到远程库房推送标识符是为了跟别人一起合作，命令行非常简单
$ git push [REMOTE] [BRANCH]
remote 默认为 origin，如果不填的话就推送到它下面，branch 默认为当前分支，其实可以不加，加了就把指定的分支推送到远程了。如果要将推送本地功能分支，建议 push 后面加上 —set-upstream 参数。
郑重警告：永远不要对主线 master 分支执行 —force
$ git pull # 把标识符更新到 workspace$ git fetch # 把标识符更新到 Local repository，可能需要通过 merge 再合并到 worksapce 一次。远程库房Clone 之后会有两个默认的远程库房为 origin，但如果还要增加别的远程库房，就需要用到下面命令了：
$ git remote add [REMOTE_NAME] [URL]# 添加原创库房$ git fetch [REMOTE_NAME] $ git branch -a # 查看包括远程库房以内的所有分支$ git push [REMOTE_NAME] [BRANCH_NAME]# 推送到远程库房Github Pull Request & Gitlab Merge Request
Github 在 Git Remote 的基础上为了方便大家参与开源项目，衍生出的一套机制，目前常规开源项目的参与流程是，先注册两个 Github 账号，接着将感兴趣的开源项目 Fork 一份到她们的 namespace 下，然后拆分分支展开修改，接着提交到她们的 Github repository 下，再发起两个 Pull Request，让项目维护者来合并你的标识符（Pull request 名副其实），在这个过程中，项目维护者会对你的标识符展开 Review 和点评，你得按照维护者要求展开修改（这里 rebase 会用得很勤），修改通过，维护者同意后，就有他将标识符合并进项目中。
具体流程她们走一圈就明白了，Gitlab 的 Merge Request 原理是一模那样的。
PS: 范例图片在 PPT 的第 22 页起
Git flow
Git flow 本来应该是本文的重点内容的，它是在 Git branch 的基础上同时实现了一套简单的功能模块化开发流程，主要思想是把分支分成了上下游几个层级，接着通过一套命令行辅助工具展开维护。
master 分支 – 与线上版保持一致，当发生线上问题后可以很轻松地修复。develop 分支 – 功能开发基线分支，功能开发完之后合并到下面，所有功能开发完毕后经过测试上线，接着合并回 master。feature/* 功能开发分支 – 从 develop 上拆分，也需要随时把 develop 的更新 merge 回来，跟上游的分支保持一致，等功能开发完毕之后，即可合并到 develop。通过和上游分支保持一致，这样可以避免对误删别人的标识符，所有标识符冲突必须在下游分支修好，测试完毕后才可合并到上游分支。hotfix/* 热修复分支 – 主要用于线上 bug 修复，但是修复后应该同时合并到 master 和 develop 两个分支上。接着 git flow 提供更多了套命令行辅助工具来更加轻松地去做这些标识符合并的事情。
$ git flow init # 初始化 git flow 分支模型$ git flow feature start [NAME] # 开始两个功能分支$ git flow feature finish [NAME]# 将功能分支合并进 develop$ git flow hotfix start [NAME] # 开始两个热修复分支$ git flow hotfix finish [NAME]# 将补丁合并进 develop 和 master$ git flow release [NAME] # 发布两个新版，打 tag感觉 Git flow 得有个篇幅，下次有机会再来详述。
其它内容
有兴趣可以继续看一下别的相关内容，非常有原意：
git svn – Git 可以以 svn 为标识符后端，通过 Giit 来对 SVN 里的标识符展开版管理工作。git reflogs – 引用记录，在 git 中误删除某提交是不用害怕的，只要 commit 了，就可以通过 reflogs 找到，用 reset 或者 cherry pick 恢复。git cherry pick – 摘樱桃（commit），从另两个分支中单独将某个 patch 摘回来。git bare repository – 建立 Git 服务器git submodule – 子模块，两个大项目可以通过 submodule 展开拆分，可以随时展开子模块的版更新和回溯。git hooks – 钩子，当 git 在 repository 上发生某种行为的时候，可以通过钩子触发一些行为，像目前 Github 上的一些第三方持续集成服务，就是在此基础上同时实现的。git signature – 签名，通过 gpg 在 commit 时对 patch 展开签名，证明那个补丁确实是她们提交的，可以参考一下Github 的文档。Source Tree – Source Tree 是一套跨平台的 Git 图形界面，简单方便，我目前主要用它展开基本的 Patch 阅读，比命令行更加舒服。多谢阅读，下次有机会再写。
推荐阅读：
