止步听风的博客

远程仓库在上传的时候，添加了README.md文件，而本地没有该文件，导致本地仓库和远程仓库存在不同的commit，导致无法提交。先创建远程仓库，然后clone到本地，再进行开发远程仓库不添加README.md，如果有需要，本地新建后push到远程仓库即可。

之前已经对Git和Git的相干命令操作等做了简单地说明。但同时既然提到Git，就一定会提到GitHub。GitHub可以认为是一个代码托管平台，用户可以使用其来对自己的版本库进行管理，同时也可以参考借鉴甚至复刻他人的项目，总结来说，就是为开源代码提供版本库。在介绍GitHub之前，首先需要注册自己的账号。

Git中的钩子可以理解为一个特殊动作触发的脚本。任何时候当版本库中出现如提交或补丁等特殊事件时，都会触发执行一个或多个任意的脚本。通常情况下，一个事件会分解为多个规定好的步骤，可以为每个步骤绑定自定义脚本。当Git事件发生时，每一步开始都会调用相应的脚本。钩子只属于并作用于一个特定的版本库，在克隆操作中不会复制。换句话说，在私有版本库中设置的钩子不会传送到新克隆的版本库，也就不会改变新克隆的仓库的行为。而如果真的有需要的话，则需要获取被克隆版本库的.git/hooks目录。

Git实现了自己的传输协议用于版本库间交换数据。出于效率方面的考虑(为了节约时间和空间)，Git传输协议会进行握手，以确定原版本库中的哪些提交不在目标版本库中，最终传输提交的二进制压缩形式。接收的版本库会给新的提交合并到其本地历史记录中，同时添加到提交图中，并按需要更新分支和标签。之前提到，要交换提交并保持分布式版本库同步，可以使用Git原生协议和HTTP协议。但在很多情况下使用这些协议是不可行的，Git还支持补丁操作，通常通过email来进行数据交换。

本文主要说明如何发布Git仓库。

之前提到的Git的所有操作都是在本地完成的，而实际项目开发并不是一个人就可以搞定的，通常需要团队的协作，而这些协作可能又不是在同一个地区的，这就涉及到Git的分布式特性了。Git的分布式特定会涉及到克隆(clone)的概念，每个克隆都是版本库的副本，其包含所有的原始对象，同时每个克隆都是独立的，可以在本地独立地工作，这也是Git分布式协作的基础。克隆只是共享代码的前提，还必须为这些版本库之间进行关联，为数据交换建立连接，Git是通过远程版本库完成版本库的连接的。...

在开发中，若使用分支和提交机制模拟中断处理机制，整个过程就是创建临时分支，检出到该分支，然后提交所有未完成的修改，回到主分支，进行紧急处理，然后检出之前的临时分支，继续中断的操作。虽然Git针对引用支持大量的日期限定符，但其并不是万能的，这有点像是字符串的规则匹配，当你的字符串符合其内容的匹配规则时，就可以成功解析，换言之，若想要正常使用而不出错，最好还是有一个固定的书写风格。通常情况下，一个提交，如果既不能从某个分支或引用指向，也不可达，就默认在30天后国企，而可达的提交默认在90天后过期。...

Git中的提交会记录工作历史记录，并且保证所有的更改都是正式有效的，但是该提交本身却不是不可修改的。Git中的提交可以进行更改，以便修改完善版本库中的提交。一般来说，只要没有其它人已经获得了你的版本库的副本，你就可以自由修改和完善版本库提交历史记录。相反，如果一个分支已经发布供他人获取了，并且可能已经存在于其它版本库中了，那么你就不应该重写，修改或更改该分支的任何部分。git reset命令会把版本库和工作目录改变为目录状态。也就是说，git reset调整HEAD引用指向给定的提交，默认情况下还会更新索引

