source tree图谱和多分支开发

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

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

---

 

sourceTree图解116.png

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

---

 

sourceTree图解168.png

dev分支落后master一个提交

---

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

 

sourceTree图解234.png

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

---

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

 

sourceTree图解336.png

---

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

 

sourceTree图解360.png

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

---

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

 

sourceTree图解430.png

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

---

切换回master分支

 

sourceTree图解564.png

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

---

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

 

sourceTree图解669.png

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

---

把dev合并到master，

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

 

sourceTree图解779.png

---

Master推送完成后

 

sourceTree图解793.png

---

切换到release分支

 

sourceTree图解808.png

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

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

---

合并master到release。

 

sourceTree图解1012.png

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

---

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

 

sourceTree图解1114.png

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

---

切到release分支，

 

sourceTree图解1174.png

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

---

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

 

sourceTree图解1252.png

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

---

同时dev上也提交代码。

 

sourceTree图解1285.png

---

Dev合并到master。

 

sourceTree图解1302.png

---

Fix上修改代码不提交。

 

sourceTree图解1317.png

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

---

fix提交代码。

 

sourceTree图解1355.png

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

---

切回到master

 

sourceTree图解1401.png

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

---

合并fix到master

 

sourceTree图解1481.png

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

---

master推送2个新提交。

 

sourceTree图解1578.png

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

---

切回到fix分支

 

sourceTree图解1643.png

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

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

---

合并master到dev

 

sourceTree图解1735.png

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

---

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

 

sourceTree图解1789.png

线上的每个圆点都表示一个提交，同一行上只有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分支）。

ref：https://www.jianshu.com/p/0e64ad60899e