转自 F君のBLOG

按照之前的计划，周五去杜塞尔多夫接到了从慕尼黑来的Armor。他毕业后在微软实习，目前入职德国谷歌，是实实在在的编程大佬。
周末我们参加了Dokomi漫展，本来应该是五月底的漫展，因为疫情，硬是给拖到了九月底。我们两个都是老二次元了，展子上拍coser什么的，轻车熟路。
他在我家过夜，虽说离场馆路途遥远，回到家供扯淡的时间寥寥无几，但我还是见缝插针的向他请教一些编程方面的问题。
聊到Github，他提到了版本管理，这个对我来说还比较陌生的概念。Github可以培养很好的版本管理意识，这也是许多大的代码公司非常看重的能力。
我之前折腾Github主要是为了弄博客，当时有个master分支，本地的改动写个commit再push上去。当时只是比较好奇出了master以外，其他branch的作用是什么，我当时只是把他们当作项目底下的其他文件夹（硬要这么说也没错）
但经过大佬指点，我逐渐明白了branch的真正用途。越是大的项目，合理的版本管理就越是重要。举个例子，现在需要给一个网站写一个新feature,目前这个网站已经上线。这个新的feature需要和网页上其他的部分做联动，如果我直接修改现有的网页文件，用户很可能看到未开发完毕的页面，体验很不好。此时一个解决办法就是把整个网站clone到本地，开发测试完成后再deploy到线上。不过，要是我同时需要开发几个不同的feature呢，或者说，多人合作去做一个项目。本地的clone的方法不再好用，要对付这样的情况，就得用Github这样的有版本管理功能的仓库了。
比如master主分支可以作为用户看到的现有版本，在这个分支下，我可以创建develop分支，或者test分支，再往下，每一个不同的feature都可以再进行展开。画成图形，这不就正像一颗枝叶茂密的树么。用branch来形容再形象不过。
每一个branch写完之后，确认没问题就可以merge到master，这样用户就能使用新的功能了。用户和开发两边都会有不错的体验。
为了实践，我把我的homepage和记账项目上传到了github，并尝试了最基本的分支操作。

这里我已经建好了仓库，到这里和以前没有不同。

使用桌面应用或者网页端再Master下创建了dev分支，现在把软件中切换到dev分支。
这里稍微插两句。
为了真正的让分支起到作用，我花了点时间，折腾了本地网页服务器，还有github到remote server的同步。

本地服务器直接使用Synology的webstation，源文件夹设置成Github仓库本地文件夹。
本地的代码更新将实时反馈到NAS上的网页。

先测试一下本地的访问，一切ok，可以无视chrome提示的网页不安全，本地的证书懒得搞了。

稍微修改一下代码，比如我想把这里的2020改成2017-2020。

修改完成保存

本地页面瞬间更新

github软件这边也检测到了更新，我们再次确认选择的是dev分支，给commit写个description，不写也可以，然后push。

在github网页版上看结果，目前master分区没有任何变化。

在dev分支下，可以看到index的改动。
如果是多人合作的项目，其他开发者也可以看到这条改动并进行review或者优化。

线上的版本还是改动之前的。
现在假设代码没有问题，我们决定deploy刚才的改动。

点击pull request，可以看到箭头从dev指向master。
这里也可以写点comment来记录。

现在已经提交了merge申请，这一步操作个人开发者来说意义不大，如果是多人团队，可以设置不同的权限。比如这里，权限较低的开发成员只能提交request，能否上线还需要admin进行确认。
github自动进行了校验，返回了一个绿勾。如果代码写的有问题这里可能提示conflict，那么就还是得打回去继续改代码。
我们确认后点击merge pull request

允许merge并关闭了这个request

这边master已经开始了更新

因为目前网页服务不是跑在github上，而是单独的VPS，这边还需要通过github action的脚本同步。

github action会把新文件通过rsync上传到server上。

上传完成。

回到github仓库页面，master分区这边也出现了个绿勾，说明merge已经完成。

再次刷新线上的homepage，更新的内容已经出现。

到这里，整个演示完成，回顾一下版本管理的好处。
1.新的开发不会影响已有线上项目的运行。
2.每个feature的开发都相对独立，管理更方便。
3.多人团队开发，权限分明，敏感代码不易泄露。
4.merge到主分之前，review更轻松，只需检查单个request中的内容。
5.使用类似Github的代码托管平台，必要时可版本回溯。