0
点赞
收藏
分享

微信扫一扫

source tree图谱和多分支开发

亿奇学 2021-09-21 阅读 116

最左边的线不一定是当前分支,每条线的颜色和后面标签颜色一致,从标签名字和当前分支名比对看哪条线是当前分支。

最左边线好像是最近一次提交所在的分支即哪个分支最后一次提交时间最近,就在最左边。


小白点圆圈表示当前分支的最后一次提交。同时后面的提交注释是粗体显示。


dev分支落后master一个提交


远端从master创建2个新分支test和release。

从第一行看出 master, origin/test, origin/release, origin/master, origin/HEAD都在同一个提交点。


切换到release分支看也是一样。


在dev新建一个文件b.txt,未提交。

1附近的白圈表示当前工作所在点,2附近的白圈表示当前dev分支在远端的提交点。


在dev分支提交并push到远端。

dev分支和本地一致,但是比master, test, release等分支少了一个“commit a.txt to master”提交,同时比master,test,release多了一个”commit b.txt to dev”提交。


切换回master分支

Master, test, release分支最后一次提交在白圈位置,后面的“commit a.txt to master”也是粗体显示。同时落后dev分支一个提交。


Master新建一个资源,不提交。

Master落后dev一个提交,且master本地有新的更改。


把dev合并到master,

会有2个提交“commit b.txt to dev”和“merge branch dev”,因此有2个需要push。


Master推送完成后


切换到release分支


黄色的线和黄色的标签对应,表示当前release分支,release最后一次提交点在“commit a.txt to master”,因为release就是从这个提交点从master拉出来的。

紫色的线和紫色标签origin/dev, dev对应,可以知道紫色是dev分支。蓝色就是master分支,dev分支合并到了master上,但是还没合并到release上。


合并master到release。

可以看到产生2个推送”commit b.txt to dev”和”merge branch dev”。


在dev分支上提交一个新文件“commit c.txt to dev”。然后切回master。

最左边即蓝颜色的是dev分支,紫色的是master分支,master落后dev一个提交。


切到release分支,

release落后dev一个分支,release和master在同一提交点。


在远程release分支上拉一个fix分支,

图中红圈就是fix分支所在提交点。


同时dev上也提交代码。


Dev合并到master。



Fix上修改代码不提交。

可以看到fix分支上是没有c.txt和d.txt的。


fix提交代码。

Fix比master落后3个提交,但是比master有一个新提交。


切回到master

蓝色是fix,紫色是master,黄色是dev。master和dev代码是一样的,比fix多3个提交,但是比fix少一个新提交。


合并fix到master

蓝色是master,紫色是fix,黄色是dev。Master上新产生2个提交“commit e.txt fo fix”和“merge branch fix”。


master推送2个新提交。

蓝色是master,此时master上的代码是最全的了,因为紫色和黄色分支的代码都合并到master上了。


切回到fix分支

蓝色是master,紫色是fix,此时fix上代码比master少3个提交,红圈画出来的。

fix上代码缺少c.txt,d.txt。查看代码得到验证。


合并master到dev

黄色是dev,红圈的5个提交不在dev上,因此有5个push。


只显示当前分支可以少些线和提交。

线上的每个圆点都表示一个提交,同一行上只有1个点(提交)。


版本管理实践(和上面讲解的东西无关):

FeatureXXX具体功能开发分支,从develop分支拉,功能开发自测完后合并到develop分支。来不及上线的feature分支不要合并到develop。

develop开发分支,上面代码都是已经开发完的代码(包括已上线和正在测试的)。

Release分支:测试分支,从develop上fork进行测试,测试发现问题就在release分支上修改,测试通过release代码合并到master分支发布和develop分支(如果有修改)。

master分支:发布分支,任何时候master上代码都是能上线的,可以打tag。

fix分支:当上线后发现bug,在master上开一个fix分支进行修正,修正完后合并到master进行发布,同时fix也要合并到develop,(看情况决定是否合并到当前正在测试的release分支)。

举报

相关推荐

0 条评论