Git分支管理

GIT分支管理是一门艺术

http://www.oschina.net/question/54371_59134

摘自: http://kb.cnblogs.com/page/132209/

　　英文原文：http://www.nvie.com/posts/a-successful-git-branching-model/ 

　　原文作者：Vincent Driessen

　　本文经Linux大棚博主总结精简而成。

　　1

　　GIT，在技术层面上，绝对是一个无中心的分布式版本控制系统，但在管理层面上，我建议你保持一个中心版本库。

　　2

　　我建议，一个中心版本库(我们叫它origin)至少包括两个分支，即“主分支(master)”和“开发分支(develop)”

　　3

　　要确保：团队成员从主分支(master)获得的都是处于可发布状态的代码，而从开发分支(develop)应该总能够获得最新开发进展的代码。

　　4

　　在一个团队开发协作中，我建议，要有“辅助分支”的概念。

　　5

　　“辅助分支”，大体包括如下几类：“管理功能开发”的分支、“帮助构建可发布代码”的分支、“可以便捷的修复发布版本关键BUG”的分支，等等。

　　6

　　“辅助分支”的最大特点就是“生命周期十分有限”，完成使命后即可被清除。

　　7

　　我建议至少还应设置三类“辅助分支”，我们称之为“Feature branches”，“Release branches”，“Hotfix branches”。

　　至此，我们形成了如下这张最重要的组织组，包含了两个粗体字分支（master/develop）和三个细体字分支（feature/release/hotfixes）。

　　8

　　“Feature branches”，起源于develop分支，最终也会归于develop分支。

　　9

　　“Feature branches”常用于开发一个独立的新功能，且其最终的结局必然只有两个，其一是合并入“develop”分支，其二是被抛弃。最典型的“Fearture branches”一定是存在于团队开发者那里，而不应该是“中心版本库”中。

　　10

　　“Feature branches”起源于“develop”分支，实现方法是：

git checkout -b myfeature develop

　　11

　　“Feature branches”最终也归于“develop”分支，实现方式是：

git checkout devleopgit merge --no-ff myfeature（--no-ff，即not fast forward，其作用是：要求git merge即使在fast forward条件下也要产生一个新的merge commit）（此处，要求采用--no-ff的方式进行分支合并，其目的在于，希望保持原有“Feature branches”整个提交链的完整性）git branch -d myfeaturegit push origin develop

　　12

　　“Release branch”，起源于develop分支，最终归于“develop”或“master”分支。这类分支建议命名为“release-*”

　　13

　　“Relase branch”通常负责“短期的发布前准备工作”、“小bug的修复工作”、“版本号等元信息的准备工作”。与此同时，“develop”分支又可以承接下一个新功能的开发工作了。

　　14

　　“Release branch”产生新提交的最好时机是“develop”分支已经基本到达预期的状态，至少希望新功能已经完全从“Feature branches”合并到“develop”分支了。

　　15

　　创建“Release branches”，方法是：

git checkout -b release-1.2 develop./bump-version.sh 1.2 （这个脚本用于将代码所有涉及版本信息的地方都统一修改到1.2，另外，需要用户根据自己的项目去编写适合的bump-version.sh）git commit -a -m "Bumped version number to 1.2"

　　16

　　在一段短时间内，在“Release branches”上，我们可以继续修复bug。在此阶段，严禁新功能的并入，新功能应该是被合并到“develop”分支的。

　　17

　　经过若干bug修复后，“Release branches”上的代码已经达到可发布状态，此时，需要完成三个动作：第一是将“Release branches”合并到“master”分支，第二是一定要为master上的这个新提交打TAG（记录里程碑），第三是要将“Release branches”合并回“develop”分支。

git checkout mastergit merge --no-ff release-1.2git tag -a 1.2 （使用-u/-s/-a参数会创建tag对象，而非软tag）git checkout developgit merge --no-ff release-1.2git branch -d release-1.2

　　18

　　“Hotfix branches”源于“master”，归于“develop”或“master”，通常命名为“hotfix-*”

　　19

　　“Hotfix branches”类似于“Release branch”，但产生此分支总是非预期的关键BUG。

　　20

　　建议设立“Hotfix branches”的原因是：希望避免“develop分支”新功能的开发必须为BUG修复让路的情况。

　　21

　　建立“Hotfix branches”，方法是：

git checkout -b hotfix-1.2.1 master./bump-version.sh 1.2.1git commit -a -m "Bumpt version to 1.2.1" （然后可以开始问题修复工作）git commit -m "Fixed severe production problem" （在问题修复后，进行第二次提交）

　　22

　　BUG修复后，需要将“Hotfix branches”合并回“master”分支，同时也需要合并回“develop”分支，方法是：

git checkout mastergit merge --no-ff hotfix-1.2.1git tag -a 1.2.1git checkout developgit merge --no-ff hotfix-1.2.1git branch -d hotfix-1.2.1

　　23

　　还记得文章开始时的那张大图么，我建议你把这幅大图从这里下载下来，打印出来，贴在你写字台的墙壁上，好处不言而喻。

　　over~

Git分支管理策略

http://www.ruanyifeng.com/blog/2012/07/git.html

作者： 阮一峰

日期： 2012年7月 5日

如果你严肃对待编程，就必定会使用"版本管理系统"（Version Control System）。

眼下最流行的"版本管理系统"，非Git莫属。

相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。

但是，太方便了也会产生副作用。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。

Vincent Driessen提出了一个分支管理的策略，我觉得非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。理论上，这些策略对所有的版本管理系统都适用，Git只是用来举例而已。如果你不熟悉Git，跳过举例部分就可以了。

