小结：

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 工作流程如下：

1. 在工作目录中修改某些文件。
2. 对修改后的文件进行快照，然后保存到暂存区域。
3. 提交更新，将保存在暂存区域的文件快照永久转储到 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/

3. 提Bug和提需求：Flink 使用 JIRA 来管理issue。打开 Flink JIRA 并登录，点击菜单栏中的红色 “Create“ 按钮，创建一个issue。
4. 贡献代码：可以在 Flink JIRA 中寻找自己感兴趣的 issue，并提交一个 Pull Request（下文会介绍提交一个 PR 的全过程）。如果是新手，建议从 “starter” 标记的 issue 入手。笔者在 Flink 项目的第一个 issue 就是修复了打印日志中的错别字，非常适合于熟悉贡献流程，而且当天就 merge 了，成就感满满。当熟悉了流程之后，建议专注贡献某个模块（如 SQL, DataStream, Runtime)，有利于积累影响力。
5. 贡献文档：文档是一个项目很重要的部分，可以在 JIRA 中寻找并解决文档类的 issue。熟悉中英文的同学可以参与贡献中文翻译，可以搜索 “chinese-translation” 的 issue。
6. 代码审查：Flink 每天都会在 GitHub 上收到很多 Pull Request 。帮助 review 代码也是对社区很重要的贡献。
7. 还有很多参与贡献的方式，比如帮助测试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" });