分支管理介绍

分支管理介绍

先说说什么是branch。

branch  [br?nt?]  n. 分支; 树枝; 部门,分科; 支流;  vi. 分支形成; 分支扩张;  [计] 下分支的指令;  vt.  使分支; 使分叉;
trunk    [tr??k]   n.  树干; 躯干; 象鼻; 汽车车尾的行李箱;
merge  [m?:rd?]  vt.融入; (使)混合; 相融; 渐渐消失在某物中;

1

branch  [br?nt?]  n. 分支; 树枝; 部门,分科; 支流;  vi. 分支形成; 分支扩张;  [计] 下分支的指令;  vt.  使分支; 使分叉;

2

trunk    [tr??k]   n.  树干; 躯干; 象鼻; 汽车车尾的行李箱;

3

merge  [m?:rd?]  vt.融入; (使)混合; 相融; 渐渐消失在某物中;

按照Subversion的说法,一个branch是某个development line(通常是主线,也即trunk)的一个拷贝,见下图:

branch存在的意义在于,在不干扰trunk的情况下,和trunk并行开发,待开发结束后【合并】回trunk中。在branch和trunk各自开发的过程中,他们都可以不断地提交自己的修改,从而使得每次修改在repository中都有记录。

设想以下场景,如果你的项目需要开发一个新功能,而该功能可能会修改项目中的绝大多数文件,而与此同时,你的另一位同事正在进行bug fix,如果你的新功能不在branch中开发而直接在trunk中开发,那么你极有可能影响另一位同事的bug fix,他在bug修复中可能会遇到各种各样的问题,因为你的频繁提交代码引入了过多的不稳定因素。你可能会说,那我在开发的过程中不提交不就行了,等到我全部开发结束我再提交,是,你可以这么做,那还要版本控制干什么呢?也许等到你最后提交代码的时候(也许一周,也许两周?),你会发现有一大堆conflict等着你resolve。。。

那么,正确的做法是什么?使用branch,从trunk创建branch,然后在你的branch上开发,开发完成后再合并到trunk中。

关于branch先讲到这里,下面说说什么叫做合并。

很好理解,当branch开发完成后(包括必要的测试),将branch中的修改同步到trunk中,这个过程有可能包括修改文件、增加文件、删除文件等等。

说到这里,貌似本文差不多可以结束了,不就是分支和合并么?只要再简单地说说如何建立分支和如何合并就可以收尾了,可能只需两个命令,也可能只需鼠标点几下然后键盘敲两下即可。其实事情远非这么简单,爱动脑筋的同学可能会问了,将branch的改动merge到trunk的时候,和上文说的直接在trunk中全部开发完然后提交有何区别?你最后还不是要处理一大堆conflict?

这个问题问得非常好,其实这正是本文的重点:branch和trunk在并行开发的过程中如何感知对方,branch如何才能在开发过程中不会和trunk越走越远,导致最后无法合并?试想一下,如果在你开发branch的过程中,trunk中的某个类文件已经被删除了(这可能是另外一个家伙在另一个branch上开发了两周后才合并到trunk的),而你竟然在这个类文件上做了大量修改,试问你到最后合并回trunk的时候该有多蛋疼?解决这一问题的唯一手段是,branch要不停地和trunk保持【同步】,你要及时地知道trunk都做了什么修改,这些修改是否会影响你正在开发的新功能,如果需要,你必须及时调整branch的代码,使之能与trunk兼容。

那么如何让branch和trunk保持同步?合并,从trunk合并到branch,你没听错,是从trunk合并到branch。关于TortoiseSVN的合并,有几点需要注意:

  • TortoiseSVN的合并发生在本地,也即你的working copy中,你无需过多担心会对repository中的代码造成影响
  • 不管是从trunk合并到branch还是最终从branch合并回trunk,在每次合并前最好先update,然后将本地的修改先全部commit,保护好现场,万一合并不理想随时都可以revert
  • 合并完成后看是否能正确编译,然后测试验证,最后将合并后的改动提交到repository

