做自己卖东西的网站,龙岩app建设,能打开各种网站的浏览器,仪征做网站公司从人们开始用电脑开始就面临着文件版本控制的问题#xff0c;从最原始的同一个文档多个不同命名表示版本到使用本地的文件版本管理#xff0c;到后面集中式版本管理如2000年的SVN#xff0c;到再后来的分布式的版本控制系统#xff0c;如2005年的Git。到现在用的最多的版本…从人们开始用电脑开始就面临着文件版本控制的问题从最原始的同一个文档多个不同命名表示版本到使用本地的文件版本管理到后面集中式版本管理如2000年的SVN到再后来的分布式的版本控制系统如2005年的Git。到现在用的最多的版本控制库依旧是SVN和GitGit多用于个人、代码库的管理。 与SVN的使用简单相比Gti是入门复杂不过网上有大量视频、文档教程作为技术人员学习并使用理解Git会是一件很值的事。 虽然Git在分布式、分支管理等方便领先SVN但并不代表它能代替SVN两者的理念设计原则不同Git更适合文本文件如代码库的管理尤其是并行远程异地开发、分支较多的情况而SVN则适用于集中式文件版本管理、权限控制严格等场景我们要根据需求选对的工具。 Git的每次提交都会生成一个完整的文件快照对应一个文件目录tree。Git工程有工作区、暂存区、本地仓库3个工作区域引入暂存区是个不错的设计它能够实现部分提交记录文件的修改时间等信息提高文件的比对效率。 与SVN分支策略相比Git分支流程复杂了很多除了要维护两个长期的分支master和develop外还有很多临时性分支如hotfix等甚至有些用SVN分支思维的同学还有疑问这种模式分支合并后岂不是增加了很多重复测试的工作量因为理论上分支测试后任何代码的改动合并到其它分支都是要重新回归测试才可以的。对此要用Git分支思维才能更好理解Git用这样的分支策略就是为了应对实际中常出现的多人多版本并行开发的情况更方便有效率如果实际开发过程中真像SVN开发分支线性向前迭代则分支合并只是简单的移动分支指针并不用重新测试因为它们是同一套代码。 rebase 会把从 Merge Base 以来的所有提交以补丁的形式一个一个重新达到目标分支上。这使得目标分支合并该分支的时候会直接 Fast Forward即不会产生任何冲突。提交历史是一条线这对强迫症患者可谓是一大福音。stash 将工作区与暂存区中的内容做一个提交保存起来然后使用reset hard选项恢复工作区与暂存区内容。我们可以随时使用 stash apply 将修改应用回来。stash 实现思路将我们的修改提交到本地仓库使用特殊的分支指针.git/refs/stash引用该提交然后在恢复的时候将该提交恢复即可。
