分支

首先嘚瑟一下，上一篇博客成为了开源中国代码托管的“帮助”教程 ，有兴趣的可以在空间里面找一下。习惯使用eclipse做开发，中途也听别人说其他的IDE更好怎么的，去尝试了一下，觉得还是eclipse好，毕竟是IBM出品的。 以前使用svn做代码管理，觉得不错，后来使用了开源中国的git代码托管，觉得很赞，但是都是简单的提交、提交，根本没有用其他功能，只是基本一下修改，太大材小用了。有一天突然想尝试一下分支啊、标签啊什么的（据说git就是在这些方面比svn好的），可是网上资料太少了，而且大多数都是命令行的，特别是分支、标签的推送，找不到操作方法，有也只是命令行，最后实在国外的一个网站上找到（曲折中在youtube上看的抓屏）。eclipse用的人很多吧，用egit插件的人也很多吧，可是怎么一搜都会教人安装、提交变更呢，怎么没有更深入的呢，于是我决定写一篇博客，方便后来的人学习egit插件使用，于是就有了开头说的那篇博客。但是写的并不是很全面，内容也是文字少、图片多，虽然说按照步骤来还是可以操作了，但是始终觉得不好，而且还有一些方面没有涵盖到，但是又不好改的（成为教程了，万一改得不如从前了呢），所以就单独写这篇了。 好了，铺垫完了，下面开始正题。 1、eclipse和egit版本 eclipse使用的是kepler的SR1版，egit就是自带的那个版本，要详细的话

最近都在用atom来代替了sublime text来写代码，github强大的开源插件让这个编辑器变得非常的强大而且有个性化，推荐前端开发的朋友都去尝试使用，为什么不是都建议使用呢？因为atom占用的内存比sublime text确实大了很多很多，目前还出现过崩溃的情况。 这次不是讨论atom的好坏，而是发现了一个问题，atom不能显示git项目的分支。 用atom的朋友应该都都知道，atom打开了git项目（不需要是github），打开项目的其中一个文件，那么在atom的右下角位置都会显示你项目当前的分支，显示修改了多少行，删除了多少行这样的状态，如下图 但是发现有时候，打开了git项目却没有像上面那样的显示，让我一度怀疑自己的atom已经坏了...... 经过试验发现，atom没有我想象中的那么智能吧，这种情况下添加项目文件是没有的 而这样添加项目文件却能够正确显示了，如下 观察可以看出来，这两者的区别在于第一种情况是git项目在添加项目目录的时候是二级目录，而第二种情况则是一级目录，那就是说atom只能识别项目的一级目录？ 这个时候应该确认一下atom是如果读取git项目的，那么需要打开atom的调试器（windows下的快捷键是alt+ctrl+i），atom编辑器调试的对象是atom，那么分析它读取的项目是atom.project，往下查看发现有一个读取项目的仓库方法

昨天改完release分支的操作（ http://www.jiangyouxin.net/2013/02/13/git_flow_2.html ）。现在只剩hotfix了，当然，之后我发现我改的还是release。 按照原始定义，hotfix其实和release很像，唯一的不同是，release分支基于develop创建，而hotfix基于以前的版本TAG创建。源代码里，git-flow-hotfix明显是从git-flow-release复制了一份，然后作了些许修改，很多地方连注释都还没改过来。其实这哥俩没必要分这么清楚，在我的版本里，是使用release分支来实现原版hotfix分支的功能，只是启动命令稍有不同： git flow release start <version> [<base>] 如果省略<base>，则release分支基于develop创建，代表一个主线版本；如果<base>是一个版本TAG，则release分支基于TAG创建，代表一个修补版本（厂里叫做擦屁股版本）。git-flow-release本来就有基于某个base创建分支的功能，只需要再改两点即可： (1) 修改sanity检查部分，允许多个release分支共存 这是因为以前的git flow是允许一个release和一个hotfix分支共存的。 (2) 结束release分支，向master做-

