gitlab 怎么baseline

对于 a i 的建模来讲，有一个非常重要的概念叫做基准，英文叫 baseline， 而且我们真的在工艺界里面去建模的时候，我们一定要重视这个 base line， 那什么叫 base line 呢？ 啊？举个例子，假设我想解决一个问题，比如说我想搭一个推荐系统。好，那我们的目标呢？就是搭一个比较好的推荐系统，就是准确率比较高的。 好呢？搭建推荐系统我们可以采用的方法是比较多的，比如说我们可以采用一个比较简单的模型，或者我可以采用一个比较复杂的模型，所以我可以通过一步步的方式，从简单到复杂的过程去做这个事情。 那什么叫贝斯兰呢？那我们所谓的贝斯兰就是我可能一开始我先搭一个非常简单的一个模型，比如说我们使用一个逻辑回归来搭一个模型， 那这个时候我们可以把逻辑回归当做是一个背词来，我们用逻辑回归模型来验证它的效果之后，假设它的效果是可能是百分之六十的准确率。好，那接下来呢，我再通过稍微复杂的模型一步一步去把它优化掉，所以 这个时候基准起到了一个非常重要的一个作用。那为什么在这个情况下基准这么重要呢？我就有几个原因啊。第一个，第一个主要的原因是基准可以让我们在非常短的时间内可以帮助我们验证咱们模型的效果。 比如说很多的时候我们可能遇到了一个新的问题，那这个时候呢，可能我们会有一些疑问，我们到底能不能解决他 就这个问题是是一个能解决的还是不能解决的？所以我们说我们需要做一个可行性的一个分析，那为了在非常短的时间内验证出可行性， 我们可以使用这种基准来去做。所以一般我们假设使用一个基准的话，那可能在一天一天之内，或者是甚至可能啊，可能更短的时间内可以把这个问题可以验证出来，所以这个基准非常重要。但如果相反，我们一开始直接使用一个很复杂的深度学习模型，你可能需要花 可能一周的时间，或者甚至更多的时间也未必能把它搭建起来，即便搭建了，可能有可能存在非常多的一些 bug， 而且我需要不断的去修复 bug， 我才能把它真正的跑起来。基准的重要性还体现在另外一个事情上，我们来看一下，我们假设来解决一个具体的问题， 然后呢？ x 轴表示的是一个模型不同的模型，然后呢？ y 轴在这里表示的是模型的效果，假设这个模型的效果用一个准确率来表示吧。好，那首先呢，我们使用了一个基准 叫做逻辑回归，所以我们使用的是一个一个基准模型，叫逻辑回归。然后我们通过逻辑回归呢，得出来的一个结论是，它的效果可以达到什么标准呢？ 他的效果可以达到百分之，比如说六十九的准确率，零点六九。好，那做完之后，接下来我们使用一个稍微复杂一点的，那比逻辑回归稍微复杂一点的，我们有一个模型呢，叫做 支持下量机，叫 svm。 那逻辑回归我们用一个 l r l r 来表示它，它的一个简写， 然后通过知识项链机呢，我们做出了一个一个模型，然后他的效果可能是在哪呢？可能在 零点七二，比他稍微高了一点点，这是我们支持项链机的一个结果。 然后下面我们再使用一个稍微复杂一点的纳米，它稍微复杂一点的可能是啊，假设我们使用了神经网络，这个叫 new row network， 叫神经网络。 那使用神经网络之后呢，我们发现他的准确率大概在哪呢？大概在零点七幺，所以我们可以画一条线， 然后零点零点七幺 这个点的准确率。然后下面啊， 我觉得我们再尝试一个比较复杂的模型吧。那，呃，可能尝试了一个，这是一层的神经网络，所以我们在深度学习里面里面会讲到这些细节。那在这里使用的模型呢？叫做一层的神经网络。好，那接下来呢，我再使用，比如说多层的神经网络吧，那这是 多层的神经网络，然后呢，结果发现， 结果发现我们的准确率可能还是维持在零点七幺二这样的一个区间， 那这个说明什么问题？我们可以把这条线可以连起来， 所以从这条 里面可以看得到我们的模型的准确率是在一步一步提高的，但是在一步步提高的过程里面，我们也可以看得到他的一个上限在哪。 我们可以把这条线呢可以画出来，那画完之后呢，你可以发现这条线的趋势可能是类似于这样的，所以从这个趋势我们至少可以大概的判断出，那上线可能是这样的，对吧？那上线可能这样的，那这个图里面可能上线是零点七二，有可能是他的一个上线， 所以这个上线为什么这么重要？我们可以有几个重要性。第一个通过这个上线，我们可以决定要不要持续尝试更复杂的模型？ 因为我们尝试完他之后呢，其实已经发现了我们的准确率可能上升没有那么快。 所以我即便使用更复杂的模型，比如说我接着再做，那有可能我们还是突破不了零点七二的这个上限。 那所以这个时候呢，从公司的角度来讲，我们会做一个决策，比如说我要不要去买更多的机器，然后呢来搭一个更复杂的模型，比如说我们逻辑回归呢？我们训练一天，好，那我现在搭一个更复杂的模型，我可以用，我可以用这个模型来训练两个月，值不值得？ 这个时候我们从公司的角度来讲，可以去测算他的一个投入产出比的，那这是第一个作用。那第二个作用呢？就是 很多的时候刚才也说过，可行性分析对我们 ar 的应用来讲非常重要，而且我们任何的程序，任何的应用，我们首先需要做一些可行性分析的。我们举个例子，比如说我们想做 做一个医疗领域的一个图像识别，比如说让 a i 自动去诊断一个图片，来看一下这个医师这个患者有没有得病。那对于医疗领域的场景来讲，我们对准确准确率的要求是非常高的， 所以当我的准确率可能没有达到百分之或者是百分之九十五或者九十六的时候，那我这个系统可能就没有商用，没，不能，不能商业化了。所以我的意思呢，就是说不同的应用场景有他的一个门槛， 比如说无人驾驶，如果我的准确率还不到百分之零点九九九九九，那这个无人驾驶车是没有办法上路的，所以每个场景呢，他有他的一个门槛，所以通过这种方式，我们基本上可以看到一个 门槛的。那假设我们回到刚才推荐的例子，那我们贾定设置了我这个应用场景呢，可能需要零点七五以上的准确率，我才能商用化，商业化。 那从这个结果可以看得到，哎，我的上线可能就在零点七二了，那这个时候我们就要决定了，我要不要做这个项目， 对吧？因为从这个简单的测试里面可以看得到，我可能再花很多的时间也未必能达到零点七五以上的准确率， 对吧？那这个时候可我们可能会做一个决定，比如说，哎，我干脆就不做这个项目，我来去定一个另外一个项目来做，因为我从这个图里面可以很难看到，对吧？我能达到一个预期的结果的，所以这是一个贝斯懒教基准的一个非常核心的作用。 所以任何的项目我们一定要先尝试机准，千万不要去尝试，比如说复杂的模型， 一定要一定是从简单到一个复杂的过程。那另外呢，基准的一个重要性啊，其实也体现在体，体现在这个地方，比如说我们先尝试了一个非常复杂的模型，比如说神经网络，或者叫深度学习模型，然后我们没有去尝试这些简单的模型， 那这个时候我们会发生一个问题，就是这些复杂的模型本身是很难去挑餐的，也就说很难去训练的。假设我在构建模型的时候呢啊，做了一些，犯了一些错误， 可能这个错误呢会导致我的模型的准确率没有那么高，那这个时候我们甚至都不知道哪里出错了。假设我得到了一个准确率，比如说我跑了一个深度学习，得到了一个准确率 叫零点六七，那对于我们来讲，我们根根本可能不知道是我们训练训练的不对，还是哪里出错了。 但是如果我们已经训练好了这些基本的模型的话，那假如我们通过深度学习得到的准确率在零点六七，那这个时候我们一定会知道可能哪里出错了，我们在 训练的时候可能没有写好，因为我有一个基准，对吧？我有个参考值，所以有参考值之后呢，我们是很容易定位到某一个问题上， 所以这是基准的一个一个，他的一个一个优点。所以最后呢重要的事情说三遍。任何的 ai 的建模一定要重视基准，从基准开始来搭建， 就是任何的 ai 应用一定要从基准开始搭建，这是我给大家的一个非常强烈的一个建议。

