欢迎回来｡
让我们从上一个视频继续讨论更高级的工作流和获取GitHub｡
现在, 到目前为止, 玛西和我都在这里工作, 分支会长｡
那是什么意思？
嗯, 上面写着树枝, 但我在这里只看到主人｡
你可能已经注意到我们做事的方式有一个问题｡
也就是说, 如果这是我第一天工作, 我只是改变了标题｡
但也许我们根本就不想改变｡
也许这会破坏我们的品牌形象或破坏我们的应用程序｡
但我能这么容易地把它变成大师｡
也许玛西根本不知道｡
我已经添加了该更改｡
这是个大问题, 对吧？
你不想把东西投入到我们所谓的生产中, 投入到用户看到的东西中｡
如果它会破坏我们的网站, 如果你是一家像Facebook这样的大公司, 这可能意味着数百万美元的收入损失,
即使你有一个持续几个小时的错误｡
我将向你们展示一个更现实的工作流程, 那就是分支｡
让我来告诉你我的意思｡
我在这里看到了杰德真正擅长的东西｡
到目前为止, 我们一直在研究我们称之为大师的东西｡
那是主分支｡
可以将主分支视为权威｡
这才是我们的应用程序或网站的正确外观｡
而直到现在, 当我添加了很酷的背景标题, 嗯, 我从背景生成器到很酷的生成器｡
然后当Marcy把它改成大写字母, 然后我们到了这里, 我们只是以线性的方式从一端到另一端到另一端再到另一端｡
但就像我说的, 这是一个有点问题｡
所以更好的做法是我们称之为分支｡
如果我想改变标题, 我将创建一个分支, 并只称之为小功能, 例如｡
而我只是自己在那个分支上工作, 而不会影响主分支｡
用户看到的内容｡
还有｡
只有当它完成了, 当Marcy审查了它, 当我们测试了它,
并且团队中的每个人都没事的时候, 我们才把它带回到Master｡
你可以看到这里有一个很大的特点, 你可以在你自己的分支上持续很长一段时间, 只有当你完成的时候｡
做我们称之为合并到主程序的操作｡
今天我将向大家展示它是如何工作的｡
我将结束这段对话并记住我们的例子｡
玛西的电脑里有所有的文件, 我的电脑里也有所有的文件.
我们都有自己的工作站｡
现在你们知道我的终端里的master是什么意思了, 我会在后面的笔记里告诉你们, 如何设置它, 这样它就能告诉你们,
你在哪个分支上｡
但我们可以看到我们都在Master上｡
那是我的电脑｡
玛西的电脑也在Master上｡
我们想确保我们都是最新的GitHub｡
所以Marcy要做get pull, 我也要做get pull.
假设我现在正在开发一个新功能, 因为不使用master是一个更好的工作流程, 这是一个很好的提示,
通常不使用master总是分支｡
如果我抓到布兰奇他们会让我知道的｡
嗯, 我只有一个分支, 那就是师父｡
但我们可以增加｡
我们可以说获得分支的新特性或小特性｡
现在如果我真的得到了分支｡
我看到我的功能很少, 但主视图突出显示, 因为我当前是主视图｡
所以我会转到小功能分支, 我会说“获取检查”｡
小功能｡
然后您切换到小功能分支, 现在我在小功能分支上｡
所以我所做的就是从Master分支出来, 现在创建了一个小功能｡
让我们来创造一点变化｡
在这个小功能中, 我们将更改当前的CSS背景标题, 使其成为背景｡
我在这里会很安全｡
再一次, 我执行上一个视频中的简单工作流获取状态｡
我看到了｡
是的, 我们有索引｡ html更改｡
天要放晴了, 我们就能看到了｡
既然我们已经做了这个修改, 让我们来看看add｡
同样, 只需获得状态, 以确保一切顺利进行｡
是的, 我知道
我们已准备好提交索引｡ html所以我们会得到commit, commit消息会改变文本｡
好极了｡
让我们把它弄清楚｡
现在, 为了让GitHub知道我们需要做的改变, 再次得到推送｡
所以我们要做的就是得到推动｡
好吧, 我会的
让我们去GitHub看看发生了什么｡
我们看到, 现在出现了一个黄色条, 上面写着“您最近推了分支”｡
如果我单击屏幕上的按钮, 比较､ 提取､ 请求｡
它显示了我做了哪些修改, 我修改了标题, 在这里我可以让Marcy知道, Marcy,
我修改了文本｡
你觉得呢？
然后单击“Create Pull Request（创建合并请求）”｡
现在我有了我的PR, 你可以看到它是如何说合并拉取请求的｡
好了, 如果我们回到我们的图表, 我已经创建了这个小功能, 现在我说, 嘿,
Marcy, 我刚刚做了这个新的更改｡
你觉得呢？
我把它融合到主人身上可以吗？
这里最有可能发生的事情是Marcy会来看这个拉取请求｡
您可以看到我们位于拉取请求选项卡上｡
这样她就能看到它们, 安德烈刚做了这个改动.
她会仔细看这些变化｡
她会说, 嗯, 好吧, 如果她喜欢这个, 她可能会说, 看起来不错｡
她可以点击开始审查｡
你知道吗？
她喜欢这样, 否则她会同意的｡
现在, 马尔西或我自己｡
通常, 您不希望合并自己的池请求｡
团队里的某个人会这么做｡
可现在才说合并｡
用力拉
请求, 确认｡
合并｡
就这样｡
有些团队喜欢事后删除分支, 所以您可以在此处单击“删除”｡
如果我回到代码｡
我已经没有分支了因为我刚把它删了｡
但在我掌握的指数中如果我去｡ 我看到这是背景｡
所以现在马尔西可以去她的项目, 并说, 得到拉｡
再一次｡
她有最新消息｡
现在, 我们来讨论一下可能出现的一些冲突｡
现在, 假设Marcy想要更改某个内容, 而我也更改了相同的内容, 这样就产生了合并冲突｡
看看会发生什么｡
假设Marcy想要改变, 创建一个新功能, 我们称之为一个大功能｡
她会说结账或者去分支｡
大功能｡
她会说, 把支票拿出来大｡
功能｡
如果我得到了分支, 我们会看到这里有一个新的分支｡
让我们把它弄清楚｡
她会在这里说, 她想把它改回背景色或背景生成器, 因为所有的用户都抱怨标题变了,
他们喜欢旧的标题｡
所以她改变了这一点｡
她已经做了get add｡
获得认可｡
恢复旧标题｡
好极了｡
然后她会被推｡
哦, 让我们先清除, 其实｡
而且我们确实有压力｡
当你第一次看到这个的时候, 你可能会看到这个错误, 说没有上游｡
你只需要复制他们给予你的代码｡
好极了｡
现在, 如果我回去｡
回到发电机上｡
我在这里看到了大功能拉取请求｡
为了让你知道你可以有多个提交, 让我们假设Marcy决定, 哦, 这是我｡
Marcy决定在这里加一个感叹号｡
她可以再说一遍, 她救了这个｡
很清楚
她会说“加”｡
获得认可｡
你经常这样做,
所以你在一家公司工作一段时间后, 你会变得非常非常擅长得到, 她会说增加X感叹号｡
哦, 不好意思
所以我想做的是, 得到承诺｡
承诺｡
加了感叹｡
她会再被推一次的｡
我们回去找人帮忙吧｡
如果我们看看这个糟糕的请求, 他们实际上会让这两个标题都恢复到旧标题, 并添加感叹号｡
我们在这里看到, 这两个更改都创建了拉取请求需要更改｡
安德烈｡
所以当这个投票请求发出的时候｡
我决定成立一个新的分支机构, 叫&just;冲突&just;.
和我会查清楚冲突的｡
而现在在冲突分支中｡
我决定改变｡
这样就可以完全移除冷却发生器｡
我保存的？
再来一次｡
我检查我的状态和索引｡ html文件已更改
所以当这一切发生的时候, 我让marci合并到pull请求中｡
所以她把它输入了主程序｡
她的拉入请求已输入｡
现在如果我回到我的冲突中, 我确实得到了地位｡
我们还得加上这些｡
所以先添加, 然后提交｡
我在这里发个短信｡
只是检查｡
现在如果我回去找师父｡
哦, 我必须做｡
快结帐出去, 主人再来｡
在推送更改之前, 我希望确保拥有最新版本的母版｡
所以我什么都不会改变｡
我不会有任何冲突｡
所以我会尽可能的拉到最新的｡
现在我去结账｡
冲突分支｡
而我可以做到这一点的命令得到｡
合并母版｡
所以我要说的是, 把任何一个主人合并到冲突中｡
马尔西一直在工作的大功能, 她合并了它｡
所以现在Master有了大功能分支｡
我还创建了另一个分支, 并且一直在独立处理冲突分支｡
而冲突分支对主人的事一无所知｡
所以我说, 不管Master现在有什么, 包括Marci开发的大功能,
都要把它拉进来, 确保没有冲突｡
所以我就这么做了｡
然后我得到了冲突合并冲突和索引｡ html档案｡
现在, 如果我真的点击了崇高的文本, 让我打开它, 这样你就可以更好地看到它｡
哦, 天哪｡
我得到了这个奇怪的小语法｡
一开始是压倒性的, 但很容易看到发生了什么｡
头部是我的分支所在的位置, 它告诉我, 到最后我不再有H了.
但在主分支中, 我们有后台生成器｡
现在我可以和玛西说, 嘿, 玛西, 你想保留背景生成器的标题吗？
她会说, 是的, 这是正确的做法｡
不要更改背景｡
好吧, 既然这样, 我就把这些线去掉｡
把这个拿掉｡
并保存｡
现在, 如果我真的得到｡
现在的状态｡
好吧, 我会的
我们在这里看到了已修改的状态｡
让我把它再缩小一点这样你就能看到了｡
让我澄清一下｡
我们现在要做的是再次添加, 因为我们已经进行了这些更改, 我们必须进行提交修复,
合并问题｡
我忘了｡
我们再来一次｡
还有｡
修复合并问题时发生恩怨｡
让我们清理这里, 并做了状态｡
没有要提交的内容, 正在进行清理｡
如果我真的被推了, 那么, 同样, 我会得到这个错误｡
但这次我想向你们展示, 如果我真的得到了推动起源冲突的机会｡
它现在起作用了｡
让我们回到GitHub｡
看看我们有什么东西｡
我们有了冲突分支, 如果我们现在查看冲突分支, 没有任何变化,
因为我刚刚还原了所有的更改.
所以里面是空的｡
现在没有变化｡
所以Marcy会说, 嘿, 你是不是故意的, 为了做这个公关, 它是空的｡
所以我会在我的公关上看到这条消息, 我可以继续下去｡
这就是您在GET中看到的工作流｡
我会把命令留给你｡
但是你看, 和你一起工作是非常非常好的,
学习一些命令, 只要你有这个可视化模型, 每次你在做什么, 你总是会创建一个分支｡
你可以用你正在开发的任何功能来命名它｡
每隔一段时间, 您就需要将master和merge master拉到您的分支中,
以确保您不会错过其他开发人员或团队成员所做的任何更新｡
完成功能后, 您可以通过执行获取推送来发出拉取请求, 然后在该拉取请求中添加注释,
用户将查看您的文件更改｡
如果他们想让你做一些改变, 那么你可以再做一次, 获取, 添加, 提交｡
最后进行更改, 然后可以合并､ 提取和请求｡
一旦完成了, 那么团队中的其他人, 现在就有了一个新的主人｡
所以团队中的其他人也应该得到拉｡
它确实需要一点时间来适应, 但它是一个非常非常好的工作流,
可以确保团队中的每个人都在处理相同的文件､ 相同的项目, 而不会导致任何错误, 并确保每个人都能很好地协作｡
就是这样｡
我希望你觉得这个有用｡
下次见｡
再见, 再见, 再见