一次完整的分支管理过程

下面我将step by step地演示如何一次完整的branching和merging,包括创建分支、分支开发、分支和主线同步,分支合并到主线的全过程。

1、创建仓库

假设我要在D:\TortoiseSVN\TestRepository目录中创建repository,只需右键TestRepository目录,依次选择"TortoiseSVN" -> "Create repository here"便完成了repository的创建。

2、检出资源

假设要check out到D:\TortoiseSVN\TestSVN。在D:\TortoiseSVN目录下创建TestSVN目录,然后在该目录上右键,选择"SVN Check out...",在弹出的窗口中的"URL of repository"中填入"file:///D:/TortoiseSVN/TestRepository",其他默认即可,最后点击ok。

3、创建项目

在主线trunk中创建新项目MyProject

4、创建分支

在 /trunk/MyProject 目录上右键,依次选择 TortoiseSVN --> Branch/tag...,在弹出窗口的【To URL】中填入分支的地址,在这里【目标revision】选择HEAD revision,然后添加log,点击ok后分支便建立了。

5、检出分支

在TestSVN目录右键,选择 TortoiseSVN Update 即可将刚刚建立的分支检出到本地。进入 /branches/MyProject 目录下你会发现其文件结构和 /trunk/MyProject 一模一样,因为目前此分支就是 trunk 的一个拷贝。

6、开发分支branch和主线trunk

在分支中修改并提交一个修改。

在trunk中修改并提交一个修改。

在分支中再修改并提交一个修改。

7、核心步骤:将主线trunk中的修改同步到分支branch中

前面第6步演示的是branch和trunk在独立、并行地开发。为了防止在错误的道路上越走越远,现在branch意识到是时候和trunk来一次同步了。

将主线trunk合并到分支branch的步骤:

  • 1、首先在本地主线trunk中update一下,有冲突的解决冲突,保证trunk和repository已经完全同步。
  • 2、然后在 /branches/MyProject 上右键,依次选择 TortoiseSVN  --> 【Merge...】 -->  在弹出的窗口中选择第一项 【Merge a range of revision】,意思是:将某个分支或主线上提交的多个revision间的变化,合并到另外一个分支上。

 

  • 3、点击next,由于是要从主线trunk合并到分支branch,所以这里的 URL to merge from 应该填主线trunk的路径,Revision range to merge 就是你要将主线trunk的哪些revision所对应的变化合并到当前分支branch中。

  • 4、点击next,这里只需保留默认设置即可。在点击Merge按钮前你可以先Test merge一把,看成功与否,以及merge的详细信息。点击Merge按钮后trunk所做的修改将同步到branch中。

8、提交合并后的branch

至此,branch已经完全和trunk同步,branch和trunk的代码相处很融洽,没有任何冲突。

如果branch已经开发结束,那就是时候将branch合并回trunk了,当然,如果branch还要继续开发,那你将不断地重复6-7这几个步骤。

9、核心步骤:将分支branch合并回主线trunk

在主线的目录 /trunk/MyProject 上右键,依次选择 TortoiseSVN  ->  Merge... ,在弹出的窗口中,Merge type选择第二项 Reintegrate a branch ,这种类型的合并,适合在分支branch开发结束后将所有的改动合并回主线trunk。

在点击next后弹出的窗口中,"From URL"选择 /branches/MyProject,无需选择revision,Reintegrate会将branch上所有修改合并到trunk。

后面的步骤和上文第7步中的一样。

如无意外,branch将成功合并到trunk,你需要做的只是将合并后的主线trunk赶紧commit!

10、提交合并后的trunk

so easy...

11、删除branch

如果你认为你新加的功能已经开发完成了,你可以删除你的分支

来自为知笔记(Wiz)

时间: 2024-11-03 18:32:53

分支管理介绍的相关文章

Git分支管理介绍

