共计 4406 个字符，预计需要花费 12 分钟才能阅读完成。
版本控制
什么是版本控制
版本控制是一种记录一个或若干文件内容变动，以便未来查阅特定版本订正状况的零碎。除了我的项目源代码，你能够对任何类型的文件进行版本控制。
为什么要版本控制
有了它你就能够将某个文件回溯到之前的状态，甚至将整个我的项目都回退到过来某个工夫点的状态，你能够比拟文件的变动细节，查出最初是谁批改了哪个中央，从而找出导致怪异问题呈现的起因，又是谁在何时报告了某个性能缺点等等。
本地版本控制系统
许多人习惯用复制整个我的项目目录的形式来保留不同的版本，或者还会改名加上备份工夫以示区别。这么做惟一的益处就是简略，然而特地容易犯错。有时候会混同所在的工作目录，一不小心会写错文件或者笼罩意想外的文件。
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采纳某种简略的数据库来记录文件的历次更新差别。
集中化的版本控制系统
接下来人们又遇到一个问题，如何让在不同零碎上的开发者协同工作？于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。
集中化的版本控制系统都有一个繁多的集中管理的服务器，保留所有文件的订正版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
这么做尽管解决了本地版本控制系统无奈让在不同零碎上的开发者协同工作的诟病，但也还是存在上面的问题：
- 单点故障： 地方服务器宕机，则其他人无奈应用；如果核心数据库磁盘损坏有没有进行备份，你将失落所有数据。本地版本控制系统也存在相似问题，只有整个我的项目的历史记录被保留在繁多地位，就有失落所有历史更新记录的危险。
- 必须联网能力工作： 受网络情况、带宽影响。
分布式版本控制系统
于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。Git 就是一个典型的分布式版本控制系统。
这类零碎，客户端并不只提取最新版本的文件快照，而是把代码仓库残缺地镜像下来。这么一来，任何一处协同工作用的服务器产生故障，预先都能够用任何一个镜像进去的本地仓库复原。因为每一次的克隆操作，实际上都是一次对代码仓库的残缺备份。
分布式版本控制系统能够不必联网就能够工作，因为每个人的电脑上都是残缺的版本库，当你批改了某个文件后，你只须要将本人的批改推送给他人就能够了。然而，在理论应用分布式版本控制系统的时候，很少会间接进行推送批改，而是应用一台充当“地方服务器”的货色。这个服务器的作用仅仅是用来不便“替换”大家的批改，没有它大家也一样干活，只是替换批改不不便而已。
分布式版本控制系统的劣势不单是不用联网这么简略，前面咱们还会看到 Git 极其弱小的分支治理等性能。
意识 Git
Git 简史
Linux 内核项目组过后应用分布式版本控制系统 BitKeeper 来治理和保护代码。然而，起初开发 BitKeeper 的商业公司同 Linux 内核开源社区的单干关系完结，他们发出了 Linux 内核社区收费应用 BitKeeper 的势力。Linux 开源社区（特地是 Linux 的缔造者 Linus Torvalds）基于应用 BitKeeper 时的经验教训，开发出本人的版本零碎，而且对新的版本控制系统做了很多改良。
Git 与其余版本管理系统的次要区别
Git 在保留和看待各种信息的时候与其它版本控制系统有很大差别，只管操作起来的命令模式十分相近，了解这些差别将有助于避免你应用中的困惑。
上面咱们次要说一个对于 Git 其余版本管理系统的次要差异：看待数据的形式。
Git 采纳的是间接记录快照的形式，而非差别比拟。我前面会具体介绍这两种形式的差异。
大部分版本控制系统（CVS、Subversion、Perforce、Bazaar 等等）都是以文件变更列表的形式存储信息，这类零碎 将它们保留的信息看作是一组根本文件和每个文件随工夫逐渐累积的差别。
具体原理如下图所示，了解起来其实很简略，每个咱们对提交更新一个文件之后，零碎记录都会记录这个文件做了哪些更新，以增量符号 Δ(Delta)示意。
咱们怎样才能失去一个文件的最终版本呢？
很简略，高中数学的基本知识，咱们只须要将这些原文件和这些减少进行相加就行了。
这种形式有什么问题呢？
比方咱们的增量特地特地多的话，如果咱们要失去最终的文件是不是会消耗工夫和性能。
Git 不依照以上形式看待或保留数据。反之，Git 更像是把数据看作是对小型文件系统的一组快照。每次你提交更新，或在 Git 中保留我的项目状态时，它次要对过后的全副文件制作一个快照并保留这个快照的索引。为了高效，如果文件没有批改，Git 不再从新存储该文件，而是只保留一个链接指向之前存储的文件。Git 看待数据更像是一个 快照流。
Git 的三种状态
Git 有三种状态，你的文件可能处于其中之一：
- 已提交（committed）：数据曾经平安的保留在本地数据库中。
- 已批改（modified）：已批改示意批改了文件，但还没保留到数据库中。
- 已暂存（staged）：示意对一个已批改文件的以后版本做了标记，使之蕴含在下次提交的快照中。
由此引入 Git 我的项目的三个工作区域的概念：Git 仓库 (.git directoty)、 工作目录 (Working Directory) 以及 暂存区域(Staging Area)。
根本的 Git 工作流程如下：
- 在工作目录中批改文件。
- 暂存文件，将文件的快照放入暂存区域。
- 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。
Git 应用疾速入门
获取 Git 仓库
有两种获得 Git 我的项目仓库的办法。
- 在现有目录中初始化仓库: 进入我的项目目录运行
git init命令, 该命令将创立一个名为.git的子目录。 - 从一个服务器克隆一个现有的 Git 仓库:
git clone [url]自定义本地仓库的名字:git clone [url]directoryname
记录每次更新到仓库
- 检测以后文件状态 :
git status - 提出更改（把它们增加到暂存区）：
git add filename(针对特定文件)、git add *(所有文件)、git add *.txt（反对通配符，所有 .txt 文件） - 疏忽文件：
.gitignore文件 - 提交更新:
git commit -m "代码提交信息"（每次筹备提交前，先用git status看下，是不是都已暂存起来了，而后再运行提交命令git commit） - 跳过应用暂存区域更新的形式 :
git commit -a -m "代码提交信息"。git commit加上-a选项，Git 就会主动把所有曾经跟踪过的文件暂存起来一并提交，从而跳过git add步骤。 - 移除文件：
git rm filename（从暂存区域移除，而后提交。） - 对文件重命名：
git mv README.md README(这个命令相当于mv README.md README、git rm README.md、git add README这三条命令的汇合)
一个好的 Git 提交音讯
一个好的 Git 提交音讯如下：
题目行：用这一行来形容和解释你的这次提交
主体局部能够是很少的几行，来退出更多的细节来解释提交，最好是能给出一些相干的背景或者解释这个提交能修复和解决什么问题。主体局部当然也能够有几段，然而肯定要留神换行和句子不要太长。因为这样在应用 "git log" 的时候会有缩进比拟难看。提交的题目行形容应该尽量的清晰和尽量的一句话概括。这样就不便相干的 Git 日志查看工具显示和其他人的浏览。
推送改变到近程仓库
- 如果你还没有克隆现有仓库，并欲将你的仓库连贯到某个近程服务器，你能够应用如下命令增加：·
git remote add origin <server>, 比方咱们要让本地的一个仓库和 Github 上创立的一个仓库关联能够这样git remote add origin https://github.com/Snailclimb/test.git - 将这些改变提交到远端仓库：
git push origin master(能够把 master 换成你想要推送的任何分支)如此你就可能将你的改变推送到所增加的服务器下来了。
近程仓库的移除与重命名
- 将 test 重命名位 test1：
git remote rename test test1 - 移除近程仓库 test1:
git remote rm test1
查看提交历史
在提交了若干更新，又或者克隆了某个我的项目之后，你兴许想回顾下提交历史。实现这个工作最简略而又无效的工具是 git log 命令。git log 会按提交工夫列出所有的更新，最近的更新排在最下面。
能够增加一些参数来查看本人心愿看到的内容：
只看某个人的提交记录：
git log --author=bob撤销操作
有时候咱们提交完了才发现漏掉了几个文件没有增加，或者提交信息写错了。此时，能够运行带有 --amend 选项的提交命令尝试从新提交：
git commit --amend勾销暂存的文件
git reset filename吊销对文件的批改:
git checkout -- filename如果你想抛弃你在本地的所有改变与提交，能够到服务器上获取最新的版本历史，并将你本地主分支指向它：
git fetch origin
git reset --hard origin/master分支
分支是用来将个性开发绝缘开来的。在你创立仓库的时候，master 是“默认的”分支。在其余分支上进行开发，实现后再将它们合并到主分支上。
咱们通常在开发新性能、修复一个紧急 bug 等等时候会抉择创立分支。单分支开发好还是多分支开发好，还是要看具体场景来说。
创立一个名字叫做 test 的分支
git branch test切换以后分支到 test（当你切换分支的时候，Git 会重置你的工作目录，使其看起来像回到了你在那个分支上最初一次提交的样子。Git 会主动增加、删除、批改文件以确保此时你的工作目录和这个分支最初一次提交时的样子截然不同）
git checkout test
你也能够间接这样创立分支并切换过来(下面两条命令的合写)
git checkout -b feature_x切换到主分支
git checkout master合并分支(可能会有抵触)
git merge test把新建的分支删掉
git branch -d feature_x将分支推送到远端仓库（推送胜利后其他人可见）：
git push origin 举荐
在线演示学习工具：
「补充，来自 issue729」Learn Git Branching https://oschina.gitee.io/learn-git-branching/。该网站能够不便的演示根本的 git 操作，解说得明明白白。每一个根本命令的作用和后果。
举荐浏览：
- Git – 扼要指南
- 图解 Git
- 猴子都能懂得 Git 入门
- https://git-scm.com/book/en/v2
- Generating a new SSH key and adding it to the ssh-agent
- 一个好的 Git 提交音讯，出自 Linus 之手