昨天写了Git Flow印象（ http://www.jiangyouxin.net/2013/02/11/git_flow.html ），总体来说这是个不错的东西，与现在厂里的研发模型非常契合。所以打算稍稍做些修改，然后拿到厂里去推广。 今天做的修改（按老周的话，这叫“微创新”），是在git flow feature finish的时候，提供一个选项，可以将所有修改合并为一个commit提交到develop分支上；feature分支本身的提交历史不再保留。 为什么需要这样一个选项？首先当前的git flow在将feature分支向develop合并的时候，使用了--no-ff，强制生成了一个merge结点。见下图（左）： 左图通过merge结点来确定feature之间的边界 —— 如果不使用--no-ff就会形成右图（类似SVN的线性提交历史），日子一久就分不清哪些提交属于同一个feature了。 这已经很好了，但仍不是最好。事实上，feature分支的原始提交历史，很多情况下是无用的。比如说在我厂推广git flow时，feature分支将伴随某个功能“开发 + 测试”的全过程，上面的提交历史体现的是开发和BUG FIX的节奏次序；等合并到develop时，功能基本稳定，只需要合并最终结果，以后也很少会关心这个feature的开发过程中发生了什么事情。 综上

到目前为止我们都还是在一个名为master的分支里面做操作，而git的优势之一就是对分支的操作，在本文中就来说一说怎么搞分支和标签。 0、准备 接着上一篇文章来，继续使用那个工程。 关于git中分支和标签的管理上的建议，大家可以参考这篇文章： Git分支管理策略 以及 一个成功的 Git 分支模型 当然，本文并不打算说怎么规划你的分支和标签，因为我自己也没有闹明白，本文只说怎么创建、合并、删除分支以及标签，关于规划方面的请根据自己的需要来，可以看一下那两篇文章。 1、分支的创建 当我们在git@osc创建一个项目的时候，勾选了初始化项目的话，是会创建一个有master分支的项目的，这也是之前创建项目的方式，此外还可以清空项目，然后推送本地已有的柜台仓库上去。但是这不是重点，重点是有了master，然后在此基础上创建分支，然后开发。 在eclipse中创建分支，请在仓库视图中右键->"switch to"->"new branch",打开新建分支对话框： 在对话框中指定新建的分支基于什么，推送和拉取的配置，分支名是什么等： 新分支的基础默认是当前检出的分支，我们可以进行“选择”，可以在弹出框里面选择具体需要的，现在还没有创建标签，所以“tags”下面还是空的，以后有了标签，就可以基于标签创建分支了。名称可以按照自己的需要命名，只要符合命名要求就可以，不能重复这是必须的

这篇文章当时制作有点粗糙，建议阅读升级版 ： eclipse中egit插件使用--升级版 使用git作为项目的代码管理工具现在是越来越火，网上有各种各样的文章、博客、讨论，其中以命令行居多。使用eclipse作为开发工具的人也是很多，eclipse和git结合指出有一个插件，egit是eclipse官方提供的。 我不讨论从其它代码管理工具转向git，也不讨论其他IDE转向eclipse，而且也不是说使用eclipse开发使用tortoisegit来负责代码管理的相关事项，这里只是介绍eclipse中egit插件的用法。 一、约定 演示使用的eclipse版本为Kepler SR1,git服务为oschina 二、步骤 1、准备代码库 在oschina代码托管商新建代码库 然后复制地址， 然后再eclipse的git视图中克隆代码库 2、新建一个项目用于演示，实际中可以是任意项目 3、将项目加入本地的代码库 选择git管理 选择代码库 4、提交到中央仓库 本地提交 填写说明，选择文件 提交结果 在服务器上查看 5、标签管理 git上同样支持标签，可以标记代码库中比较重要的版本，而且使用起来相当方便。 填写标签的说明信息，选择代码版本用于标签 推送标签到中央服务器 选取推送标签信息 推送结果 在服务器查看 6、分支管理 git也支持分支，并且在各个分支之间切换非常容易（什么是分支