分支管理 软件的版本控制以及分支管理贯穿于整个软件产品的生命周期,日常的项目管理对于开发团队能否有节奏且顺利的交付软件也很重要.本分支管理和版本控制规范主要分为3个部分,即分支管理规范.版本号规范.需求与代码关联.其中,将阐述不同的分支管理模型,以及它们的优缺点和使用的场景:描述版本号控制方式--语义化版本:以及将需求与代码管理的必要性等. 分支管理规范 目前比较流行的分支管理模型有三个,即GitFlow.GitLabFlow.GitHubFlow.下面将介绍这三种分支模型的原理,使用场景和优缺

git分支管理与冲突解决(转载)

Git 分支管理和冲突解决 原文:http://www.cnblogs.com/mengdd/p/3585038.html 创建分支 git branch 没有参数,显示本地版本库中所有的本地分支名称. 当前检出分支的前面会有星号. git branch newname 在当前检出分支上新建分支,名叫newname. git checkout newname 检出分支,即切换到名叫newname的分支. git checkout –b newname master 这个命令将上面两个命令合并:在

Xcode Alcatraz插件管理介绍和使用

Xcode Alcatraz插件管理介绍和使用http://www.jianshu.com/p/7a2484123bf6 1.简介 Alcatraz是一个能帮你管理Xcode插件丶模版及颜色配置的工具.它可以直接集成在Xcode的图形界面中,让你感觉就像在使用Xcode自带的功能一样. 2.安装和删除 使用如下的终端来安装Alcatraz: curl -fsSL https://raw.github.com/supermarin/Alcatraz/master/Scripts/install.s

Git 最佳实践:分支管理

5月份,为统一团队git分支管理规范,刚开始准备自己写,在网上搜了下,发现不少不错的git分支管理实践.最后我为团队选择了这个git分支管理实践 A successful Git branching model ,网上有不少参考这篇文章写的中文版gitflow实践,推荐一个中文版的Git 最佳实践:分支管理. 除了团队git管理的需要,我自己在github上有重要的开源项目采用github flow,这里转载一篇关于这两种分支管理的文章:GitHub Flow & Git Flow 基于Git

Git分支管理——创建、合并、删除分支

前言: 几乎所有的版本控制都以某种形式支持分支.使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线. Git的分支模型成称为它的"必杀技特性",也正因为这一特性,使得Git从众多版本控制系统中脱颖而出.Git处理分支的方式是难以置信的轻量,创建新的分支这一操作是秒级完成的,并且在不同分支之间的切换操作也是一样便捷. Git的分支,其实本质上仅仅是指向提交对象的可变指针.Git的默认分支是master.在多次提交操作之后,其实我们已经有一个指向最后那个提交对象的mast

Git 之三 分支管理

写在前面   Git 的官网上有很详细的使用教程(当然有翻译版本),具体地址是 https://git-scm.com/book/zh/v2.唯一不足就是,很多讲解并没有实机演示.但是,毫无疑问,官网资料是最全面的!如果有任何疑问,可以去官网看看! 分支   使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线. Git 的一大特点就是对于分支的支持!Git 的分支可谓是难以置信的轻量级,它的新建操作几乎可以在瞬间完成,并且在不同分支间切换起来也差不多一样快. 远程分支   在了

[廖雪峰] Git 分支管理策略

通常,合并分支时,如果可能,Git 会用 Fast forward 模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制 禁用 Fast forward 模式,Git 就会在 merge 时生成一个新的 commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下 --no-ff 方式的 git merge: 首先,仍然创建并切换 dev 分支: $ git checkout -b dev Switched to a new branch 'dev' 修改 readme.txt

git 教程(12)--分支管理

分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习Git的时候,另一个你正在另一个平行宇宙里努力学习SVN. 如果两个平行宇宙互不干扰,那对现在的你也没啥影响.不过,在某个时间点,两个平行宇宙合并了,结果,你既学会了Git又学会了SVN! 分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了.如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险. 现在有了分支,就不用怕了.你

GIT 分支管理:分支管理策略、Bug分支、Feature分支

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的git merge: 首先,仍然创建并切换dev分支: $ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件,并提交一个新的commit