大多数人,都低估了编程学习的难度,而高估了自己的学习能力和毅力。
当前系列: 软件工程 修改讲义


分支

很多时候,我们的软件开发都是“阶段性”的发布:

  • 1.0
    • 1.1
      • 1.1.1
    • 1.2
  • 2.0

公司可能需要同时维护不同的版本,所以就会带来一系列的问题。比如:

  1. 1.0的版本已经发布了,我们都在为2.0版本hard working……
  2. 突然,1.0版本上发现了一个bug,需要马上发布一个补丁修复(hot fix)
  3. 但这时候我们的代码已经是1.0和2.0之间的“半成品”了

咋办?

  • 在半成品上修复之后马上发布吗?不现实
  • 回退到1.0吗?1.0之后的代码不要了

这时候就要引入分支,除了有1.0-2.0-3.0这样的“主干”代码,还要有1.1-1.2……这样的“分支”代码。

merge

@想一想@:是不是只要留下1.0/2.0时候的代码副本就OK了?

不是的,1.1/1.2“分支”上面新增加的代码仍然是有用的,最终还是要合并到“主干”上的呀!

—— 这个过程被称之为merge,能够由版本控制工具自动完成。

注意:merge是“单向”的不是“同步”的,从release到master,只会将release上新提交的内容复制到master上,会将master的内容复制到release。


延伸

branch还可以更主动、更广泛的用于并行开发:

  • 你做你的,我做我的;
  • 你一个branch,我一个branch;
  • 互不干涉,到了一定的时候,大家一起merge

git就默认采用了这种模式:

  • 前面我们讲的多人开发,张三提交,接着李四提交,张三和李四的提交都是在一个branch当中
  • git不会,李四会自动开一个branch,李四本地的提交都算在这个branch中

如果git要像svn一样,没有额外的branch,需要rebase(略)

PS:要不要各自独立branch的?

git能够把branch当做“基本功能”用(随随便便的开branch),主要还是因为她内部精妙的设计:


svn
git
开一个branch
就“真”的copy了相关内容(演示)
“假装”开了一个branch

背后原理

git怎么以branch为核心/基础,实现“轻量级的”branch操作的呢?

指针:HEAD和branch

首先,每新建一个仓库,git会自动创建的一个master分支。(git至少需要一个分支)

我们通常会用该分支作为“主”分支:即大家共用的、主力维护着的分支。

但实际上,git中各个分支是“平等”的,master作为主分支只是约定俗成,没有什么特殊含义或强制性……

每一个分支,也有一个branch指针,新建分支实际上是创建一个新的branch指针。

每一个仓库,还有一个HEAD指针:默认指向(当前分支中的)最后一次提交

通过操作HEAD和branch指针,并配合checkout(更改/同步工作区内容),git就能实现一系列的功能!

PPT演示:(选修)

  • 确定当前分支(活跃,正在被使用):HEAD指向的branch
  • commit:HEAD拖着当前分支branch向“前”走一步

  • 新建一个分支:新加一个branch指针

  • 切换分支:将HEAD指针指向目标分支,并checkout

  • 在当前分支上继续提交
    1. v1
    2. master

  • merge(v1到master):将v1指针移到master

  • 删除分支:删除branch指针。commit记录本身不会被删除,但为了不惹麻烦,branch应该在被merge之后删除

远程分支

复习:本地和远程之间的sync是repository之间的同步。

但是,同步不是每次都把所有内容传一遍吧?

@想一想@:如何找到差异性的那一部分呢?

比如colon一个远程仓库到本地,那就会把整个仓库——包含其中的所有commit记录、branches和HEAD——完整的复制下来;反之亦然。

然后,额外记录下远程仓库中的branch,并把它们标记(添加前缀)为origin,比如:origin/master、origin/release……

#理解#:远程/origin分支存储在本地

本地保存着的远程分支不会随着commit而改变,除非fetch/pull。

在push之前,再更新一次远程branch,然后“对标”本地branch和远程branch(本地master对远程master;本地v1对远程v1……),将差异部分推送到远程。

常用分支名称

版本号更多的时候用于打标签(tag),tag本质上和branch一样,只是名称不同。

branch除了用开发人员昵称命名,常见的还有:

  • master:长期/共有/主流的develop分支
  • release:用于发布的分支,
  • hotfix/patch/bugfix:一般只打补丁
  • feature:开发各种新feature
  • ……


工作流

常用的(以Github为例)有两种:

collaborators

  1. 服务器上只有一个公用repository,向所有developer开放读/写权限
  2. 所有developers都向自己本地repository commit,
  3. 然后直接往公用repository上push(先pull再push)
方便。但是不便于代码质量控制,什么内容都可以往repository里提……通常是“信得过”的团队内部成员才能成为collaborator

fork

不方便。但是自主性/控制性高,通常用于开发人员不特定/放心/熟悉的开源项目中:
  1. 服务器上有一个权威(官方)repository,repository向所有人开放读权限,禁止写权限
  2. 所有developer在服务器上有自己的fork(如果得到认可,fork其实也可以成为权威……
  3. 可以向自己的fork push,但无法向权威repository 直接push
  4. 向别人的repository/fork提交内容,只能发出一股pull request,请求他人pull,然后由他人push


作业

使用你选用的git插件,完成:

  1. 新建两个分支:hotfix和t1
  2. 切换到hotfix:
    1. 在hotfix上进行若干提交
    2. 将hotfix上的修改合并到master上
    3. 删除hotfix分支
  3. 切换到t1:
    1. 在t1上进行若干提交
    2. 切换到master,在master上进行若干(之后能产生conflict)的提交
    3. (resolve conflict 后)将t1 merge到master
  4. 将上述修改全部push到远程仓库,观察远程仓库的变化
  5. 在远程仓库新建一个分支faq,并同步到本地
  6. 在预备班中找到一个小伙伴
    1. 将其添加成collaborator,让其能够直接push到你的repository
    2. fork一个他的repoistory,通过pull request将你的提交添加到他的仓库
学习笔记
源栈学历
大多数人,都低估了编程学习的难度,而高估了自己的学习能力和毅力。

作业

觉得很 ,不要忘记分享哟!

任何问题,都可以直接加 QQ群:273534701

在当前系列 软件工程 中继续学习:

多快好省!前端后端,线上线下,名师精讲

  • 先学习,后付费;
  • 不满意,不要钱。
  • 编程培训班,我就选源栈

更多了解 加:

QQ群:273534701

答疑解惑,远程debug……

B站 源栈-小九 的直播间

写代码要保持微笑 (๑•̀ㅂ•́)و✧

公众号:源栈一起帮

二维码