GIT

GIT、一个文件在同一时刻只能有一个人checkout出来修改，别人要修改需要等待；2、经常出现代码之间的互相覆盖；3、每次提交代码时要在自己checkout出来的文件列表中找半天才能识别出来；4、当重构一个大模块时，为了不影响既有代码，需要另外建立一个代码库来单独开发；5、在维护阶段，如果多种开发活动关系到同一段代码就有可能导致冲突，这对生产环境是极大的风险；多种版本控制介绍和对比1、本地版本控制系统本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异，它的工作原理基本上就是保存并管理文件补丁。（如下图）。如何让在不同系统上的开发者协同工作呢多种版本控制介绍和对比2、集中化的版本控制系统（诸如CVS，Subversion）都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新（如下图）。多种版本控制介绍和对比3、分布式版本控制系统（诸如Git）在这类系统中，把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份。多种版本控制介绍和对比4、各版本控制的对比分类优点缺点本地版本控制系统比较简单开发者不能在不同系统上协同工作集中化的版本控制系统每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个CVCS要远比在各个客户端上维护本地数据库轻松容易得多。中央服务器的单点故障，谁都无法提交更新，也就无法协同工作。分布式的版本控制系统任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复，分支的创建合并很方便。管理doc等二进制文件不是很好Git基本介绍Git是为了管理Linux内核发起并开发的一个开源分布式版本控件系统（DVCS）。从2002年起，Linux内核一直使用BitKeeper来进行版本管理，但是在2005年BitKeeper和Linux内核开源社区的合作关系结束，BitKeeper再也不能免费使用了，这迫使Linus决定开发一个开源界自已的版本控制系统。传统的SVN、CVS等版本控制系统，只有一个仓库（repository)，用户必须要连上这个仓库才能开始提交；而Git之类的分布式版本控制系统，它的每个工作目录都包含一个完整的仓库，它们可以支持离线工作，先把工作提交到本地仓库后再提交上远程的服务器上的仓库里。分布式的处理也让开发更为便捷，开发人员可以很方便的在本地创建分支来进行日常开发，每个人的本地仓库都是平等且独立，不会因为你的本地提交而直接影响别人。Git安装与初次运行时git前的配置1、安装GIT（windows）2、简单配置工作环境第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要，每次Git提交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记录Git基础要点1、直接快照，而非比较差异CVS，Subversion，Perforce，Bazaar等每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容（每个版本中记录着各个文件的具体差异）Git基础要点Git并不保存这些前后变化的差异数据，Git更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git不会再次保存，而只对上次保存的快照作一连接。Git基础要点2、状态所有文件都不外乎这两种状态：已跟踪或未跟踪1)已跟踪在Git内都只有三种状态：已提交(committed)，表示该文件已经被安全地保存在本地数据库中了；已修改(modified)，表示修改了某个文件，但还没有提交保存；已暂存(staged)，表示把已修改的文件放在下次提交时要保存的清单中。2）未跟踪(除了上面的都是)Git实战取得项目的仓库（两种方式）何谓分支以及使用分支的好处分支式工作流程分支的创建，删除记录每次更新到仓库分支的合并与冲突解决储藏（Stashing）打标签查看提交历史等取得项目的仓库取得Git项目仓库有两种方法1、是在现存的目录下，通过导入所有文件来创建新的Git仓库；2、从已有的Git仓库克隆出一个新的镜像仓库来；何谓分支以及使用分支的好处何谓分支：分支是用来跟踪代码提交情况的一条路径。在传统的CVS/SVN中分支都是主干上代码的廉价拷贝，而在Git中分支就是指向建立分支的提交点的一个指针，这意味着节省了存储空间和拷贝的时间。使用分支的好处：1、在任何时候，假设我们突然想改变一个算法的实现，那么我们可以开出一个分支来专门实现这个算法，等实现好了再合并到原来的分支上来替换老的算法。这在实现新算法时丝毫不影响老算法的使用。2、在维护阶段，我们可以专门开出一个分支来重构某个模块，可以专门开个分支来处理热补丁。这些内容都可以同时进行且不互相影响。分支的创建现在让我们来看一个简单的分支与合并的例子，实际工作中大体也会用到这样的工作流程：1.开发某个网站；2.为实现某个新的需求，创建一个分支。3.在这个分支上开展工作。此时分支情况如图创建了一个新的分支指针分支的创建假设此时，你突然接到一个电话说有个很严重的问题需要紧急修补，那么可以按照下面的方式处理：1、返回到原先已经发布到生产服务器上的分支。2、为这次紧急修补建立一个新分支。3、测试通过后，将此修补分支合并，再推送到生产服务器上。4、切换到之前实现新需求的分支，继续工作。此时分支情况如图hotfix分支是从master分支所在点分化出来的分支的合并与冲突解决此时你已经把那个严重的问题解决了，接下来需要做什么呢？把hotfix分支合并到master分支并发布到生产服务器。此时分支情况：问题解决了，只要切换到之前实现新需求的分支，继续工作。分支的合并与冲突解决上面的合并很顺利，几乎不需要我们任何操作；有时候合并操作并不会如此顺利，如果你修改了两个待合并分支里同一个文件的同一部分，Git就无法干净地把两者合到一起。分支的合并与冲突解决Git会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：hotfix:index.htmldivid=footer123/div=======divid=footer234/divdevolop:index.html可以看到=======隔开的上半部分，是hotfix分支中的内容，下半部分是在develop分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：divid=footer123/div分支的删除经过一段时间的开发，你的仓库可能有好几个分支了，有些分支可能是为了开发一个特殊功能而新建的，现在已经合并到其它对应的分支了，对于这些分支而言已经没有多大用处了，这时我们可以毫不客气的删除了。如果你要删除一个你没有合并到其它分支的分支，这时就会导致失败。储藏经常有这样的事情发生，当你正在进行项目中某一部分的工作，里面的东西处于一个比较杂乱的状态，而你想转到其他分支上进行一些工作。问题是，你不想提交进行了一半的工作，否则以后你无法回到这个工作点。我们不做任何处理，强制切换分支情况会这么样？失败。这时候就可以把这些变更储藏起来，随时可以重新应用。储藏变更：gitstash；查看现有的储藏：你可以使用gitstashlist；重新应用储藏：gitstashapply打标签同大多数VCS一样，Git也可以对某一时间点上的版本打上标签。人们在发布某个软件版本（比如v1.0等等）的时候，经常这么做。命令：gittag-av1.4-m‘描述说明’；分支式工作流程如今有了分支与合并的基础，我们会介绍些使用分支进行开发的工作流程。长期分支由于Git对分支的处理非常方便，我们可以同时拥有多个开放的分支，每个分支用于完成特定的任务，随着开发的推进，你可以随时把某个特性分支的成果并到其他分支中。比如仅在master分支中保留完全稳定的代码，即已经发布或即将发布的代码。与此同时，他们还有一个名为develop或next的平行分支，专门用于后续的开发，或用于热补丁，一旦进入某种稳定状态，便可以把它合并到master里。使用多个长期分支的做法并非必需，不过一般来说，对于特大型项目或特复杂的项目，这么做确实更容易管理。特性分支一个特性分支是指一个短期的，用来实现单一特性或与其相关工作的分支。可能你在以前的版本控制系统里从未做过类似这样的事请，因为通常创建与合并分支消耗太大。然而在Git中，一天之内建立，使用，合并再删除多个分支是常见的事。分支式工作流程拥有多个特性分支的提交历史我们的工作流程图示：我们的工作流程客户端工作流程1.前提1）以里程碑为时间单位2）服务端建立长期分支develop,hotfixdevelop：用于新特性开发和功能改进hotfix：用于正式系统上报出的bug修复2.工作流程1）从服务器上clone项目2）建立本地的develop，hotfix分支用于跟踪服务器上的对应分支3）hotfix分支修复好后推送到服务器上的对应分支4）将hotfix合并到develop分支5）develop完成一个完整功能后推送到服务器上的对应分支6）删除本地的develop和hotfix分支，带服务端合并完成后获取服务端数据，将origin/master合并到自己的master。然后从2）开始下个里程碑我们的工作流程服务端工作流程1.前提1）以里程碑为时间单位2）服务端建立长期分支develop,hotfixdevelop：用于新特性开发和功能改进hotfix：用于正式系统上报出的bug修复2.工作流程1）补丁修复后，确定每个开发人员都推送了最新代码，且稳定后再将hotfix合并到master2）确定每个开发人员都推送了最新的develop分支，且稳定后再将develop合并到master3)一个里程碑后，在master上新建develop和hotfix分支供后续开发。提交指南1、请将每次提交限定于完成一次逻辑功能。并且可能的话，适当地分解为多次小更新，以便每次小型提交都更易于理解。请不要在周末穷追猛打一次性解决五个问题，而最后拖到周一再提交。无论是五次小提交还是混杂在一起的大提交，最终分支末端的项目快照应该还是一样的，但分解开来之后，更便于其他开发者复阅。这么做也方便自己将来取消某个特定问题的修复。2、需要谨记的是提交说明的撰写。写得好可以让大家协作起来更轻松。GIT使用记录每次更新到仓库查看提交历史等