如何优雅地管理版本

什么是Git?

Git直接翻译是「蠢货,饭桶」,然而却是由天才开发出来的,被全世界最活跃的开发者使用的版本管理系统。可能是一些黑色幽默吧,就像Geek这个词一样。

这里简单介绍一下,详情请查阅资料,本文主要是要讲解一下使用中的一些问题。

Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。 Git的读音为/gɪt/。

Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

常用基本命令

:初始化

:克隆

:查看状态

:添加

:提交

:拉

:推

以上几个命令比较简单,略微查下资料即可顺利使用。

稍复杂基本命令

: 查看所有 记录。

: 在进行客户端开发时,常会考虑到版本。使用 ,那么就在当前代码状态下新建了一个 的标签,使用git tag可以查看当前所有标签。使用 的话,那么就切换到 的代码状态下。

: 比较当前文件和暂存区的差异,两次 之间的差异,两条分支之间的差异,两个版本库之间的差异。

: 切换, 可以切换标签,分支。 还能撤销还没有 进暂存区的代码,比如 即可撤销对于md文档的改动。

: 移除暂存区中等待提交的代码

: 本地仓库与远程名为tes的t仓库进行关联

别名alias

当经常使用Git时,会在输入命令上消耗一些时间,尤其是一些比较长的命令,这时候用户可以自定义别名,用来简化命令。比如:

下面是这篇文章所要讲的重点:团队协作。分支

什么是分支?为什么需要分支?

可以设想这么一个情况,假如一款产品只有一份代码,而需要多人开发,那么每个人都在这一份代码上随意修改,那岂不是乱了套?

这时候我们就需要用到分支,使一个项目组中的不同开发者相互独立,互不干扰。在云端,首先需要一份代码之源,我们称之为:主分支(master),犹如青藏高原巴颜喀拉山脉之于黄河。另外一条重要分支是开发分支(develop)。

可以概括为:master:随时处于准备发布状态develop:最新的开发状态

初步协调团队

线上一般保留master,develop两条分支,开发者首先从master分支pull下代码,然后在本地基于master再新建本地develop分支,然后在develop分支上进行开发。

若在本地完成开发内容,可以将本地develop合并到本地master,将本地master推到线上master,切换回本地develop,将本地develop推到线上develop。(有点拗口,其实就两个步骤)

若在本地只开发到一半,可以将本地develop推到线上develop。

命令行

:新建 分支。需要提一下的是,所建分支是基于当前分支的。

:切换到分支 。

:将上述两步合为一步。

:将本地 分支推送到远程仓库。

:查看本地分支列表。

:查看远端分支列表。

:删除本地分支 。

: 强制删除本地分支,为什么要强制删除?因为在一些情况下是无法常规删除的,比如:你的 分支本身还存在未合并的代码,此时想要使用 是无法删除这个分支的,会出现智能提示。

:删除远程分支。

:将远程分支迁移到本地。

合并

合并有两种方式:

merge

假如在 分支上进行开发,开发完成后想要把分支合并到 分支。

首先需要切换到master分支

不出意外就能将 分支合并进来,但是需要考虑意外情况:发生版本冲突。

rebase e和 有异曲同工之处,使用 也能达到合并分支的效果。

但是这两点的差异在哪?这是stormzhang的一个比喻:

跟 的区别你们可以理解成有两个书架,你需要把两个书架的书整理到一起去,第一种做法是 ,比较粗鲁暴力,就直接腾出一块地方把另一个书架的书全部放进 去,虽然暴力,但是这种做法你可以知道哪些书是来自另一个书架的;第二种做法就是 ,他会把两个书架的书先进行比较,按照购书的时间来给他重新排序,然后重新放置 好,这样做的好处就是合并之后的书架看起来很有逻辑,但是你很难清晰的知道哪些书来自哪个书架的。

冲突

两个人在两条分支上开发不同的功能,然后依次合并到主分支,一般来说两人各司其职是不会出现问题的。但是有些情况,两个人对同一块公共代码进行了更改,比如工具类。此时第一个人可以顺利合并master,但是第二个人提交时会出现冲突,需要手动解决冲突才能顺利合并。

在解决冲突问题时,我们可以根据提示的代码差异进行更改后重新提交。

Stash

假如我们已经在一个分支开发到了一半,现在需要切换到别的分支去完成一些任务,那么现在当前的代码如何保留呢?

此时需要用到 ,当然前提是没有 。首先执行 此时会将还没有 的代码保存到一个暂存区,此时执行 查看,会发现当前分支没有等待提交的代码。 可以 查看暂存区有多少条记录(一条分支暂存的所有代码只会生成一条记录)

此时可以切换到其他分支,将任务完成,再切回到原来的分支,此时,如何将未提交的代码还原?执行 ,然后使用 将暂存区的记录删除。而 相当于将上述两步变为一步。

进阶协调

理想化的状态是这样:比如有三个人开发一款产品,那三个人分别创建三个分支,在各自的分支上完成后合依次合并到 。而现实情况的干扰因素却多得多。这时候需要用到分支管理流程 。

一般状态下有两个主要分支: :随时处于准备发布状态 :最新的开发状态

如果出现了线上版本出现严重bug需要紧急修复,或者某些功能完成后出现了需求变更,这时,需要再引入三个辅助分支。

: 开发新功能的分支, 基于 , 完成后 回

: 准备要发布版本的分支, 用来修复 bug,基于 ,完成后 回 和

: 修复 上的问题,紧急情况, 等不及 版本就必须马上上线. 基于 , 完成后 回 和

情景:

假如我们现在的项目有 和 分支

现在我准备开发一个登录功能,B同学准备开发一个注册功能,那么我需要基于 分支新建 ,B同学需要基于 新建

比如突然说线上版本的图片显示出了bug,需要紧急修复,尽快上线,那么需要在 分支下执行 ,修复完成后合并到 和

如果某一阶段开发的差不多了,功能都已经合并到了 ,现在需要对 上的代码进行一个整体的测试,假如测试通过,可以发布到正式环境,此时可以基于 新建一个分支

这是一个规范化的分支管理流程,可能在小团队的开发中,有些步骤可以忽略,但是我建议还是按照这一套逻辑管理代码会更为高效。

当然,如果你觉得输入这些命令很麻烦,尤其是可以将命令行合并为命令块的情况,你可以使用 推出的一套工具,简化命令。开源地址:https://github.com/nvie/gitflow

—————————————————————————————————

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180124G0HBK700?refer=cp_1026

同媒体快讯

  • 我们的第一款作品

    2018-10-17

相关快讯

扫码关注云+社区