很好用的工具,给出了很好的开发模式 安装: git clone git://github.com/nvie/gitflow.git cd gitflow git submodule init git submodule update sudo make install 简单使用: git flow init git branch git flow feature start test git flow feature finish test git flow release start 1.0 git flow release finish 1.0 这个时候得到最新的master和develop分支 不过下面参考的图中,好像release finish合并到master上的不是release上的分支,而是develop上的 主页: https://github.com/nvie/gitflow/ 参考: http://ihower.tw/blog/archives/5140/ http://www.jeffkit.info/2010/12/842/ 来源： oschina 链接： https://my.oschina.net/u/4355/blog/66668

分支是什么呢？ 团队开发的过程中，每个人都会有一个不同于别人的分支，各自都在自己的分支上编写代码，等到需要的时候，再把各分支合并起来，这样既安全也不会相互影响。 一、创建与合并分支 在上一节中，我们在本地创建了一个Git仓库，但只有一个分支，就是 master 分支，它是主分支， HEAD 指向 master ， master 指向当前提交，所以， HEAD 指向的就是当前分支。 每次提交， master 都会向前移动一步，随着不断的提交，这条分支线会越来越长 当我们创建了新的分支，比如叫 myBranch ，git就会新建一个指针叫 myBranch ，指向 master 相同的提交，在把 HEAD 指向 myBranch ，就表示当前分支在 myBranch 上。 从现在开始，对工作区的修改和提交都是针对 myBranch 分支了，如果我们修改后再提交一次， myBranch 指针就会向前移动一步，而 master 指针不变 当我们在myBranch分支上的工作完成后，就可以把myBranch合并到master，也就是把master指针移动到myBranch的当前提交。 当合并完成后，我们就可以删除掉myBranch分支，也就是把myBranch指针删除掉，然后我们就只剩下master分支了 OK,我们现在通过实际的例子来说明上面分支的使用。我们先看看当前分支： $ git

Git 分支 几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。在很多版本控制系统中，这是个昂贵的过程，常常需要创建一个源代码目录的完整副本，对大型项目来说会花费很长时间。 有人把 Git 的分支模型称为“必杀技特性”，而正是因为它，将 Git 从版本控制系统家族里区分出来。Git 有何特别之处呢？Git 的分支可谓是难以置信的轻量级，它的新建操作几乎可以在瞬间完成，并且在不同分支间切换起来也差不多一样快。和许多其他版本控制系统不同，Git 鼓励在工作流程中频繁使用分支与合并，哪怕一天之内进行许多次都没有关系。理解分支的概念并熟练运用后，你才会意识到为什么 Git 是一个如此强大而独特的工具，并从此真正改变你的开发方式。 3.1 何谓分支 为了理解 Git 分支的实现方式，我们需要回顾一下 Git 是如何储存数据的。或许你还记得第一章的内容，Git 保存的不是文件差异或者变化量，而只是一系列文件快照。 在 Git 中提交时，会保存一个提交（commit）对象，该对象包含一个指向暂存内容快照的指针，包含本次提交的作者等相关附属信息，包含零个或多个指向该提交对 象的父对象指针：首次提交是没有直接祖先的，普通提交有一个祖先，由两个或多个分支合并产生的提交则有多个祖先。 为直观起见，我们假设在工作目录中有三个文件

在本章中您将学习到以下内容： *关键字 if / else / switch / continue / break / case / default / goto *运算符 && || ?: *函数： getchar() / putchar() 以及ctype.h系列 *怎样使用if和ifelse语句，以及如何嵌套使用它们 *使用逻辑运算符将关系表达式组合为更加复杂的判断表达式 *C的条件运算符 *Switch语句 *break continue 和 goto跳转 *使用C的字符I/O函数：getchar()和putchar()。 *由ctype.h头文件提供的字符分析函数系列。 学完本章，您将获得设计按您希望的方式运行的程序所需的全部基本知识。 来源： oschina 链接： https://my.oschina.net/u/2754880/blog/689761