小结：
1、如果要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来
2、注意 git clone 应指定版本，它复制的这个版本的全部历史信息；
各个分支 git init 数据库
master分支 git 数据库
“分布式 地位平等的 ” “git 区别与svn，没有 c/s 主从的概念”“”“c/s” 大家都往这个分支提交，这个分支就是“c/s”中的“s”?
master分支 非master分支地位平等
master只是第一个分支的默认名字而已，任意改。
git clone 时 clone 的是哪个分支，然后本地pull过来的就是哪个分支，push过去的目的地就是哪个分支？
https://git-scm.com/book/zh/v1/起步-Git-基础#近乎所有操作都是本地执行
直接记录快照，而非差异比较
Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容，请看图 1-4。
图 1-4. 其他系统在每个版本中记录着各个文件的具体差异
Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就像图 1-5 所示。
图 1-5. Git 保存每次更新时的文件快照
这是 Git 同其他系统的重要区别。它完全颠覆了传统版本控制的套路，并对各个环节的实现方式作了新的设计。Git 更像是个小型的文件系统，但它同时还提供了许多以此为基础的超强工具，而不只是一个简单的 VCS。稍后在第三章讨论 Git 分支管理的时候，我们会再看看这样的设计究竟会带来哪些好处。
近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。但如果用 CVCS 的话，差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。
举个例子，如果要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。所以任何时候你都可以马上翻阅，无需等待。如果想要看当前版本的文件和一个月前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算，而不用请求远程服务器来做这件事，或是把老版本的文件拉到本地来作比较。
用 CVCS 的话，没有网络或者断开 VPN 你就无法做任何事情。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程仓库。同样，在回家的路上，不用连接 VPN 你也可以继续工作。换作其他版本控制系统，这么做几乎不可能，抑或非常麻烦。比如 Perforce，如果不连到服务器，几乎什么都做不了（译注：默认无法发出命令 p4 edit file 开始编辑文件，因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文件权限可以绕过这个限制，只是完成后还是无法提交更新。）；如果是 Subversion 或 CVS，虽然可以编辑文件，但无法提交更新，因为数据库在网络上。看上去好像这些都不是什么大问题，但实际体验过之后，你就会惊喜地发现，这其实是会带来很大不同的。
时刻保持数据完整性
在保存到 Git 之前，所有数据都要进行内容的校验和（checksum）计算，并将此结果作为数据的唯一标识和索引。换句话说，不可能在你修改了文件或目录之后，Git 一无所知。这项特性作为 Git 的设计哲学，建在整体架构的最底层。所以如果文件在传输时变得不完整，或者磁盘损坏导致文件数据缺失，Git 都能立即察觉。
Git 使用 SHA-1 算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，作为指纹字符串。该字串由 40 个十六进制字符（0-9 及 a-f）组成，看起来就像是：
24b9da6552252987aa493b52f8696cd6d3b00373
Git 的工作完全依赖于这类指纹字串，所以你会经常看到这样的哈希值。实际上，所有保存在 Git 数据库中的东西都是用此哈希值来作索引的，而不是靠文件名。
多数操作仅添加数据
常用的 Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作，比如删除数据，都会使回退或重现历史版本变得困难重重。在别的 VCS 中，若还未提交更新，就有可能丢失或者混淆一些修改的内容，但在 Git 里，一旦提交快照之后就完全不用担心丢失数据，特别是养成定期推送到其他仓库的习惯的话。
这种高可靠性令我们的开发工作安心不少，尽管去做各种试验性的尝试好了，再怎样也不会弄丢数据。至于 Git 内部究竟是如何保存和恢复数据的，我们会在第九章讨论 Git 内部原理时再作详述。
文件的三种状态
好，现在请注意，接下来要讲的概念非常重要。对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库中了；已修改表示修改了某个文件，但还没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。
由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。
图 1-6. 工作目录，暂存区域，以及本地仓库
每个项目都有一个 Git 目录（译注：如果 git clone 出来的话，就是其中 .git 的目录；如果 git clone --bare 的话，新建的目录本身就是 Git 目录。），它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。
从项目中取出某个版本的所有文件和目录，用以开始后续工作的叫做工作目录。这些文件实际上都是从 Git 目录中的压缩对象数据库中提取出来的，接下来就可以在工作目录中对这些文件进行编辑。
所谓的暂存区域只不过是个简单的文件，一般都放在 Git 目录中。有时候人们会把这个文件叫做索引文件，不过标准说法还是叫暂存区域。
基本的 Git 工作流程如下：
- 在工作目录中修改某些文件。
- 对修改后的文件进行快照，然后保存到暂存区域。
- 提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。
所以，我们可以从文件所处的位置来判断状态：如果是 Git 目录中保存着的特定版本文件，就属于已提交状态；如果作了修改并已放入暂存区域，就属于已暂存状态；如果自上次取出后，作了修改但还没有放到暂存区域，就是已修改状态。到第二章的时候，我们会进一步了解其中细节，并学会如何根据文件状态实施后续操作，以及怎样跳过暂存直接提交。
(克隆指定分支)
git clone -b dev git@192.68.11.123:root/autocloudservices.git
git clone -b master git@192.68.11.123:root/autocloudservices.git
git+ssh://git@gitlab-test.d5.com:182/python/e.logging_sdk.git@fxl requirement
[xiaole@localhost .git]$ tree -sf
.
├── [ 6] ./branches
├── [ 264] ./config
├── [ 73] ./description
├── [ 20] ./HEAD
├── [ 242] ./hooks
│ ├── [ 452] ./hooks/applypatch-msg.sample
│ ├── [ 896] ./hooks/commit-msg.sample
│ ├── [ 189] ./hooks/post-update.sample
│ ├── [ 398] ./hooks/pre-applypatch.sample
│ ├── [ 1704] ./hooks/pre-commit.sample
│ ├── [ 1239] ./hooks/prepare-commit-msg.sample
│ ├── [ 1348] ./hooks/pre-push.sample
│ ├── [ 4951] ./hooks/pre-rebase.sample
│ └── [ 3611] ./hooks/update.sample
├── [ 10448] ./index
├── [ 21] ./info
│ └── [ 240] ./info/exclude
├── [ 30] ./logs
│ ├── [ 195] ./logs/HEAD
│ └── [ 34] ./logs/refs
│ ├── [ 17] ./logs/refs/heads
│ │ └── [ 195] ./logs/refs/heads/dev
│ └── [ 20] ./logs/refs/remotes
│ └── [ 18] ./logs/refs/remotes/origin
│ └── [ 195] ./logs/refs/remotes/origin/HEAD
├── [ 30] ./objects
│ ├── [ 6] ./objects/info
│ └── [ 121] ./objects/pack
│ ├── [ 10312] ./objects/pack/pack-0428e2c92ad659916d4f1dcf0548dbb152dd0720.idx
│ └── [ 384838] ./objects/pack/pack-0428e2c92ad659916d4f1dcf0548dbb152dd0720.pack
├── [ 172] ./packed-refs
└── [ 46] ./refs
├── [ 17] ./refs/heads
│ └── [ 41] ./refs/heads/dev
├── [ 20] ./refs/remotes
│ └── [ 18] ./refs/remotes/origin
│ └── [ 32] ./refs/remotes/origin/HEAD
└── [ 6] ./refs/tags 16 directories, 22 files
更新时前缀英文字母A C D M G U R I的含义
A：add，新增
C：conflict，冲突
D：delete，删除
M：modify，本地已经修改
G：modify and merGed，本地文件修改并且和服务器的进行合并
U：update，从服务器更新
R：replace，从服务器替换
I：ignored，忽略
http://wuchong.me/blog/2019/02/12/how-to-become-apache-committer/
- 提Bug和提需求：Flink 使用 JIRA 来管理issue。打开 Flink JIRA 并登录，点击菜单栏中的红色 “Create“ 按钮，创建一个issue。
- 贡献代码：可以在 Flink JIRA 中寻找自己感兴趣的 issue，并提交一个 Pull Request（下文会介绍提交一个 PR 的全过程）。如果是新手，建议从 “starter” 标记的 issue 入手。笔者在 Flink 项目的第一个 issue 就是修复了打印日志中的错别字，非常适合于熟悉贡献流程，而且当天就 merge 了，成就感满满。当熟悉了流程之后，建议专注贡献某个模块（如 SQL, DataStream, Runtime)，有利于积累影响力。
- 贡献文档：文档是一个项目很重要的部分，可以在 JIRA 中寻找并解决文档类的 issue。熟悉中英文的同学可以参与贡献中文翻译，可以搜索 “chinese-translation” 的 issue。
- 代码审查：Flink 每天都会在 GitHub 上收到很多 Pull Request 。帮助 review 代码也是对社区很重要的贡献。
- 还有很多参与贡献的方式，比如帮助测试RC版本，写Flink相关的博客等等。
如何提交第一个 Pull Request
1. 订阅 dev 邮件列表
1.用自己的邮箱给 dev-subscribe@flink.apache.org 发送任意邮件。
2.收到官方确认邮件。
3.回复该邮件，内容随意，表示确认即可。
4.确认后，会收到一封欢迎邮件，表示订阅成功。
注：自2019年7月开始，经过社区讨论，将开始执行新的 JIRA workflow，不再需要去 dev 邮件列表申请 contributor 权限。
2. 在 JIRA 中挑选 issue
如果有感兴趣的 JIRA，可以直接在 JIRA 下面留言，对于复杂的 issue，需要先阐明实现方案。然后会有 Committer/PMC assign issue 给你。
推荐从简单的开始做起。例如中文翻译的issue。
3. 本地开发代码
认领了 issue 后建议尽快开始开发，本地的开发环境建议使用 IntelliJ IDEA。在开发过程中有几个注意点：
- 分支开发。 从最新的 master 分支切出一个开发分支用于 issue 开发。
- 单 PR 单改动。 不要在 PR 中混入不相关的改动，不做无关的代码优化，不做无关的代码格式化。如果真有必要，可以另开 JIRA 解决。
- 保证新代码能被单元测试覆盖到。如果原本的测试用例，无法覆盖到，则需要自己编写对应的单元测试。
4. 创建 pull request
在提交之前，先更新 master 分支，并通过 git rebase -i master
命令，将自己的提交置顶（也可以通过 IDEA > VCS > Git > Rebase 可视化界面来做
rebase）。同时保证自己的提交信息中只有一个 commit，commit message 遵循规范格式。Commit 格式是
“[FLINK-XXX] [YYY] ZZZ”，其中 XXX 是 JIRA ID，YYY 是 component 名字，ZZZ 是 JIRA
title。例如 [FLINK-5385] [core] Add a helper method to create Row object。
5. 解决 code review 反馈的问题和建议
提交 PR 后会收到修改建议，只需要为这些修改 追加commit 就行，commit message 随意。注意不要 rebase/squash commits。追加 commit 能方便地看出距离上次的改动，而 rebase/squash 会导致 reviewer 不得不从头到尾重新看一遍 diff。
6. Committer merge PR
当 PR 获得 Committer 的 +1 认可后，就可以等待被 merge 到主干分支了。merge 的工作会由 Committer 来完成，Committer 会将你的分支再次 rebase 到最新的master 之上，并将多个 commits 合并成一个，完善 commit 信息，做最后的测试检查，最后会 merge 到 master 。
比较指定的2次提交的差异，注意方向
git diff
git diff ba13a9e4688312dbce247ff6489459a53a46bd57
git diff ba13a9e4688312dbce247ff6489459a53a46bd57 eda70705953ce2e57eb7501333dc73f49a39469e
- this.$router.push({ path: "/account/index" });
+ this.$router.push({ path: "/selfinfo/info" });
git diff eda70705953ce2e57eb7501333dc73f49a39469e ba13a9e4688312dbce247ff6489459a53a46bd57
- this.$router.push({ path: "/selfinfo/info" });
+ this.$router.push({ path: "/account/index" });