全栈必备：Git
DoyDanielso
8年前
<h2><strong>为什么使用Git</strong></h2> <p>Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。大神就是大神，在开发了Linux之后，Git 是又一抗鼎之作。这是唯一的理由么？</p> <h2><strong>Git在软件开发中位置——配置管理SCM</strong></h2> <p>Software configuration management (SCM, or just plain CM) is an organizational framework — that is, a discipline — for managing the evolution of computer systems throughout all stages of systems development.</p> <p>软件配置管理:通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置资源的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。没有软件配置管理，最大的麻烦是工作成果无法回溯。</p> <h3><strong>配置管理的内容和目标</strong></h3> <p>配置管理的内容：</p> <p>一类是属于产品的组成部分，例如需求文档、设计文档、源代码、测试用例等等；</p> <p>另一类是在管理过程中产生的文档，例如各种计划、报告等</p> <p>软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。它的基本目标包括：</p> <p>1. 软件配置管理的各项工作是有计划进行的。</p> <p>2. 被选择的项目产品得到识别，控制并且可以被相关人员获取。</p> <p>3. 已识别出的项目产品的更改得到控制。</p> <p>4. 使相关组别和个人及时了解软件基准的状态和内容。</p> <h3>配置管理的主要任务</h3> <p>软件配置管理的主要任务也就归结为以下几条：</p> <p>（1）制定项目的配置计划；</p> <p>（2）对配置项进行标识；</p> <p>（3）对配置项进行版本控制；</p> <p>（4）对配置项进行变更控制；</p> <p>（5）定期进行配置审计；</p> <p>（6）向相关人员报告配置的状态。</p> <h2><strong>版本控制</strong></h2> <p>版本控制是软件配置管理的核心功能。所有位于配置资源库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。</p> <p>版本控制(Revision control)确保由不同人所编辑的同一档案都得到更新。</p> <h3><strong>版本控制中的基本概念</strong></h3> <p>1）签入，提交，检出</p> <p>2）冲突，解决，合并</p> <p>3）分支，版本</p> <p>4）锁定，hook</p> <h3><strong>常见的版本控制工具</strong></h3> <p>作为一个老码农，枚举一下曾经使用过的版本控制工具。</p> <p>1. VSS： visual source safe, 微软的东东，97年写VC程序时使用，人多的时候性能较差，不知道现在的升级版怎样了</p> <p>2. clearcase： 99年开发Unix 上分布式式应用时使用，功能强大，不只限于版本控制，有钱的大团队才去用</p> <p>3. CVS: 02年在互联网热潮的时候使用，开源产品，当时“Copy-Modify-Merge”开发模型眼前一亮。</p> <p>4. SVN：曾经的挚爱，在曾工作的合资公司使用，权限管理和分支合并等方面做的很出色，并在多个公司推广使用。还记得TortoiseSVN么?那只可爱的小乌龟。</p> <p>5. perforce:是一款具有轻便快速的SCM工具、真正的客户端/服务器系统等特点的商业软件。高通内部使用的版本管理工具。确实不错。</p> <p>6. git：现在的最爱……</p> <p>比较一下cvs,svn,和git：</p> <p><img src="https://simg.open-open.com/show/8aa4b79db48786a30b5fa6f12121e848.png"></p> <h2><strong>Git 简要</strong></h2> <p>GIT 是一款免费的、开源的、分布式的版本控制系统。每一个GIT克隆都是一个完整的文件库，含有全部历史记录和修订追踪能力。其最大特色就是“分支”及“合并”操作快速、简便。支持离线工作，GIT是整个项目范围的原子提交，而且GIT中的每个工作树都包含一个具有完整项目历史的仓库。</p> <h2><strong>核心特点：</strong></h2> <ol> <li> <p>Git 底层自行维护的存储文件系统：存储的是文件快照，即整个文件内容，并保存指向快照的索引</p> </li> <li> <p>去中心化的分布式控制</p> </li> </ol> <h2><strong>优缺点：</strong></h2> <p>优点：</p> <ul> <li> <p>适合分布式开发，强调个体。</p> </li> <li> <p>公共服务器压力和数据量都不会太大， 速度快、灵活。</p> </li> <li> <p>任意两个开发者之间可以很容易的解决冲突。</p> </li> <li> <p>离线工作。</p> </li> </ul> <p>缺点：</p> <ul> <li> <p>学习周期相对而言比较长。</p> </li> <li> <p>不符合常规思维。</p> </li> <li> <p>代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。</p> </li> </ul> <h2><strong>Git 原理</strong></h2> <h2><strong>Git的目录结构</strong></h2> <p>不论通过git init 还是克隆下来的git 仓库，都有如下的目录结构：</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/d3b7904f52d15764cf80675b240d43d4.png"></p> <p>主要目录结构描述见下表：</p> <table> <tbody> <tr> <th>子目录名</th> <th>简要描述</th> </tr> <tr> <th>branches</th> <th>Git 项目分支信息，新版 Git 已经不再使用该目录</th> </tr> <tr> <th>config</th> <th>Git 项目配置信息</th> </tr> <tr> <th>description</th> <th>Git 项目描述信息</th> </tr> <tr> <th>HEAD</th> <th>指向 Git 项目当前分支的头指针</th> </tr> <tr> <th>hooks</th> <th>默认的”hooks”脚本，被特定事件发生前后触发。</th> </tr> <tr> <th>info</th> <th>里面含一个 exclude 文件，指 Git 项目要忽略的文件。</th> </tr> <tr> <th>objects</th> <th>Git 的数据对象，包括：commits, trees, blobs, tags。</th> </tr> <tr> <th>refs</th> <th>指向所有 Git 项目分支的指针</th> </tr> </tbody> </table> <p>所有的分支指针保存在 .git/refs/heads 目录下，HEAD 在 .git/HEAD 目录下，标签在 .git/refs/tags 目录下。</p> <h2><strong>快照</strong></h2> <p>例如： 一个工程中有两个文件A和B， 有3个版本:</p> <p>V1.0 A和B，V1.5 A1和B，V2.0 A1和B1</p> <p>在Git 的实际存储中实际存了3个快照 4个文件。</p> <p>Git对文件进行 SHA-1 计算作为文件的唯一ID，并校验了文件完整性。</p> <p>SHA-1 算法将文件中的内容通过计算生成一个 40 位的 Hash 值。SHA-1 算法的特点：</p> <p>由文件内容计算出的 Hash 值；Hash 值相同，文件内容相同。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/4d0ff9b1c41ae20d079bc9808b08e648.png"></p> <p>使用 SHA-1 的前两位创建了文件夹，剩下的 38 位为文件名。</p> <p>这些 Obj 文件，其实分为四种类型，分别是 Blob、Tree、Commit、Tag。</p> <h3><strong>Blob</strong></h3> <p>用来存放项目文件的内容，但是不包括文件的路径、名字、格式等其它描述信息。项目的任意文件的任意版本都是以 Blob 的形式存放的。</p> <h3><strong>Tree</strong></h3> <p>Tree 用来表示目录。我们知道项目就是一个目录，目录中有文件、有子目录。因此 Tree 中有 Blob、子 Tree，且都是使用 SHA-1值引用的。这是与目录对应的。从顶层的 Tree 纵览整个树状的结构，叶子结点就是 Blob，表示文件的内容，非叶子结点表示项目的目录，顶层的 Tree 对象就代表了当前项目的快照。</p> <h3><strong>Commit</strong></h3> <p>表示一次提交，有 Parent 字段，用来引用父提交。指向了一个顶层 Tree，表示了项目的快照，还有一些其它的信息，比如上一个提交 Committer、Author、Message 等信息。</p> <h2><strong>存储区</strong></h2> <p>Git中有4个类型的存储区：远程仓库，工作区，本地仓库和缓存区。</p> <p>暂存区的好处：</p> <ol> <li> <p>为了能够实现部分提交</p> </li> <li> <p>为了不在工作区创建状态文件、会污染工作区。</p> </li> <li> <p>暂存区记录文件的修改时间等信息，提高文件比较的效率。<br> 暂存区是用来构建项目快照的区域。暂存区是一个文件，路径为： .Git/index</p> </li> </ol> <p style="text-align: center;"><img src="https://simg.open-open.com/show/7445e469d62af906d282ac7906a9d38a.png"></p> <p>它是一个二进制文件，第四列是文件名，第三列是文件的冲突状态，第二列指的是文件的 Blob。</p> <p>Commit 命令，将暂存区的内容永久保存到本地仓库。提交时 Git 会使用暂存区的这些信息生成 Tree 对象，也就是项目快照，永久保存到数据库中。</p> <p>文件的状态可以分为两类。一类是暂存区与本地仓库比较得出的状态，另一类是工作区与暂存区比较得出的状态。为什么要分成两类的愿意也很简单，因为第一类状态在提交时，会直接写入本地仓库。而第二种则不会。一个文件可以同时拥有两种状态。</p> <h2><strong>分支</strong></h2> <p>分支的目的是让我们可以并行的进行开发。 .Git/HEAD 文件，它保存了当前的分支。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/871c57960001d5494bb3643f727e92b5.png"></p> <p>分支指向了一次提交，也是 Git 中的分支为什么这么轻量的原因。</p> <p>因为分支就是指向了一个 Commit 的指针，当提交新的 Commit，这个分支的指向只需要跟着更新就可以了，而创建分支仅仅是创建一个指针。</p> <h2><strong>Git 必备技能</strong></h2> <h2><strong>常见命令速查</strong></h2> <p><img src="https://simg.open-open.com/show/aaf60108cef2ffbf10018944f7097885.png"></p> <h2><strong>git add 和 git commit</strong></h2> <p>Add 操作是将修改保存到暂存区，Commit 是将暂存区的内容永久保存到本地仓库。</p> <p>每当将修改的文件加入到暂存区，Git 都会根据文件的内容计算出 SHA-1，并将内容转换成 Blob，写入数据库。然后使用 SHA-1 值更新该列表中的文件项。</p> <p>在暂存区的文件列表中，每一个文件名，都会对应一个 SHA-1 值，用于指向文件的实际内容。最后提交的那一刻，Git 会将这个列表信息转换为项目的快照，也就是 Tree 对象。写入数据库，并再构建一个 Commit 对象，写入数据库。然后更新分支指向。</p> <h2><strong>分支合并: merge 和rebase</strong></h2> <p>冲突的状态</p> <ul> <li>DELETED_BY_THEM;</li> <li>DELETED_BY_US;</li> <li>BOTH_ADDED;</li> <li>BOTH_MODIFIED</li> </ul> <p>遇到不可自动合并冲突时，Git 会将这些状态写入到暂存区。</p> <h3><strong>merge</strong></h3> <p>在解决完冲突后，我们可以将修改的内容提交为一个新的提交。这就是 Merge。</p> <p>Merge 之后仍可以做出新的提交。</p> <p><img src="https://simg.open-open.com/show/c1aad161b2156ef8cdf3d7e3f3145e92.png"></p> <h3><strong>rebase</strong></h3> <p>Rebase 会把从 Merge Base 以来的所有提交，以补丁的形式一个一个重新达到目标分支上。这使得目标分支合并该分支的时候会直接 Fast Forward，即不会产生任何冲突。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/a8aa515ecea1c69efb4c9a1608555e83.png"></p> <p>Rebase 主要在 .Git/Rebase-Merge 下生成了两个文件，分别为 Git-Rebase-todo 和 Done 文件，Git-Rebase-todo 存放了 Rebase 将要操作的 Commit。而 Done 存放正在操作或已经操作完毕的 Commit。</p> <p>Rebase 的一个缺点，那就是修改了分支的历史提交。如果已经将分支推送到了远程仓库，会导致无法将修改后的分支推送上去，必须使用 -f 参数（Force）强行推送。</p> <p>所以使用 Rebase 最好不要在公共分支上进行操作。</p> <h3><strong>checkout</strong></h3> <p>经常用来切换分支、或者切换到某一次提交。</p> <p>Checkout 找到目标提交（Commit），目标提交中的快照也就是 Tree 对象就是我们要检出的项目版本。</p> <p>Checkout 首先根据Tree生成暂存区的内容，再根据 Tree 与其包含的 Blob 转换成我们的项目文件。然后修改 HEAD 的指向，表示切换分支。</p> <p>Checkout 并没有修改提交的历史记录。只是将对应版本的项目内容提取出来。</p> <h3><strong>revert</strong></h3> <p>revert 实现了反向提交，就是旧版本添加了的内容，要在新版本中删除；旧版本中删除了的内容，要在新版本中添加。这在分支已经推送到远程仓库的情境下非常有用。</p> <p>Revert 也不会修改历史提交记录，实际的操作相当于是检出目标提交的项目快照到工作区与暂存区，然后用一个新的提交完成版本的“回退”。</p> <h3><strong>reset</strong></h3> <p>在当前分支进行版本的“回退”，Reset 是会修改历史提交记录的。</p> <p>Reset 常用的选项有三个，分别是 —Soft, —Mixed, —Hard。他们的作用域依次增大。</p> <p>Soft 会仅仅修改分支指向。而不修改工作区与暂存区的内容，</p> <p>Mixed 比 Soft 的作用域多了一个 暂存区。实际上 Mixed 选项与 Soft 只差了一个 Add 操作。</p> <p>Hard 会比 Mixed作用域又多了一个工作区。</p> <p>注意：在丢失后可以使用 Git Reset –Hard ORIG_HEAD 立即恢复，或者使用 reflog 命令查看之前分支的引用</p> <h3><strong>stash</strong></h3> <p>有时，在一个分支上做了一些工作，修改了很多代码，而这时需要切换到另一个分支干点别的事。但又不想将只做了一半的工作提交。</p> <p>Stash 将工作区与暂存区中的内容做一个提交，保存起来，然后使用Reset Hard 选项恢复工作区与暂存区内容。我们可以随时使用 Stash Apply 将修改应用回来。</p> <p>Stash 实现思路将我们的修改提交到本地仓库，使用特殊的分支指针（.Git/refs/Stash）引用该提交，然后在恢复的时候，将该提交恢复即可。</p> <h2><strong>Git 典型实践</strong></h2> <p>一个典型的git 并行开发的流程模型如下：</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/4bf7e68c49e29c353a01bd6b782a1be3.png"></p> <h2><strong>主要分支</strong></h2> <p>把origin/master作为主要分支，源码的HEAD总是表示production-ready(可随时部署)状态。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/554f4577fd87859c7d7ae840f05c3416.png"></p> <p>origin/develop上的代码是为下一次的代码发布准备的。每日构建也是基于此分支。</p> <p>当develop分支达到了一个稳定状态并准备发布时，所有的改变都要合并到master分支，并标上版本号。</p> <h2><strong>辅助分支</strong></h2> <h3><strong>Feature branches</strong></h3> <p>继承与合并都与develop 分支相关，用来开发新特性的(短期，远期都可以)。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/da62ac4baa44ce986ec8a8e89d487317.png"></p> <p>当要创建一个新特性时，从develop分支上再创建一个 Feature branch。</p> <p>$ git checkout -b myfeature develop</p> <p>合并feature 到develop</p> <pre> $ gitcheckoutdevelop Switchedto branch 'develop' $ gitmerge --no-ffmyfeature Updatingea1b82a..05e9557 (Summaryofchanges) $ gitbranch -d myfeature Deletedbranchmyfeature (was 05e9557). $ gitpushorigindevelop </pre> <p style="text-align: center;"><img src="https://simg.open-open.com/show/84832910e059383bfb71da558f821adb.png"></p> <h3><strong>Release branches</strong></h3> <p>继承分支: develop</p> <p>合并分支：develop 和 master</p> <p>命名规范：release-*</p> <p>创建一个release 分支</p> <p>Release branch是通过develop分支而创建.</p> <pre> $ gitcheckout -b release-1.2 develop Switchedto a new branch "release-1.2" $ ./bump-version.sh 1.2 Filesmodifiedsuccessfully, versionbumpedto 1.2. $ gitcommit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumpedversionnumberto 1.2 1 fileschanged, 1 insertions(+), 1 deletions(-) </pre> <p>完成一个release 分支</p> <p>当release branch已经准备就绪，需要做几件事。</p> <ol> <li>release分支被合并到master分支上(每一个提交到master上的commit都是一个新版 本，切记)。</li> <li>master上的commit都要添加tag，方便将来查看和回滚。</li> <li>release上所做的修改必须合并到develop分支上，保证bug已被修补。<br> 前两个步骤：</li> </ol> <pre> $ gitcheckoutmaster Switchedto branch 'master' $ gitmerge --no-ffrelease-1.2 Mergemadebyrecursive. (Summaryofchanges) $ gittag -a 1.2 </pre> <p>为了把release上的改变保存到develop，需要合并到develop。</p> <pre> $ gitcheckoutdevelop Switchedto branch 'develop' $ gitmerge --no-ffrelease-1.2 Mergemadebyrecursive. (Summaryofchanges) </pre> <p>这个步骤可能会导致冲突，如果这样的话，解决冲突，然后再提交。</p> <p>最后，可以删除release 分支。</p> <pre> $ gitbranch -d release-1.2 Deletedbranchrelease-1.2 (wasff452fe). </pre> <h3><strong>Hotfix branches</strong></h3> <p>继承分支: master</p> <p>合并分支：develop 和 master</p> <p>命名规范：hotfix-*</p> <p>运行过程中发现了bug，就必须快速解决，这时就可以创建一个Hotfix branch，解决完后合并到master分支上。好处是开发人员可以继续工作，有专人来负责搞定这个bug。</p> <p>创建hotfix分支</p> <pre> $ gitcheckout -b hotfix-1.2.1 master Switchedto a new branch "hotfix-1.2.1" $ ./bump-version.sh 1.2.1 Filesmodifiedsuccessfully, versionbumpedto 1.2.1. $ gitcommit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumpedversionnumberto 1.2.1 1 fileschanged, 1 insertions(+), 1 deletions(-) </pre> <p>fix bug, 解决问题</p> <p>需要一次或几次commit</p> <pre> $ gitcommit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixedsevereproductionproblem 5 fileschanged, 32 insertions(+), 17 deletions(-) </pre> <h3><strong>完成Hotfix branch</strong></h3> <p>当结束时，bugfix要被合并到master，同时也要合并到develop，保证下个版本发布时该bug已被修复。这跟release branch完成时一样。</p> <p>首先更新master和tag release</p> <pre> $ gitcheckoutmaster Switchedto branch 'master' $ gitmerge --no-ffhotfix-1.2.1 Mergemadebyrecursive. (Summaryofchanges) $ gittag -a 1.2.1 </pre> <p>接下来与develop合并</p> <pre> $ gitcheckoutdevelop Switchedto branch 'develop' $ gitmerge --no-ffhotfix-1.2.1 Mergemadebyrecursive. (Summaryofchanges) </pre> <p>有一个例外，就是当一个release branch存在时，bugfix要被合并到release而不是develop，因为release最终会被合并到develop。</p> <p>最后移除branch</p> <pre> $ gitbranch -d hotfix-1.2.1 Deletedbranchhotfix-1.2.1 (wasabbe5d6). </pre> <h2><strong>总结</strong></h2> <p>了解Git 在软件工程及敏捷开发中的地位，明白git与其他版本控制工具之间的区别，掌握Git 工作的基本原理和必备操作，复杂问题可以查找git的相关命令，应用git开发的流程模型，让Git 成为我们的真正利器。</p> <p>参考资料：</p> <p>1） <a href="/misc/goto?guid=4958183577197840820" rel="nofollow,noindex">http://nvie.com/posts/a-successful-git-branching-model/</a></p> <p>2） <a href="/misc/goto?guid=4959722331124647878" rel="nofollow,noindex">https://community.qingcloud.com/topic/457/%E6%8A%80%E6%9C%AF%E5%9F%B9%E8%AE%AD-git-%E4%BD%A0%E7%9C%9F%E7%9A%84%E4%BC%9A%E7%94%A8%E4%B9%88/2</a></p> <p> </p> <p>来自：http://blog.jobbole.com/107027/</p> <p> </p>