呃大家好，呃我是你们的朋友木瓜啊。今天呢呃想和大家聊一聊这个在 getlam 里边啊如何进行代码合并啊？呃大家可以思考一下。呃我们在用 get 的这个过程当中呢呃平时哪些功能用到的是最多的呢 啊啊对吧啊像 pu 对吧？ pus 对吧？呃一般的话这两个功能用的是最多的对吧啊只要我们在用 get 那么呃这两个功能呢是避免不了的对吧必须要用到的对不对啊 那么除了这两个功能以外呢呃其实我们的代码合并呢呃也是用的非常多的啊啊呃比方说我们有一些规范的这种项目啊或者我的项目稍微大一些对吧？啊呃代码合并用的还是比较多的啊。但是呢呃可能也有一些朋友 啊几乎没有用过啊。因为什么呢？就是他们的项目比较小对吧也没有这个代码规范一些东西啊。这样的话呢呃他们在一个分支上啊呃直接铺铺式代码就可以了对不对啊这样的话呢啊他们可能就用不到对吧啊 ok 那么这样呢今天我们再看一下这个代码合并啊怎么来用啊？首先呢呃还是看一下我们本节的这个内容啊。 呃主要包括两个部分啊。第一部分的话就是呃为什么要进行这个代码合并啊？那么呃在哪些情况下我们是需要合并代码的啊？ 那么第二部分呢就是，呃合并代码这个操作呢我们应该怎么来做啊？这一部分的话呢我们会通过演示啊给大家把这个呃整个的这个过程呢演 支出来啊。 ok 首先呢我们先看我们的第一部分啊，我们的第一部分，呃为什么要合并我们的代码啊？那么，呃在我们整个的这个开发过程当中呢？呃由于某些原因呢会导致我们的代码呢会分布在 不同的这个多个分支上啊，就是多个不同的分支上啊，那么最终呢，呃在我们的测试以前啊，或者是说发布以前呢？呃需要把我们的这些代码呢合并在一起，然后再进行我们的测试或者是发布啊， 那么这种情况呢？呃会有很多啊会有很多。呃在这里呢，我就简单给大家列了这么几个呃列了这么几条啊，也就在这几个场景下呢，我们会用到啊，那么其他的场景呢？呃也还会有啊啊大家可以自己思考一下啊。那么第一个场景 啊，就是说啊啊大家在开发的过程当中呢，可能啊并没有在同一个分支上进行开发啊，那么完成后呢我们是需要把这些代码合并到一个分支上面来的啊那么这种情况呢一般会出现在什么时候呢啊？ 呃比方说我们的这个对吧？我们开发的时候都有一个功能拆解对不对啊？那我们在功能拆解的这个阶段呢，呃我们发现我们很多的功能呢啊，他互相之间是没有偶合的对不对啊？中间，呃之间的这个依赖是没有的啊，是没有的。比方说啊我在进行这个 登录页面的这个编码，对吧？那么，呃另一个小伙伴呢？呃在进行像这种比较简单的设置页面的一些编码对吧？啊那么他们之间呢是没有依赖的啊，是没有依赖的。那么这个时候呢，呃这两个 功能呢？呃我们会创建两个不同的分支啊，那么在这两个分支上啊，然后来进行这个编码啊，那么在我们完成了以后呢，我们再把这两个分支呢？呃合并到一个分支上面来啊，呃这样的话呢，我们之间不会产生一些影响，对不对啊？ ok。 那么第二种情况呢就是，呃大家呢在同一个分支商进行开发啊？啊？虽然说在同一个分支商，对不对啊？ 但是呢啊呃这个时候呢，我们可能这个开发资源呢，还有一些空余，对不对啊？还有些空余，那么这个时候呢，我们的产品可能就希望有一些这个胃病的，呃期望有一些呢？呃。下一期的功能能不能提前先做 啊？能不能提前先做？那么这个时候呢我们就可以单另一个分支啊，来做这些功能啊，那么 如果在本期这个功能完成了啊，我们有充足的资源啊，能够让他一起上线啊，那么这个时候呢，我们的代码就要合并到一块，对不对啊？那如果说我们没有这个充足的资源呢啊？那我们放到下一期就完事了啊，那么这个时候呢也有可能呢，需要我们把代码合并到一块来啊。 呃第三种情况呢就是说，呃我们有多个团队啊，在进行多个这个公众模块的开发啊，呃举个例子啊， 呃比方说，呃我们这个做一个这个什么呢？做一个这个？嗯阅读类的这么一个 a p p 吧。啊？那么我们有两个团队啊，一个团队呢，在在做这个什么呢？文字性的阅读对吧？文字性啊都是一些文本对吧？啊？大家打开以后就会读书？ 是的啊，怎么来读就行了啊？另一个团队呢他在做一些什么呢？就是听书类的这么一些功能，对吧？啊？那么这个时候呢都是一些音频对吧？都是一些音频啊。 那么这个时候呢这两呃这两块的功能呢？呃哪个功能先开发完了我们就上哪个，对吧？哪个功能开发完了我们就上哪个啊？这样的话呢？呃 也能够让我们的这个 app 呢呃提前呢推到市场上来啊，能够抓住更多的用户，对不对啊？呃那么这个时候呢？呃我们呃这个时候呢我们就呃 做的过程当中呢啊也有可能就是说我们两个团队的功能呢同时全部开发完了，对不对？那么这个时候呢我们一起来呃上所有的功能的时候呢，我们就需要把这个功能 合并到一块来，对吧？啊？合并到一块来啊？ ok 我们再看我们第四种情况啊啊大家在开发的过程当中呢难免呢会发现线上的一些 bug， 对吧？啊？那么这些 bug 呢可能不太重要啊，如果不太重要的话呢？呃我们会单另一个分支呢来进行一些 bug 修复啊， 修复完了以后呢我们的这个分支呢就放这不动了啊。呃等着什么呢？等着我们的功能啊开发完了以后呢？呃把这块代码呢和我们的这个功能代码呢合到一起，对吧？合到一起然后再进行测试以及我们的发布，对不对啊？那么这个时候呢也是需要我们的这个代码合并了啊。 那么还有一种呢，呃就是说呢，呃大家发现了一些线上的 bug 呢，是一些比较严重的 bug 啊，那么这个时候呢，呃我们的 bug 修复完 以后呢，是需要紧急上线的啊，那么这个时候呢，他不会等待我们的功能开发完了以后再上线，对不对啊？那么等我们的这个呃上线完了以后呢啊，我们的后续，我们的这个正常的功能开发完成了以后呢？呃 需要把我们的这个修复的这个代码合并进来，然后一起上线啊，不然的话我们直接上线的话，有可能我们这个呃修复 bug 的这块代码呢就丢掉了，对不对啊？啊？这也是一种情况啊， 那么看我们第六种情况呢，呃就说我们整个的也是啊，开发过程当中呢，我们还有可能在做什么呢？在做我们的这个代码重购，对吧？也就我们的工程的工程代码的一个重购啊，那么这个重购呢？呃不是我们的这个 bug 修复啊，不是我们的 bug 修复啊， 说我们可能认为某一块功能呢现在的结构上有问题啊，或者说呢？呃我们某一块功能呢？呃可能我们的代码不合理啊，有一些呃效率了，或者是有一些其他的问题，对吧？ 但是这些问题呢不是我们致命的问题啊，不影响我们正常的使用啊，那么这个时候呢，我们可能呢就要对这块代码呢进行一些重构啊，那么重构的这块代码呢？它是，呃 他是什么呢？他是不急于上线的啊，他是不急于上线的，所以说呢啊他会等待我们的这个 呃他会等待我们的这个什么呢？等待我们这个呃功能开发完成了以后啊，然后把代码进行一次合并合到一块，然后一起上线啊。那么为什么不在我们的功能代码的这个呃分支上来 做我们的重构呢？啊？那如果说大家做过重构的这些朋友啊可能就比较理比较理解这一块的东西啊。啊那么这样的话如果说我们的功能代码呃完成了以后呢？我们的重构还没有完成怎么办，对吧？这样的话呢他就会影响到我们正常的一个上限，对不对 啊？所以说他这一块是分开做的啊，分开做的那么最后呢再进行一个合并啊。 嗯那么我们再看我们这个第七种情况啊底出第七种情况下，嗯那就是说，呃我们的代码呢？嗯通过我们的验证完了以后呢？啊？最呃最终要怎么呢？最终要上线对吧？ 啊？最终要上线，那么上线的时候呢它是需要合到我们的 master 分支上然后再进行上线的啊？啊？我们的 master 呢？呃以前呢也聊过这 的东西，对吧？啊？他是一个上线分支啊，他是一个上线分支啊，在他上面呢不会直接修改代码，对吧？原因呢？以前也提过，对吧？啊？ 比方说我们的一些脚本，对吧？自动化脚本啊，可能他是固定到一个分支上面来的，对吧？另一个呢就是说我们的 master 呢，呃只作为一个上线分支来用，对吧？这样的话呢？呃呃我们不在上面改代码啊，不在上面改代码，这样的话呢？呃对我们的这个风险也会小一些，对吧？ 那么 ok。 呃其实后边还有很多的其他的情况啊，大家可以想一想，就是说还有哪些情况啊？嗯，在这里呢，我只是简单的列了这么几条啊，大家呢？呃，能有这么一个概念啊？能有这么个，还能有这么一个概念， 那么 ok， 我们再看我们第二部分啊，怎么样进行我们的这个代码合并呢？呃，首先呢，还是，呃， 打开我们的这个吉他 lamb 啊？拿我们的这个 demo 工程来看啊拿我们的这个 demo 工程来看，呃，首先呢，呃，我，我们是需要呃做我们的这个代码变更的，对吧？我们肯定是需有编码，对吧？ 否则的情况下我们，对吧？代码没有变更的话，我们也不存在合并的这个操作了，对吧？那么首先呢，我先进入到我们的这个单目的这个工程里边来啊，我们看一下我们的分支现在在哪啊？我们在我们的开发分支上啊，在开发分支上呢，我们先改一下我们的代码啊， 我们就加这么一条记录啊，加这么一条记录 看一下啊，有了变更，对吧？我们执行我们的 and cmet， and some fisher， 对吧？还能 some peter 前面加个标啊， okay， 那么这个时候呢，我们的代码就提交到了我们的 developer 分支上，对吧？呃，那么现在，呃，我们的代码完成了，我们要发布了，对吧？我们拿发布这个情况来举例子啊，因为这样的话比较简单一些，对吧？大家更容易理解啊。 那么现在呢，我就要把我们的代码合并到我们的 master 分支上了啊，呃，为了操作呢，我也只在我账号里边来做啊，只在这一个账号里边来做，但是在 在我们实际的这个场景里边呢，呃基本上不会在一个账号里边来做这个事啊。啊？因为我们代码合并的，呃这个操作呢，不是所有的这个开发人员都有权限啊， 他一定是我们整个团队里边的，呃某一些，呃开发人员啊，比如说技术可能好一些，对吧？比如这个技术可能好一些啊，也有可能是立的在做，对吧？也就只是个别的人在做啊。 那么这个时候呢，我们的编码人员完成了以后呢，呃会通过呃他自己的这个账号里边提交这么一个呃合并请求啊，我们可以看到我们左侧的这个导航栏，呃导航列表里边啊有一个这个 啊合并请求的这么一个选项啊。啊那么这个时候呢他会提交一个合并请求，合并请求完了以后呢，呃我们的这个相关的 这个人员呢就能看到啊，呃某个人提交了一次这个合并请求，对吧？那么这个时候呢他就会在他的账号里边然后进行一个这个代码合并的这么一个工作啊，那么流程的话是这个样子啊，我们具体来看啊， 首先的话呢我进入到我们的这个 merge request 这个页面里面来啊，我们可以看到啊有一个 new merge request， 对吧？ 啊？呃第一次的话这是一个创建啊 create mr request 啊，那么后边的话也就是那个那个什么了啊，就一样了后边啊，我们先点一个 new 一个新的，对吧？ 啊？用完了以后呢？嗯我们可以看到呢分两块啊，嗯第一部分的话呢就是我们的 southbridge southbrush 啊，就是说我们的呃代码元，对吧？在哪啊？那么这一块呢就是说我们具体做了代码变更的 那个位置啊，那么现在我在，呃我的位置是什么呢？是我的当前的我的我自己的账号，对吧？那么分支的话呢，我选我们的迪拜乐普啊，我选我的迪拜乐普。 那么他给的 branch 呢？就是意思就是什么呢？就是我们要合并到哪个分支上啊？那么现在呢，我们要合并到呃我账号里边的 master 分支上，对吧？那么我们呢就选 master 分支啊，那么如果说其他的分支呢，我们就选其他的分支就可以了啊， 那么选完了以后呢，我们点我们的这个啊，点我们的这个按钮啊。啊 那么这个时候呢，呃我们需要输入一些这个相关的信息啊，呃需要输入一些相关的信息。首先呢我们的 title 呢，就是我们这一次提交的这个名字啊，就是我们的，呃一个一个标题，对吧？一个标题。那么这个标题默认情况下呢？呃就是我们的 就是我们刚才提交的那个里边的那个叫什么呢？叫我们的 commit message 里边的，对吧？叫我们的 commit commit message 啊， commit message 啊。那么 下面的是我们的描述，对吧？我们描述的话可以呃写一些这个，呃与我们提交的这些内容啊，合并的内容相关的一些东西啊，那么在这呢我就写一个 test 啊，大家根据自己实际的情况来填啊。 后边呢还有一个这个呢，呃就是呃我们的合并人员是谁啊？我们具体做合并的这个合并人员是谁呢？我选我自己啊我选我自己。 呃再往下呢这是里程碑和一个 level 啊，那么因为这两个东西呢？呃，目前我这个项目也没有啊，没有啊，所以说呢，我我我在这里就不选了啊，那么如果说大家的项目是在是在一个里程碑里边来做 啊，那么大家，呃就直接选择自己的里程碑和自己的这个 label 就可以了啊。 ok， 再往下呢，就是我们的这个选项啊，选项里边比较重要的就是这个啊，就这个选项啊，什么意思呢？就是说一旦我们勾上了这个勾呢，那么在我们的这个合并请求啊，同意了以后完成了，对吧？ 我们真正的完成了我们的这个合并请求以后呢，那么我这个分支呢，就会被删掉啊，也就是我们这个原分支啊，就会被删掉啊，那么如果说我去了这个勾呢啊，那么我们合并完了以后呢，我们就不会删他了哈，那么在这呢，我们去掉他哈，那么我们正常的工作当中呢？呃， 很多情况下呢，我们也不会去勾这个东西啊，比方说，呃，我们在发布以前的这次合并，对吧？那么我们合 合并到马斯特上以后，然后再进行发布，那么这个时候呢，我们是不勾他的啊，因为我们在发布的时候有可能会失败，对不对？那么这样的话呢，有可能还需要改一些东西测试，对吧？完成了以后再和马斯特啊，那么这个时候呢，我们是不勾的啊， 什么时候删呢？就说等我们的版本发布完了以后，并且呢打了我们的 tag 以后，那么这个时候我们再删掉这个分支就可以了啊。 ok， 那么填完这些信息以后呢，我我们点一下这个提交啊，点下这个提交， 那么这个时候呢，呃我们的一个，呃请求就提交了啊，一个请求就提交了，那么我们可以看到啊，因为我是在我自己账号里边来做，那么我自己来做呃和平请求，所以说呢，我们能看到有一个墨纸的这么一个按钮啊，那如果说大家 他在不同的账号里边来做的话呢？呃提交，呃这个和平请求的这个，呃这个开发人员呢？他是没有这个按钮的啊，他是没有这个按钮的。 ok， 那么呃我们可以看一下啊，一旦我们提交了这个和平请求以后呢，呃对应的这个人员啊，对应的这个处理的这个人员的账号里边呢，就会显示到这个位置啊， 就会显示到这个位置，那么他可以点开啊，在这个列表，在这个列表里边呢找到。嗯需要他操作的这些合并请求啊，那么这个时候呢，他就可以点进来， 那么点进来了以后呢？呃我们可以看到啊，他能看到一些信息叫什么呢？比方说他这个合并请求呢，是从 developer 分支合并到马四分支的啊，还有呢就是说我是不是要合并啊？那如果我 我要合并，对吧？那我就点末日就行了，那么末日后面呢也有这么一个选项啊，也有这么一个选项，一旦他勾上了，那么合并完成以后呢，就会把那个缘分之就会删掉啊，如果不勾呢就不会删掉啊， 那么在这呢还可以写一些评论信息啊，还可以写一些评论信息。那么如果说我现在不允许这个和平请求操作怎么办呢 啊？不允许怎么办呢？那么我们就点 close 就行了啊，直接关掉它就行了啊，在这呢，我们允许，呃。来合并对吧？我们就点我们的这个 morge 就可以了啊。 ok， 点完墨汁以后呢，呃，我们这个操作就完成了啊，我们这个操作就完成了，呃，完成了以后呢，呃，我们看一下啊， 我们看一下我们的这 这个 commit 信息啊，嗯，因为我们是合到 master 的，对不对？那么我们可以看到啊，除了我一开始在 master 上进行操作的时候，这个除除化代码以外呢，我们又看到了什么呢？两个请求对吧？两个请求， 一个呢就是我原有提交代码的那个 kimit， 对吧？一个是我们原有的这个提交代码的 kimit 啊， 那么这个 camit 完了以后呢？呃，还有一个什么呢？就是我们末日的末日代码的时候这个 camit 啊，我们可以看到啊，就是末至 branch developer into master， 对吧？我们就把这个合并的时候呢，把这个 developer 里边的代码合并到了我们的这个 master 里边啊， 点开以后呢，我们也可以看到一些这种信息啊，一些信息啊。 ok， 呃，那么我们 这个代码合并的这个操作啊，一个完整的流程我们可以看到，对吧？我们可以看到了啊，一个完整的流程，那平时我们做的话，我们就按照这个流程做就可以了啊。 呃，我们可以看到啊，在这的话呢，呃，我也做了一些这个描述啊。呃，大家也可以看一下。呃，并且合并的时候呢，每一个选项代表什么意思呢？我在这呢也列了一下啊，大家可以也可以简单的看一下。 ok， 本节的内容呢，到这就结束了啊，也就是说呢，呃，希望呢对大家有一些帮助啊，那如果大家看了以后呢，呃，感觉对自己有帮助的话呢，也可以把木瓜的这节内容呢呃分享出去啊，呃，就说，呃让更多的人能够看到啊，呃，还有一个呢，就是说，呃，大家 如果想看到更多的关于这个 getlab 的这些信息啊，呃，那么这些内容呢？呃大家也可以关注一下木瓜啊。呃 关于这些的 gtlab 的一些内容呢，后续的话我们也不断的在更新啊，也不断的更新啊，希望呢能有更多的东西啊，能够帮到大家啊。 ok， 谢谢大家啊。