一、主分支Master

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

Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

二、开发分支Develop

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

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

Git创建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分支。

使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的《Understanding the Git Workflow》。

三、临时性分支

前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。

但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

　　* 功能（feature）分支

　　* 预发布（release）分支

　　* 修补bug（fixbug）分支

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

四、 功能分支

接下来，一个个来看这三种"临时性分支"。

第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

功能分支的名字，可以采用feature-*的形式命名。

创建一个功能分支：

　　git checkout -b feature-x develop

开发完成后，将功能分支合并到develop分支：

　　git checkout develop

　　git merge --no-ff feature-x

删除feature分支：

　　git branch -d feature-x

五、预发布分支

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

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

创建一个预发布分支：

　　git checkout -b release-1.2 develop

确认没有问题后，合并到master分支：

　　git checkout master

　　git merge --no-ff release-1.2

　　# 对合并生成的新节点，做一个标签
　　git tag -a 1.2

再合并到develop分支：

　　git checkout develop

　　git merge --no-ff release-1.2

最后，删除预发布分支：

　　git branch -d release-1.2

六、修补bug分支

最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。

创建一个修补bug分支：

　　git checkout -b fixbug-0.1 master

修补结束后，合并到master分支：

　　git checkout master

　　git merge --no-ff fixbug-0.1

　　git tag -a 0.1.1

再合并到develop分支：

　　git checkout develop

　　git merge --no-ff fixbug-0.1

最后，删除"修补bug分支"：

　　git branch -d fixbug-0.1

（完）

文档信息

• 版权声明：自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0
• 原文网址：http://www.ruanyifeng.com/blog/2012/07/git.html
• 最后修改时间：2013年1月14日 21:11
• 付费支持： | 

git提交本地分支到远程分支

http://www.cnblogs.com/springbarley/archive/2012/11/03/2752984.html

git 常用命令(含删除文件)

Git常用操作命令收集：

1) 远程仓库相关命令

检出仓库：$ git clone git://github.com/jquery/jquery.git

查看远程仓库：$ git remote -v

添加远程仓库：$ git remote add [name] [url]

删除远程仓库：$ git remote rm [name]

修改远程仓库：$ git remote set-url --push[name][newUrl]

拉取远程仓库：$ git pull [remoteName] [localBranchName]

推送远程仓库：$ git push [remoteName] [localBranchName]

 

2）分支(branch)操作相关命令

查看本地分支：$ git branch

查看远程分支：$ git branch -r

创建本地分支：$ git branch [name] ----注意新分支创建后不会自动切换为当前分支

切换分支：$ git checkout [name]

创建新分支并立即切换到新分支：$ git checkout -b [name]

删除分支：$ git branch -d [name] ---- -d选项只能删除已经参与了合并的分支，对于未有合并的分支是无法删除的。如果想强制删除一个分支，可以使用-D选项

合并分支：$ git merge [name] ----将名称为[name]的分支与当前分支合并

创建远程分支(本地分支push到远程)：$ git push origin [name]

删除远程分支：$ git push origin :heads/[name]

我从master分支创建了一个issue5560分支，做了一些修改后，使用git push origin master提交，但是显示的结果却是'Everything up-to-date'，发生问题的原因是git push origin master 在没有track远程分支的本地分支中默认提交的master分支，因为master分支默认指向了origin master 分支，这里要使用git push origin issue5560：master 就可以把issue5560推送到远程的master分支了。

    如果想把本地的某个分支test提交到远程仓库，并作为远程仓库的master分支，或者作为另外一个名叫test的分支，那么可以这么做。

$ git push origin test:master         // 提交本地test分支作为远程的master分支 //好像只写这一句，远程的github就会自动创建一个test分支
$ git push origin test:test              // 提交本地test分支作为远程的test分支

如果想删除远程的分支呢？类似于上面，如果:左边的分支为空，那么将删除:右边的远程的分支。

$ git push origin :test              // 刚提交到远程的test将被删除，但是本地还会保存的，不用担心

3）版本(tag)操作相关命令

查看版本：$ git tag

创建版本：$ git tag [name]

删除版本：$ git tag -d [name]

查看远程版本：$ git tag -r

创建远程版本(本地版本push到远程)：$ git push origin [name]

删除远程版本：$ git push origin :refs/tags/[name]

 

4) 子模块(submodule)相关操作命令

添加子模块：$ git submodule add [url] [path]

如：$ git submodule add git://github.com/soberh/ui-libs.git src/main/webapp/ui-libs

初始化子模块：$ git submodule init ----只在首次检出仓库时运行一次就行

更新子模块：$ git submodule update ----每次更新或切换分支后都需要运行一下

删除子模块：（分4步走哦）

1)$ git rm --cached [path]

2) 编辑“.gitmodules”文件，将子模块的相关配置节点删除掉

3) 编辑“.git/config”文件，将子模块的相关配置节点删除掉

4) 手动删除子模块残留的目录

 

5）忽略一些文件、文件夹不提交

在仓库根目录下创建名称为“.gitignore”的文件，写入不需要的文件夹名或文件，每个元素占一行即可，如

target

bin

*.db

 

 

git操作-删除文件

日期:2012-05-20 来源: bg090721 分享至:

 

git删除文件

rm add2.txt

git rm add2.txt

git commit -m "rm test"

git push web

 

-----------at server

cd /var/www/foo.git;sudo git update-server-info

 

------------检查删除效果

cd;rm foo3 -rf;git clone http://[某ip]/foo.git foo3

 

------------更新已经存在的local code

cd;cd foo2

git remote add web [某user]@[某ip]:/var/www/foo.git/

git pull web master