共计 2658 个字符，预计需要花费 7 分钟才能阅读完成。
最近想写一篇 git 的向导，因为 git 的应用形式非常灵活，每个人对 git 也有不同的应用偏好，所以写一下本人的教训还是很值得的。另外，当初总结一下应用教训，今后发展我的项目能够做到有恃无恐。依据我的总结，git 还是有不少货色值得写的，所以想把我写的货色分成几块，有个前后程序。这是第一篇，介绍一下根本的入门常识，再讲讲 git 的整体构造是什么样的。Let’s go!
什么是 git
git 是一个用于软件开发的代码 版本控制系统。它有以下特点：
- 分布式：git 不依赖于集中的版本控制服务器，不同的用户创立本人的库后，能够自在地在其根底上做版本治理
- 收费开源
git repositories 的空间视角
总的来说，git repository 是一个简单的数据结构，开发者须要对整体有一个根本的理解。我倡议把工作中应用的 git repository 看作一个三维的空间。上面就来说一下 git 空间的三个维度。
第一维度：commit history
commit 是一次代码提交，它实现版本治理最根底的性能 —— 把批改历史划分为不同的版本。它也是 git 在切换不同版本时的最小单位。咱们平时写代码时，每一次写完一个残缺的代码逻辑，就能够做一次代码提交。每一次提交都要确保达到以下要求：
- 我的项目能够编译胜利
- 未实现的局部能显示正当的提醒或者抛出
NotImplementedException之类的异样
第二维度：branch
branch 是代码的正本，服务于团队开发中不同的开发者专一于各自的工作工作。除了默认的 master 分支，咱们在创立分支时都会基于一个原有的分支进行拷贝，创立实现后，新分支也保留了原有分支的 commit hostory。
第三维度：remote
和你的本地库产生关联的近程库叫 remote。咱们常常应用 git clone 命令去拷贝他人的代码，这个命令生成的本地库就带有 remote 信息。能够应用 git remote -v 查看以后库的 remote 的详细信息。尽管 git 是分布式的，然而发展团队开发工作时通常还是把 repository 分为“团队的库”和“本人的库”，另外，团队还会应用 Github 这样的代码托管服务。通常的团队开发中，每个开发者（对于同一个我的项目）会用到三个库，两个近程的，一个本地的。上面阐明一下这三个库：
| 简称 | remote 主机名 | host 在哪里 | 用处 |
|---|---|---|---|
| 本人的本地库 | – | 开发者本地 | 进行本地开发和调试，解决代码合并时的抵触 |
| 本人的近程库 | origin | github 之类的代码托管服务 | 代码近程存储，更便捷地应用托管服务的 Pull Request 等性能 |
| 团队的近程库 | upstream | github 之类的代码托管服务 | 治理产品源代码，治理开发迭代中的代码，代码权限治理 |
产品开发过程中，代码的流向应该是这样的：
解释一下上图中的步骤：
- local -> origin：个别是筹备提交到团队库之前就先提交到 origin，或者是须要近程备份本人的代码时这么做。这里的虚线是从本人的近程备份下载代码时这么做。
- origin -> upstream：提交 Rull Request 时这样操作。
- upstream -> local：须要从团队库更新代码时这样做。我的习惯是间接 pull（信赖团队的代码是牢靠的），就不分步 fetch 和 merge 了。
这样就造成了图中所示的逆时针工作流。
间接把团队库当成 origin 岂不更好？ 这样只是看上去简略，对团队整体而言是不好的。团队的库是要做权限治理的，不宜把团队库的某个分支当作“本人的近程库”。
{: .notice–info}
基于以上的空间划分，git 的空间视角应该是这样的：
图中的每个圆点代表一个 commit，每个横向的直线 + 箭头代表一个分支，每一个立体代表一个 repository 正本。（图中的虚线没有实际意义，只是为了看上去像是平面的）
应用 checkout 命令在 git 空间中“穿梭”
checkout 命令有很多用法，最次要的有两个：在不同的分支间切换；在不同的 commit 状态间切换。前者是基本操作，后者显得高级一点。这里次要说一下后者，因为在 commit 间切换使 git 用法更加灵便，但容易遇到问题。开发者每次提交之后，生成的 commit 都有一个对应的 SHA-1 哈希值（通过 git log 或图形化工具也能拿到这个值），通过应用 git checkout 前面加上这个哈希值就能实现在 commit 之间切换，像上面这样：
git checkout dc3966be219e95abe2b098858e1ef4dd79f4b84d这样应用 checkout 命令会让 git 处于 detached HEAD 状态，字面意思看，是“脑袋错位了”。开发者要留神，如果你处于 detached HEAD 状态，肯定是为了查看某个 commit 后状态的代码（或在此基础上做调试），查看完之后肯定要通过“某种形式”还原到失常状态，否则可能会出问题。说到这里，有几个事件必须解释一下：
- 什么是 HEAD？HEAD 是一个指针，它指向目前你本地文件所处的状态。咱们能够把 commit history 看作一个链表，每个 commit 是链表上的一个节点，开发者本地文件的状态必然是处于某一个节点上，HEAD 正是指向这个节点。失常状态下 HEAD 总是处于这个链表的最初一个节点。
- 什么是 detached HEAD？ 当咱们执行 checkout 命令且把哈希值作为参数切换到某个 commit 之后的状态时，HEAD 就不再指向“失常”的地位了，这种状态就是 detached HEAD。
- 上文中提到的“某种形式”是什么？ 为了回到失常状态，你有两种抉择：1. 应用
git checkout [branchName]回到某个分支；2. 在以后的 commit 状态下建一个新的分支，应用git checkout -b [newBranchName]。 - 不从 detached HEAD 状态切换回失常状态会导致什么问题？ 处于 detached HEAD 状态下也能够提交新的 commit，如果开发者在这种状态下提交新的 commit，commit history 这个链表就分叉了！如果开发者对眼前的状态不是很分明，可能会把本人要提交的内容弄丢。
这篇就先写到这儿，次要是想说一下“如何看 git”。一些代码提交、批改的常识比拟系统，筹备放在今后的文章里写，目前来看，还有以下几篇是今后要写的：
- 图形化辅助工具
- 代码的提交 / 合并
- 团队应用标准
最初再举荐一篇攻略，我感觉这篇借助图形讲得十分好：A Visual Git Reference
感谢您的浏览，欢送提出您的认识。
此文的原文链接：git 经验谈（一）：意识 git 的构造