我很好奇，就是你们每一次开发的新需求，然后等我们测试测完了之后，你们怎么把这些新需求的代码跟线上，行不行呀？ 我很好奇这咋做的？其实，呃，对于我们开发来说啊，这个代码是用工具管理的，哎，叫 get， 基本上现在公司都用的 get。 然后呢？我们在公司内部呢，基本上会搭建一个自己的一个 get level， 一个仓库啊，我们比如说我们线上的代码， 他这个仓库里边，比如我们我们现在做这个 app， 对吧？他叫仓库名字，有个名字，那么仓库里边他会维护好几个这个分支。 就一个，比如我们线上的代码，他在就在马斯特分之上，就我们以前开发的代码，最新的代码他就在马斯特分之上。那我们这一次比如说啊，有 新的需求要做，对吧？那对于开发人员来说，先去马斯特分支上去切出来一个新的分支，这个你可以理解为就是我们把马斯特分支去扣赔一份啊，作为一个新的分支，然后我们在这个新的分支的基础上，在他上去做新的工作的开发，然后我们开发完一层厚额去 提侧啊，你们测试现在这个分针测试分针去测试，测试完没有确保没有任何问题的时候，我们再把这个测试分支去合并到这个 mass 分支上， 合并了马斯的分支上，然后用马斯分支来发布上线，那么基本上是这么一个流程。但是这是如果说是你一个人做的这个项目的话，那你就自己拉一个分支，自己开发自己的。嗯，但是 get 他就是为了方便于团队， 比如说你有多个人啊？你，你这次有好多需求，对吧？就好多需求，不同的人做不同模块，比如说我就做一个啊，我就做一个新人入口。对，对，其他人做其他的，那大家都是开始从这个 mass 分支去切出来各自自己的分支。比如说我切出一个分支 是做我的新人专享，对不对？那其他的同事他切出一个分支，他是做他的购物车，对，那大家都是互相互相这个在自己的分支上去开发，那么到最后大家合并起来， 把各自啊开发的分支合并起来，对不对？然后再做测试完了以后再把测试分支再合并到这个地方线上位置 啊。呃，其实不同的公司这个具体的要求不太一样，但是大体的这个过程是这样的，就反正就是在不同的分支去维护着不同的代码，所以说 我们这次的需求呢？他永远是建立在以前的这个代码的基础上。所以说我们开发的功能就是在以前的功能上去增加吗？嗯，对不对？但是为了让我们，呃这个代码保持最新，所以我们测试完了以后，我们需要把我们这个代码怎样合并到骂死的分支上， 让 max 分支永远保持最新的线上的版本啊？那就相当于是合并上去之后就是新功能，然后增加，然后老功能不变。 那肯定要这样的，你新功能是在老的基础上有，有可能你是老的一点都没变，你是在里边去增加功能，有可能是你还把老的部分去删除优化，对不对？然后还有添加新的，然后这个代码他会自动去去做一个合并。对，然后你去对，你再 上线的时候，你又把这个 mass 分支相当于是更新了一遍，他又保持最新的，如果下一次又有需求的话，我们又从 mass 分支来切出来一个，在他的基础上又做，明白吗？嗯，明白了这么一个过程，对。