Git理论及运用

Git理论及运用

1、什么是版本控制（版本迭代）

版本控制（Revision control）是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。

  • 实现跨区域多人协同开发
  • 追踪和记载一个或者多个文件的历史记录
  • 并行开发、提高开发效率
  • 跟踪记录整个软件的开发过程
  • 减轻开发人员的负担，节省时间，同时降低人为错误

2、SVN:集中版本控制

所有的版本数据都保存在服务器上，协同开发者从服务器上同步更新或上传自己的修改

所有的版本数据都存在服务器上，用户的本地只有自己以前所同步的版本，如果不连网的话，用户就看不到历史版本，也无法切换版本验证问题，或在不同分支工作。而且，所有数据都保存在单一的服务器上，有很大的风险这个服务器会损坏，这样就会丢失所有的数据，当然可以定期备份。代表产品：SVN、CVS、VSS

3、Git分布式版本控制

所有版本信息仓库全部同步到本地的每个用户，这样就可以在本地查看所有版本历史，可以离线在本地提交，只需在连网时push到相应的服务器或其他用户那里。由于每个用户那里保存的都是所有的版本数据，只要有一个用户的设备没有问题就可以恢复所有的数据，但这增加了本地存储空间的占用。不会因为服务器损坏或者网络问题，造成不能工作的情况！)

640

4、Git与SVN的主要区别

SVN：

​ SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而工作的时候，用的都是自己的电脑，所以首先要从中央服务器得到最新的版本，然后工作，完成工作后，需要把自己做完的活推送到中央服务器。

  • 集中式版本控制系统是必须联网才能工作，对网络带宽要求较高。

Git：

​ Git是分布式版本控制系统，没有中央服务器，每个人的电脑就是一个完整的版本库，工作的时候不需要联网了，因为版本都在自己电脑上。协同的方法是这样的：

  • 比如说自己在电脑上改了文件A，其他人也在电脑上改了文件A，这时，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。Git可以直接看到更新了哪些代码和文件！

Git是目前世界上最先进的分布式版本控制系统。

5、Git的基本理论

工作区域：

  • 三个本地区域：

    • 工作目录（WorkSpeace）：工作区，就是你平时存放项目代码的地方
    • 暂存区（Stage/Index）：用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息
    • (本地)仓库区（Repository/Git Directory）：就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本

  • 一个远程区域：

    • 远程区（Remote）：远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换

  • 注：History==(本地)仓库区（Repository/Git Directory）

工作流程

git的工作流程一般是这样的：

１、在工作目录中添加、修改文件；

２、将需要进行版本管理的文件放入暂存区域；

３、将暂存区域的文件提交到git仓库。

因此，git管理的文件有三种状态：已修改（modified）,已暂存（staged）,已提交(committed)

  • clone ：克隆远程文件

  • push ：推送本地修改分支至远程git仓库

  • fetch ：是将远程主机的最新内容拉到本地，不进行合并

  • checkout：最常用的用法对于工作分支的切换了：

  • pull ：则是将远程主机的master分支最新内容拉下来后与当前本地分支直接合并 fetch+merge

6、Git分支

就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，

对Git分支的理解：

1、为什么有分支？

对于开发来开发某个项目如果都在主分支进行开发的话完成一半就commit那么会造成代码库的缺少性，导致其他人不能干活，如果等某个功能开发完再提交的话，会又存在丢失每天进度的巨大风险。

2.分支能干什么？

  • 分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。

作用：

  • 使用分支意味着可以把你的工作从开发主线上分离开来，以免影响开发主线。
  • 分支本质上其实就是一个指向某次提交的可变指针

分支分类：

主分支Master

  • 首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布,主分支只用来分布重大版本。

开发分支Develop

  • 日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

  • 这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。

  • 创建分支（创建Develop分支的命令）

    • 　git checkout -b develop master

  • 合并分支：

    • 将Develop分支发布到Master分支的命令：
    　# 切换到Master分支
　　git checkout master

　　# 对Develop分支进行合并
　　git merge --no-ff develop

--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。

微医开发分支规范：通用的命名规范：yyyyMMdd_ 项目名或功能名_ 姓名_dev

比如我一个咨询项目：20130712_consult_wangbiao_dev

临时性分支

  • 功能（feature）分支:了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

微医开发分支规范开发分支命名规则：yyyyMMdd_feature_ 需求名_开发者 （例如：20111017_feature_income_wangjie）

  • 预发布（release）分支:指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

    预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。

微医发布tag命名规则：release_ 服务名_yyyyMMdd _和分支者 （例如： release_wedoctor_20111017_hejun）

  • 修补bug（fixbug）分支:最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。

微医fixbug命名规则：yyyyMMdd_ 项目名_功能名 _bugfix 例如： 20150115_mhealth_soslogin_bugfix

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop

posted @ 2021-03-06 16:20  yyb1024  阅读(64)  评论(0)  编辑  收藏  举报