|
@@ -49,18 +49,26 @@ git push origin master --force
|
|
|
|
|
|
|
|
```
|
|
```
|
|
|
(1) 主干开发分支上线和分支开发主干上线
|
|
(1) 主干开发分支上线和分支开发主干上线
|
|
|
- 在master分支永远是开发版的最新代码，而分支上则是当前线上部署的代码，后者反之
|
|
|
|
|
|
|
+在master分支永远是开发版的最新代码，而分支上则是当前线上部署的代码，后者反之.
|
|
|
|
|
+
|
|
|
|
|
|
|
|
(2)只用master分支，上线打tag说明:
|
|
(2)只用master分支，上线打tag说明:
|
|
|
-Tag上线:全程都只有一个master分支，所有代码都向master提交，当上线的时候我们会在当前版本上打一个tag, tag名就是版本号，比如v1.0.xxxx。版本号可以根据一个简单的规则来定，v.主版本号.副版本号.HHmm。其中后面的HHmm表示上线时的小时和分钟，例如今天下午17点的第一次上线可以叫v1.0.1700, 如果发现有问题18点又进行了一次上线，可以打一个名为v1.0.1800, 如果明天晚上又上线了一次，可以将版本号改为v1.1.2021。使用这种打tag的方式上线可以保留你所有的上线代码版本，你可以随时退回到任意一次上线的代码库，个人认为这样就比分支上线方便一些。
|
|
|
|
|
|
|
+Tag上线:全程都只有一个master分支，所有代码都向master提交，当上线的时候我们会在当前版本上打一个tag,
|
|
|
|
|
+tag名就是版本号，比如v1.0.xxxx。版本号可以根据一个简单的规则来定，v.主版本号.副版本号.HHmm。其中后
|
|
|
|
|
+面的HHmm表示上线时的小时和分钟，例如今天下午17点的第一次上线可以叫v1.0.1700, 如果发现有问题18点又
|
|
|
|
|
+进行了一次上线，可以打一个名为v1.0.1800, 如果明天晚上又上线了一次，可以将版本号改为v1.1.2021。使用
|
|
|
|
|
+这种打tag的方式上线可以保留你所有的上线代码版本，你可以随时退回到任意一次上线的代码库，个人认为这样
|
|
|
|
|
+就比分支上线方便一些。
|
|
|
```
|
|
```
|
|
|
|
|
|
|
|
-##### 修复线上bug
|
|
|
|
|
|
|
+##### 8 修复线上bug （tag上线）
|
|
|
|
|
|
|
|
```
|
|
```
|
|
|
-如果线上遇到bug需要修复而master分支已经提交了新开发的代码了该怎么办呢？非常简单，使用checkout命令，直接退回到最近一次上线的tag位置，然后以此为基准创建一个新的tmptest分支:
|
|
|
|
|
|
|
+如果线上遇到bug需要修复而master分支已经提交了新开发的代码了该怎么办呢？非常简单，使用checkout命令，
|
|
|
|
|
+直接退回到最近一次上线的tag位置，然后以此为基准创建一个新的tmptest分支:
|
|
|
git checkout tmptest v1.1.2021
|
|
git checkout tmptest v1.1.2021
|
|
|
-执行完以后就已经在新创建的tmptest分支了，而且代码已经回到了最近一次上线的状态。完成修复以后直接commit并打上新的tag, 比如v1.2.xxxx, 最后切回master分支，将tmptest合并到master即可：
|
|
|
|
|
|
|
+执行完以后就已经在新创建的tmptest分支了，而且代码已经回到了最近一次上线的状态。完成修复以后直接commit
|
|
|
|
|
+并打上新的tag, 比如v1.2.xxxx, 最后切回master分支，将tmptest合并到master即可：
|
|
|
git commit '修复xxx问题'
|
|
git commit '修复xxx问题'
|
|
|
git tag v1.2.xxxx
|
|
git tag v1.2.xxxx
|
|
|
git checkout master
|
|
git checkout master
|