之前提到了分支，既然有分，就一定有合。在Git中，当一个分支中的修改与另一个分支中的修改不发生冲突的时候，Git会计算合并结果，并创建一个新提交来代表新的统一状态。但是当分支冲突时，Git并不解决冲突，而将该文件在索引中标记为未合并的(unmerged)，交给用户处理，用户处理完冲突后，才能够进行最终提交。首先执行下列代码初始化版本库：在上面的代码中，在master分支外创建了other分支，并进行了两次提交，然后如果想要将other分支合并到master分支上的话，就需要使用到git merge命令

Git中的diff命令可以显示文件之间的差异，同时-r选项可以遍历两个树对象，同时显示它们的差异。从Git中的对象类型上看，一个树对象值只代表版本库中的一个目录层级，它包含该目录下的直接文件和它的所有直接子目录的信息，但不包括所有子目录的完整内容。而树对象引用所有子目录的树对象，所以对应项目根目录的树对象实际上代表某个时刻的整个项目，因此也可以说，git diff遍历两棵树。存在三个可供树或类树对象使用git diff命令的基本来源：通常情况下，git diff命令进行树的比较时可以通过提交名，分支名或标签

实际开发中，会在当前开发线路上拉出另外的开发线进行开发，比如软件功能已经比较稳定的话，在后续功能的开发过程中，就很可能会拉出独立的支线进行开发，待功能开发完毕后，再将该直线合入稳定的主线中。当然实际开发中，会有不同的分支策略，这就需要使用到Git的分支。分支是开发中启动一条单独的开发线的基本方法，使开发过程能够在多个方向上同时进行，并可能产生项目的不同版本。版本库中的默认分支名称为master，大多数开发人员在该分支上保持版本库中最强大和最可靠的开发线。同时Git还支持给分支命名，分支命名需要遵守一些规则：

在Git中，提交是用来记录版本库的变更的。当提交时，Git会记录索引的快照并将快照放进对象库，该快照不包含该索引中任何文件或记录中的副本。Git会将当前索引的状态与之前的快照做一个比较，并派生出一个受影响的文件和目录列表，并会为任何有变化的文件创建新blob对象，对有变化的目录创建新的树对象，对于未改动的文件和目录则会沿用之前的blob与树对象。提交的快照是串联到一起的，每张新的快照指向其前驱，随着时间的推移，一系列变更就表示为一系列提交。版本库中的变更和提交时一一对应的关系，提交则是将变更引入版本库的唯一

之前提到，Git的操作结束后需要提交才会真正起作用。这是因为Git在工作目录和版本库之间加了一层索引，用来暂存(stage)，收集或修改。这也是其它文章称工作目录和版本库中间的一层为暂存区的原因。当使用Git进行代码管理时，工作目录进行编辑，索引中积累更改，然后将索引中的修改一次性提交到版本库。Git中的索引不包含任何文件内容，它只追踪想要提交的内容。即当执行git commit命令时，Git会检查索引而不是工作目录来找到提交的内容。在任何时候都可以通过git status命令查看索引的状态，该命令会列出哪

Git版本库(repository)只是一个简单的数据库，其中包括所有用来维护与管理项目的修订版本和历史信息。而Git版本不仅会维护项目整个生命周期的完整副本，还会提供版本库本身的副本。之前也提到，Git在版本库中会维护一组配置值，而这些配置值并不会在clone版本库的时候进行clone，相反Git还会对每个网站，每个用户和每个版本库的配置和设置信息进行管理和检查。在版本库中，Git会维护两个主要的数据结构：对象库(object store)和索引(index)，所有这些版本库数据都存放在工作目录下的.gi

在大型项目开发或者多人协作开发时，都希望可以对软件代码进行管理和追踪，以便确认开发的进度和方便问题追溯。这就需要使用到版本控制系统(VCS)，比如Git就是一款很优秀的版本控制工具。如今很多项目都在使用Git进行版本控制，这也是该类工具发展到现在的结果。除了VCS，这类工具可能还有其它的名字，如源代码管理器(SCM)，修订控制系统(RCS)等。当然该类工具也不止Git一种，另外还有BitKeeper，SVN等。如果之前没有接触过其它工具的话，可以在直接使用Git进行代码管理。重要的是，Git是开源的。Git