Git--创建与合并分支

来源:本网整理

eclipse git合并分支步骤如下:1、开始进行分支合并操作,先切换回主干(注意此时的主干是我们创建分支时候的主干,不是现在主干进行的情况),如下图所示:2、将分支信息合并到主干,进行merge操作,选择local->我最后一次提交的分支,点击merge即可。3、这个时候通常情况下是没有错误的,接下来要进行一步操作,很危险,就是将最新版本的master给pull下来;修改完冲突之后,进行提交,并推送到主干即可;4、完成提交之后,我们可以将我们的分支删除。登陆eclipse到其他地方选择一次clone,检查是否完成合并www.zgxue.com防采集请勿采集本网。

在 版本回填退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主 分支,即master分支。HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支。

1,从已有的分支创建新的分支(如从master分支),创建一个dev分支 git checkout-b dev 2,创建完可以查看一下,分支已经切换到dev git branch dev master 3.建立本地到上游(远端)仓的链接-这样代码

首先,我们来创建dev分支,然后切换到dev分支上。如下操作:

你可以直接站在你的分支develop 执行git merge master,它会自动把master主分支之后的最新提交merge到你当前的develop分支上,如果不需要全部的提交,只需要个别的提交,可以执行 git cherry-pick

这里写图片描述

git checkout 命令加上 –b参数表示创建并切换,相当于如下2条命令

1.git checkout xxx(切换到你要将其他分支合并到的主分支上,xxx是分支名)2.git merge xxx(合并操作)3.git branch-d xxx(删除已经合并的分支,可选择不删除)git clone url#克隆新的版本库 02

git branch dev

这样会创建新的 commit 来抵消对应的 merge 操作,而且以后 git merge【那个编号所代表的分支】会提示: Already up-to-date. 因为使用方法二会让 git 误以为这个分支的东西都是咱们不想要的。方法三,

git checkout dev

这样会创建新的 commit 来抵消对应的 merge 操作,而且以后 git merge【那个编号所代表的分支】会提示: Already up-to-date. 因为使用方法二会让 git 误以为这个分支的东西都是咱们不想要的。方法三,

git branch查看分支,会列出所有的分支,当前分支前面会添加一个星号。然后我们在dev分支上继续做demo,比如我们现在在readme.txt再增加一行 7777777777777

首先我们先来查看下readme.txt内容,接着添加内容77777777,如下:

这里写图片描述

现在dev分支工作已完成,现在我们切换到主分支master上,继续查看readme.txt内容如下:

这里写图片描述

现在我们可以把dev分支上的内容合并到分支master上了,可以在master分支上,使用如下命令 git merge dev 如下所示:

这里写图片描述

git merge命令用于合并指定分支到当前分支上,合并后,再查看readme.txt内容,可以看到,和dev分支最新提交的是完全一样的。

注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。

合并完成后,我们可以接着删除dev分支了,操作如下:

这里写图片描述

总结创建与合并分支命令如下:

查看分支:git branch

创建分支:git branch name

切换分支:git checkout name

创建+切换分支:git checkout –b name

合并某分支到当前分支:git merge name

删除分支:git branch –d name

那么如何解决提交中的冲突呢?

下面我们还是一步一步来,先新建一个新分支,比如名字叫fenzhi1,在readme.txt添加一行内容8888888,然后提交,如下所示:

这里写图片描述

同样,我们现在切换到master分支上来,也在最后一行添加内容,内容为99999999,如下所示:

这里写图片描述

现在我们需要在master分支上来合并fenzhi1,如下操作:

这里写图片描述

Git用<<<<<<<,=======,>>>>>>>标记出 不同分支的内容,其中<<>>>>fenzhi1 是指fenzhi1上修改的内容,我们可以修改下如下后保存:

这里写图片描述

如果我想查看分支合并的情况的话,需要使用命令 git log.命令行演示如下:

这里写图片描述

分支管理策略。

通常合并分支时,git一般使用”Fast forward”模式,在这种模式下,删除分支后,会丢掉分支信息,现在我们来使用带参数 –no-ff来禁用”Fast forward”模式。首先我们来做demo演示下:

1. 创建一个dev分支。

2. 修改readme.txt内容。

3. 添加到暂存区。

4. 切换回主分支(master)。

5. 合并dev分支,使用命令 git merge –no-ff -m “注释” dev

6. 查看历史记录

截图如下:

这里写图片描述

分支策略:首先master主分支应该是非常稳定的,也就是用来发布新版本,一般情况下不允许在上面干活,干活一般情况下在新建的dev分支上干活,干完后,比如上要发布,或者说dev分支代码稳定后可以合并到主分支master上来。

更多的Git分支管理和冲突解决请参考:

http://www.cnblogs.com/mengdd/p/3585038.html

bug分支

在开发中,会经常碰到bug问题,那么有了bug就需要修复,在Git中,分支是很强大的,每个bug都可以通过一个临时分支来修复,修复完成后,合并分支,然后将临时的分支删除掉。

比如我在开发中接到一个404 bug时候,我们可以创建一个404分支来修复它,但是,当前的dev分支上的工作还没有提交。比如如下:

这里写图片描述

并不是我不想提交,而是工作进行到一半时候,我们还无法提交,比如我这个分支bug要2天完成,但是我issue-404 bug需要5个小时内完成。怎么办呢?还好,Git还提供了一个stash功能,可以把当前工作现场 ”隐藏起来”,等以后恢复现场后继续工作。如下:

这里写图片描述

所以现在我可以通过创建issue-404分支来修复bug了。

首先我们要确定在那个分支上修复bug,比如我现在是在主分支master上来修复的,现在我要在master分支上创建一个临时分支,演示如下:

这里写图片描述

修复完成后,切换到master分支上,并完成合并,最后删除issue-404分支。演示如下:

这里写图片描述

现在,我们回到dev分支上干活了。

这里写图片描述

工作区是干净的,那么我们工作现场去哪里呢?我们可以使用命令 git stash list来查看下。如下:

这里写图片描述

工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,可以使用如下2个方法:

1. git stash apply恢复,恢复后,stash内容并不删除,你需要使用命令git stash drop来删除。

2. 另一种方式是使用git stash pop,恢复的同时把stash内容也删除了。

演示如下

这里写图片描述

文章有很大一部分来自http://my.oschina.net/gsbhz/blog/337719

修正并加入许多自己的理解 希望对你有所帮助。 $(function () { $('pre.prettyprint code').each(function () { var lines = $(this).text().split('\n').length; var $numbering = $('

    ').addClass('pre-numbering').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i <= lines; i++) { $numbering.append($('
  • ').text(i)); }; $numbering.fadeIn(1700); }); });

    本文转载自zch501157081博客,版权归zch501157081所有

    git支持很多种工作流程,我们采用的一般是这样,远程创建一个主分支,本地每人创建功能分支,日常工作流程如下:去自己的工作分支git checkout work工作提交工作分支的修改git commit-a回到主分支git checkout master获取远程最新的修改,此时不会产生冲突git pull回到工作分支git checkout work用rebase合并主干的修改,如果有冲突在此时解决git rebase master回到主分支git checkout master合并工作分支的修改,此时不会产生冲突。git merge work提交到远程主干git push这样做的好处是,远程主干上的历史永远是线性的。每个人在本地分支解决冲突,不会在主干上产生冲突内容来自www.zgxue.com请勿采集。

免责声明 - 关于我们 - 联系我们 - 广告联系 - 友情链接 - 帮助中心 - 频道导航
Copyright © 2017 www.zgxue.com All Rights Reserved