Git使用简介ppt(1)

Git使用简介rainzha2015-03-29Git入门•直接记录快照，而非记录差异Git入门•文件的三种状态:已提交（committed），已修改（modified）和已暂存（staged）Git入门•基本的Git工作流程如下：1.在工作目录中修改某些文件。2.对修改后的文件进行快照，然后保存到暂存区域。3.提交更新，将保存在暂存区域的文件快照永久转储到Git目录中。Git起步•初次运行前的配置gitconfig—globaluser.nameuser.email•在工作目录中初始化新仓库gitinit•在现有项目中克隆gitcloneGit基础-记录每次更新到仓库•检查当前文件状态gitstatus•跟踪新文件gitadd•暂存已修改的文件gitadd(这是个多功能命令)•忽略某些文件.gitingore•查看已暂存和未暂存的更新gitdiff,gitdiff—staged•提交更新gitcommit-m“更新说明”•跳过使用暂存区域gitcommit-a•移除文件gitrm•移动文件gitmvGit基础-查看提交历史•查看提交历史gitlogGit基础-撤销操作•修改最后一次提交gitcommit—amend•取消已经暂存的文件gitresetHEADfile…•取消对文件的修改gitcheckout—file…Git基础-远程仓库的使用•查看当前的远程库gitremote•添加远程仓库gitremoteadd•从远程仓库抓取数据gitfetch[remote-name]•推送数据到远程仓库gitpush[remote-name]•查看远程仓库信息gitremoteshow[remote-name]•远程仓库的删除和重命名Git分支-何谓分支•几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。在很多版本控制系统中，这是个昂贵的过程，常常需要创建一个源代码目录的完整副本，对大型项目来说会花费很长时间。•有人把Git的分支模型称为“必杀技特性”，而正是因为它，将Git从版本控制系统家族里区分出来。Git有何特别之处呢？Git的分支可谓是难以置信的轻量级，它的新建操作几乎可以在瞬间完成，并且在不同分支间切换起来也差不多一样快。和许多其他版本控制系统不同，Git鼓励在工作流程中频繁使用分支与合并，哪怕一天之内进行许多次都没有关系。理解分支的概念并熟练运用后，你才会意识到为什么Git是一个如此强大而独特的工具，并从此真正改变你的开发方式。Git分支-何谓分支Git分支-分支的新建与合并•新建分支(注：还有多种方法)gitbranchbranch•切换到当前分支gitcheckoutbranchGit分支-分支的新建与合并•在分支上提交gitcommit•切换回master分支gitcheckoutmasterGit分支-分支的新建与合并•在master分支上提交gitcommitGit分支-分支的新建与合并•这和大多数版本控制系统形成了鲜明对比，它们管理分支大多采取备份所有项目文件到特定目录的方式，所以根据项目文件数量和大小不同，可能花费的时间也会有相当大的差别，快则几秒，慢则数分钟。而Git的实现与项目复杂度无关，它永远可以在几毫秒的时间内完成分支的创建和切换。同时，因为每次提交时都记录了祖先信息（注：即parent对象），将来要合并分支时，寻找恰当的合并基础（注：即共同祖先）的工作其实已经自然而然地摆在那里了，所以实现起来非常容易。Git鼓励开发者频繁使用分支，正是因为有着这些特性作保障。Git分支-一个例子•现在让我们来看一个简单的分支与合并的例子，实际工作中大体也会用到这样的工作流程：1.开发某个网站。2.为实现某个新的需求，创建一个分支。3.在这个分支上开展工作。•假设此时，你突然接到一个电话说有个很严重的问题需要紧急修补，那么可以按照下面的方式处理：1.返回到原先已经发布到生产服务器上的分支。2.为这次紧急修补建立一个新分支，并在其中修复问题。3.通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上。4.切换到之前实现新需求的分支，继续工作。Git分支-一个例子•假设项目当前的提交历史•现在你决定修补问题53,要新建并切换到该分支，运行gitcheckout并加上-b参数•接着你开始尝试修复问题，在提交了若干更新后Git分支-一个例子•现在你就接到了那个网站问题的紧急电话，需要马上修补。有了Git，我们就不需要同时发布这个补丁和iss53里作出的修改，也不需要在创建和发布该补丁到服务器之前花费大力气来复原这些修改。唯一需要的仅仅是切换回master分支。•接下来，你得进行紧急修补。我们创建一个紧急修补分支hotfix来开展工作，直到搞定：Git分支-一个例子•现在有必要作些测试，确保修补是成功的，然后回到master分支并把它合并进来，然后发布到生产服务器。用gitmerge命令来进行合并：•请注意，合并时出现了“Fastforward”的提示。由于当前master分支所在的提交对象是要并入的hotfix分支的直接上游，Git只需把master分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么Git在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fastforward）。Git分支-一个例子•在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前hotfix分支和master都指向相同的提交对象，所以hotfix已经完成了历史使命，可以删掉了。使用gitbranch的-d选项执行删除操作：Git分支-一个例子•值得注意的是之前hotfix分支的修改内容尚未包含到iss53中来。如果需要纳入此次修补，可以用gitmergemaster把master分支合并到iss53；或者等iss53完成之后，再将iss53分支中的更新并入master。•请注意，这次合并操作的底层实现，并不同于之前hotfix的并入方式。因为这次你的开发历史是从更早的地方开始分叉的。由于当前master分支所指向的提交对象（C4）并不是iss53分支的直接祖先，Git不得不进行一些额外处理。就此例而言，Git会用两个分支的末端（C4和C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。Git分支-一个例子•这次，Git没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）。这个提交对象比较特殊，它有两个祖先（C4和C5）。•值得一提的是Git可以自己裁决哪个共同祖先才是最佳合并基础；这和CVS或Subversion（1.5以后的版本）不同，它们需要开发者手工指定合并基础。所以此特性让Git的合并操作比其他系统都要简单不少。Git分支-一个例子•有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分，Git就无法干净地把两者合到一起（注：逻辑上说，这种问题只能由人来裁决）。•Git作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，可以用gitstatus查阅。•任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：Git分支-一个例子•可以看到=======隔开的上半部分，是HEAD（即master分支，在运行merge命令时所切换到的分支）中的内容，下半部分是在iss53分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：•这个解决方案各采纳了两个分支中的一部分内容，而且我还删除了，=======和这些行。在解决了所有文件里的所有冲突后，运行gitadd将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域。）。因为一旦暂存，就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题，不妨运行gitmergetool，它会调用一个可视化的合并工具并引导你解决所有冲突。•退出合并工具以后，Git会询问你合并是否成功。如果回答是，它会为你把相关文件暂存起来，以表明状态为已解决。Git分支-利用分支进行开发的工作流程•长期分支：许多使用Git的开发者都喜欢用这种方式来开展工作，比如仅在master分支中保留完全稳定的代码，即已经发布或即将发布的代码。与此同时，他们还有一个名为develop的平行分支，专门用于后续的开发，或仅用于稳定性测试—当然并不是说一定要绝对稳定，不过一旦进入某种稳定状态，便可以把它合并到master里。这样，在确保这些已完成的特性分支（短期分支，比如之前的iss53分支）能够通过所有测试，并且不会引入更多错误之后，就可以并到主干分支中，等待下一次的发布。•在任何规模的项目中都可以使用特性（Topic）分支。一个特性分支是指一个短期的，用来实现单一特性或与其相关工作的分支。可能你在以前的版本控制系统里从未做过类似这样的事情，因为通常创建与合并分支消耗太大。然而在Git中，一天之内建立、使用、合并再删除多个分支是常见的事。•我们在上节的例子里已经见过这种用法了。我们创建了iss53和hotfix这两个特性分支，在提交了若干更新后，把它们合并到主干分支，然后删除。该技术允许你迅速且完全的进行语境切换—因为你的工作分散在不同的流水线里，每个分支里的改变都和它的目标特性相关，浏览代码之类的事情因而变得更简单了。你可以把作出的改变保持在特性分支中几分钟，几天甚至几个月，等它们成熟以后再合并，而不用在乎它们建立的顺序或者进度。Git分支-利用分支进行开发的工作流程•现在我们来看一个实际的例子。请看图3-20，由下往上，起先我们在master工作到C1，然后开始一个新分支iss91尝试修复91号缺陷，提交到C6的时候，又冒出一个解决该问题的新办法，于是从之前C4的地方又分出一个分支iss91v2，干到C8的时候，又回到主干master中提交了C9和C10，再回到iss91v2继续工作，提交C11，接着，又冒出个不太确定的想法，从master的最新提交C10处开了个新的分支dumbidea做些试验。Git分支-利用分支进行开发的工作流程•现在，假定两件事情：我们最终决定使用第二个解决方案，即iss91v2中的办法；另外，我们把dumbidea分支拿给同事们看了以后，发现它竟然是个天才之作。所以接下来，我们准备抛弃原来的iss91分支（实际上会丢弃C5和C6），直接在主干中并入另外两个分支。最终的提交历史将变成图这样：•请务必牢记这些分支全部都是本地分支，这一点很重要。当你在使用分支及合并的时候，一切都是在你自己的Git仓库中进行的—完全不涉及与服务器的交互。Git分支-远程分支•远程分支（remotebranch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支；只有在Git进行网络交互时才会更新。远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。•我们用(远程仓库名)/(分支名)这样的形式表示远程分支。比如我们想看看上次同origin仓库通讯时master分支的样子，就应该查看origin/master分支。如果你和同伴一起修复某个问题，但他们先推送了一个iss53分支到远程仓库，虽然你可能也有一个本地的iss53分支，但指向服务器上最新更新的却应该是origin/iss53分支。Git分支-远程分支•假设你们团队有个地址为git.ourcompany.com的Git服务器。如果你从这里克隆，Git会自动为你将此远程仓库命名为origin，并下载其中所有的数据，建立一个指向它的master分支的指针，在本地命名为origin/master，但你无