git am没成功如何处理

假设有个需求即将上线，所有的代码都已经提交到 master 分支，突然项目经理说有一个需求不用上了，但是在你这个代码之后，已经有其他人也合并了他们的分支，这个时候你会怎么去回推代码？ 是手动删除代码还是 research 回退后重新合并分支？在这里最合适的方法是使用 get revert。 在 idea 的 get log 记录中有这样一个选项叫做 revert commit。 revert 的作用是撤交某一次提交或者某几次的提交，然后用一个新的提交来覆盖掉之前的提交。 模拟上面的这个场景，比如我现在对某个类做了第一次变更，然后进行了一次代码的提交，并推送到远程分支，接着又进行了第二次代码提交，同样推送最新的代码到远程的分支。这个时候其他人合并了一个新的 比较进来， 现在分支上一共有三次提交， 这个时候突然被告知第二次提交的这块代码不用上线了，于是需要将这次提交回退，只需要在 get 的 log 记录中找到想要撤销的那次提交，选择 reverse commit， 相当于这一次的提交就被撤销了。 get reverse 的好处在于，即使代码已经回退了，但是所有操作记录都还在。 reverse 的实现是通过逆向生成的方式进行代码的回退，比如增加代码就变成了删除代码。 这个时候项目经理又说，刚刚的代码还是一起上线吧。如果用手动删除代码的方式，现在就傻眼了。用 revert 的话，只需要对 revert 的这次提交再进行一次 revert 即可。可以看到代码又回来了，如果是多次提交同时 回退，只需要选中多个，然后执行 revert commit 就可以了。下期视频再来讲讲很多人用的更多的 reset。 以上就是本期视频的全部内容了，我是于宅，我们下期再见。

get 是 什么啊？今天给大家讲的就是 get， 想象这样一个场景，你用 ai 啊，去生成了一段代码，运行起来呢，挺好的，然后呢，你让 ai 再去进行下一步的优化， 结果呢，发现新版本啊， code new 啊出问题了，然后你就想回退到上一个版本啊，却发现你这个版本的代码呢，没有把它保存下来，所以这段好用的代码就这么消失了，这个呢，就是没有 get 的 世界。 所以呢，今天就给大家讲的就是 git， 我 先给大家讲一下 git 是 一个什么啊？ git 是 一个叫做版本控制系统，用来呢去记录文件的每一次的一个变更，让你能够随时地回到任意的一个历史状态，比如说一二三四， 第 n 个能回到任意一个，所以你可以把它想象成一个无限存档的游戏系统，每隔一段时间你就打一个存档，随时可以去读取 任何一个时间节点，都不会丢失。更具体来说呢， get 呢，其实管理的是四个区域，中间呢，第一个是工作区，那工作区里面包含的是你正在编辑的文件，就是你所能看见的这个代码。第二个区域呢是赞存区，赞存区包含的是你准备去提交的文件， 相当于去打包待机的这个区域。好。第三个就是本地仓库，那本地仓库呢，就是已经正式进入的历史版本，它呢是存在你自己本地电脑里面的 好。然后呢，再是远程仓库，远程仓库呢，就是存在远程云端的，比如大家熟知的 gitop 在 这里呢，团队共享哎，也能够去做异地的备份好。然后看到这四个区以后呢，然后 git 提供了一系列的核心操作，来串联起 从工作区到站城区，到本地仓库到远程仓库这样的一系列的流程。首先是 get app， 这个呢主要是去把工作区里面的代码加入到站城区 好，然后呢，再是 get commit， 把站城区里面的代码提交到本地仓库。接下来呢是 get push， 把本地仓库的代码推到远程的仓库。 ok， 以上就完成了我们工作区的代码到远程仓库的这一些流程。那从远程仓库怎么去拉到本地呢？用的是 get pool。 接下来呢，还有 get checkout， 包括 get restore， 把本地仓库里面不同版本的代码给它同步到工作区。 ok， 那 以上呢，就整体把 get 里面的基础的一些分区，包括基础的一些操作给大家去讲完了。 好，接下来呢再去讲 get 的 下一个灵魂叫做分支，这个呢我写在上面啊，叫做 branch。 好 分支呢，是 get 里面最强大的特性，也是最容易会被新手忽视的一个。 ok， 那 我在这个图啊，给大家去写了一个不同版本代码向前推进的一个简示图啊， 上面呢，我们叫做主分支，这个呢定义为魅啊，你看主线啊，是在文静推荐的，然后呢，你可以在比如说在 c 三这个版本里面去分叉出一条叫做 feature 分 支，然后你可以在这个分支里面 啊，去自己再去做实验，开发新功能完成以后再去合并到主线，那在这里的好处就是你的主线是从来不会被破坏的，你可以保证你在你的魅分支里面每一个版本 都是没有 bug 的， 哎，没有问题的。在这个基础，这个分支呢，是去做新功能开发的，你可以在里面去做各种的尝试调试，然后当它稳定以后，你再把它给合并到主分支里面。 所以这套机制直接解决了一个很古老的工程问题，就是怎么同时维护线上的稳定版本和开发中的新功能。 ok， 所以 以上看从下面的基础到下面的一个分支，就是 get 里面的两个最核心的点。那接下来就讲一下为什么 ai 编程前，你还是必须要去搞懂 get。 这个其实不是说学完 get 再去用 ai 的 顺序问题，而是一个工作方式的一个根本性的转变。首先就是你生成代码是不可信的，你需要有的就是快速回退， 你看 ai 写代码速度很快，但出错的频率也很高，他可能改了五个文件，结果只有三个是对的，那另外两个会引入新的 bug， 那 没有 get 呢？你根本就不知道 ai 改了哪里，也无法精准地去回退到某一个节点。那有了 get， 你 可以直接通过叫做 getif 来去看清楚这改动，然后呢，通过 get reset 来做一个回退。第二个呢，就是 ai 编程，它是一个叫做小步快跑的节奏，所以在小步快跑这个节奏里面， get 呢，是一个最好的伴侣。 好的 ai 编程的方式是去提一个小的需求，再 ai 实现，再验证，再 commit， 再去提下一个需求，那每次验证完通过，你最好就是 commit 一 次，那失败了嘛，就 reset 这种，呃，可以把它组织关系理解为存档到读档的一个循环，让你是对这个代码的掌控感呢，是完全不一样的。 第三个点呢，就是 ai， 它其实还可以直接地去操作 git， 但是呢，你还是得去看懂 ai 到底怎么去操作 git。 你 看现在的 ai 编程工具，比如说像 cloud code， 像 curl， 像 git hub compiled， 都可以去自动地执行 git add， 包括 git commit， 甚至还能帮你去写 commit message。 但如果你不懂 git， 你 就无法去判断它到底在做什么，这个命令到底做的对还是不对。 比如当他执行 get， push， 刚刚 force 的 时候，你知道那个意味着是什么？哎，是不是会影响后续的一些编程？第四个点就是团队协助， 团队协助里面必须要用的是 git， 不 管你是独立开发者，还是团队里面去用 ai 代码的协助 review 部署都建立在 git 上，不懂 git， 你 就无法去参与这套的一个工作流， ok。 所以呢， git 其实有很多的命令，但是也不需要一口气去学完所有命令。 我在这里呢去给大家展示了你需要去掌握的基础操作，大家可以截图做个笔记，然后自己呢去记下来。 那最后总结一下， get 呢，不是进阶工具，它是现代编程的一个基础设施，就好像写作需要保存文件一样，基本那在 ai 编程时代，代码生成的速度大幅提升，但随之而来的是更高频率的试错， 更多的文件的改动，更复杂的写作场景，那 git 就是 为了应对这一切而生的。所以搞懂 git 不是 为了去成为工具的专家，而是为了真正掌握自己的代码，不管它是人写的，还是 ai 写的。

各位开发者朋友们，今天我要给大家介绍一个真正改变游戏规则的工具。大家都在谈 ai a 键有多强，能规划，能推理，能写代码。但有一个问题被反复忽视， a 键他根本用不了大多数真实软件想让 a 键，他帮你批量处理 g i n p 图片， 没有 a p i， 让它操控 blender， 渲染一个场景得靠截图点击，脆弱的一碰就崩。想用 agent 自动生成 libraface 报表，只能用残缺版的拍散封装，丢掉了百分之九十的原声功能。这就是 ai agent 的 最后一公里难题。 agent 再强， 也用不了真实世界的软件。香港大学数据智能实验室 h k u d s。 的 研究团队提出了一个不同的答案， c l i anything c l i anything 是 一个开源的 cloud code 的 插件， 核心能力只有一句话，把任何有源代码的软件自动生成一套 a j n。 原生的命令行接口 c l i。 它的底层逻辑来自一个朴素的洞察， 可以是人类和 ai agent 共通的万能接口。为什么 c l i 天然适合 agent 呢？第一，结构化。可组合文本命令天然匹配 l l m 的 输入格式，可以自由串联成复杂工作流，就像搭积木，每个命令都是一块积木， 可以随意组合。第二字描述，一个 help， 就 能让 agent 在 运行时自动发现所有可用功能，无需手写 api 文档，就像你拿到一个新工具，看一眼说明书就知道怎么用。第三， agent 友好，内置 jason 标志，每条命令都能输出结构化 jason agent 无需任何额外解析，就像两个人交流，用结构化的语言比用方言更容易理解。第四，确定且可靠， 输出稳定一致。 a 键的行为可预测，经过验证， code code 的 每天通过 c l i 执行数亿千亿的真实任务。 clean anything 的 核心式，一套全自动气阶段生成流水线，即分析架构设计 c l i 实现模块规划、测试、编辑测试生成文档发布，整个过程无需人工介入。最终产出一个包含以下特性的 python 交互模式，支持逐步迭代的绘画式操作。 就像你和朋友聊天，可以一句一句地交流，而不是一次性说完所有话。第二， jason 输出模式。 jason 标志让 agent 直接消费结构化数据，就像你给 agent 发送一份格式化的报告，它可以直接读取和处理。第三，撤销重做。完整的绘画状态管理， 就像你在编辑文档时，可以随时撤销和重做，不用担心出错。第四，全套测试覆盖单元测试加端到端测试。目前九大应用共一千四百三十六个，测试通过率百分之一百。就像你盖房子，每个环节都经过严格检查， 确保质量。第五次描述文档，每个命令都有完整的 help 说明， agent 可在运行时自主发现，就像每个工具都自带说明书，随时可以查阅。 c l i anything 已经为大量主流开源软件生成了现成的 c l i 接口，覆盖范围相当广。创意工具、 ai 平台、办公套件、数据工具、开发工具、 图标格式化等等一应俱全可以。 anything 的 安装非常简单，在 cloud code 的 绘画中运行两条命令即可完成安装。第一步是添加插件市场，第二步是安装插件，无需任何额外配置，装好即用。安装完成后，只需将软件的本地路径或 git 部仓库地址传给插件 期阶段流水线自动运行。比如为本地 g i n p。 源码生成 c l i， 全期阶段自动完成。生成完成后，将 c l i 安装到系统 pass， 全程交由 cloud code 替你完成安装就好了。如果生成的 c l i 还不够完整，你可以叠代优化 c l i， 扩展覆盖面，并补充缺失的功能。 除 cody code 外，克里安尼尔森也支持其他主流 ai 编程工具，如 open code codex 等。 c l i anything 提出了一个相当有钱占性的命题，今天的软件是为人类设计的，但明天的用户将是 a 卷 t， 我 们需要提前为这个迁移做好基础设施。 它的核心价值在于，第一，彻底绕开 g u i 自动化的脆弱性，不依赖截图，不依赖点击直接对接软件的真实，后端保留百分之一百的原声，功能稳定可预测。 第二，一个命令通吃。所有软件只要有源代码，无论是 g i n p blender、 libreoffice， 还是你内部的私有工具，统统可以一键生成 a 阵的可用的 c l i。 第三， a 阵友好的设计哲学贯穿始终，结构化 j 四输出， help 字描述， r e p l 模式完整测试覆盖。每一个设计 决定都在降低 agent 的 使用门槛。第四，多平台多工具胜肏 code code、 open code code x clean anything 的 设计是平台无关的，正在向更多 ai 编程工具延伸。如果你正在构建需要操控真实软件的 ai agent， clean anything 值得认真评估， 它很可能是目前这个方向上最系统、最完整的开源解决方案。各位开发者朋友们， ai 舰的时代已经到来。今天的软件是为人类设计的，但明天的用户将是 a 舰艇，我们需要提前为这个迁移做好基础设施。可以， anything 就是 这样一座桥梁， 它让任何软件都能被 ai agent 直接操控。彻底解决了 agent 的 最后一公里难题，一个命令通知所有软件。这不是科幻，这是现实。如果你正在构建需要操控真实软件的 ai agent， cleanything 值得认真评估。为 agent 的 时代做好准备，从 cleanything 开始。

不知道各位老大，我们在用 cd 的 时候会不会遇到这样一个问题，就是你用 cd 给你改项目的时候，功能改乱了，你不知道他到底改了哪些文件，就算你让他撤回，他也回到最开始的状态了。那别担心，今天我会用最简单的方式教大家如何使用 cd 来管理好你的项目。话不多说，我们直接开始。 首先我们简单了解一下 cd 是 什么，它的权限是分布式版本控制系统。那更通俗一点讲，你可以把 cd 理解为游戏里面的存档系统， 可以使用 git 记录下某一个时间这个项目下所有的文件状态，并保存为一个存档记录。如果你后续操作这个项目发现有问题，就可以使用 git 一 键撤回你修改的内容，回到之前保存的记录当中。 首先你要确保你已经安装好了 git 和 guest code。 安装完成 git 之后，你要做的第一件事情就是出场 git 的 page。 你 要配置的东西有两个，一个是 git 的 username， 那 另一个就是邮箱。首先我们打开终端，然后在终端当中输入这两行指令。 需要注意的是，这里的 user name 和 e mail 都需要修改为你自己的，没有什么特殊的需求。那这一步的目的是为了让 git 记录下当前操作文件的人是谁。那完成之后，我们来到你的项目当中，这里我就展示一个最简单的文文本档的系统来进行展示。我们首先来到 b s code 的 左侧，这边有一个源代码管理， 这里就会提示你出使化一个仓库，我们点击一下，这样你就完成了整个仓库的出使化创建。我们来到资源管理器这边，右键点击在文件资源中管理显示，这个时候你就可以看到在当前项目下就创建了这么一个点 d 的 一个文 件，如果说你看不到这个文件的话，点击一下这里的查看，点一下这里显示，把这里的隐藏项目勾选上就可以看到了。 我们来进行第一个存档创建，我们首先看到这里的更改目录，这个更改目录下就记录了所有你需要存档的文件，我们在这里就可以简单输入一个消息， 然后点击一个提交，完成之后我们在下方就可以看到我们现在的一个存档记录了，那到这一步你就已经把你当前的代码做了一个最简单的存档。好，接下来我们对整个项目做一些简单的修改，比如说把这里的内容先删除，然后这里随便添加一行内容，按住 ctrl s 进行保存， 然后我们在这里随便再删除其中一个文件。接下来再次打开云代码管理，我们就可以在更改这里看到每一个文件下你所有的操作记录，比如我们点击这个 demo 的 文件加 打完成之后，他这里就会显示你所有的操作记录，红色的部分就是你删除的部分，绿色的部分就是你新增的部分。而如果你发现某一个文件的名称被划掉了，就说明这个文件是刚刚被你删除的文件。如果我们回到资源管理器里面，你会发现这个被删除的文件又回来了， 同理，针对这个被修改的文件，你也可以点击这里的撤销，你再来看这个文件就已经回到之前这个状态了，那接下来假设我们就需要修改这两个文件，我们这里进行第二次提交， 我们点击一个提交，那这个时候你的地址就有两次提交记录了，我们分别点击这两次提交记录，然后点击这里的文件，你就可以看到当前提交下所有的文件的修改的内容是什么。这里几个后缀可以简单记一下， a 就 表示这个文件是新增的， d 的 话就表示这个文件是删除的， m 的 话就表示这个文件是修改的。那完成之后，如果你想要退回到之前这个最初时的版本，就要进行一个回滚的操作，那么很不幸的是 ds code 里面并没有直接这个操作，需要自己手动的执行一个指令。它的方式其实也很简单， 首先按住 ctrl 加 j， 打开这里的终端，带来我们右键需要回退的版本，复制一下这里的哈希，再我们输入这一行指令，按下回退之后，就会发现这里第二次提交的记录就已经消失了， 那上面也重新恢复了之前的更改记录。如果你想批量的回退这些操作，你可以按住其中一个文件，然后再按住 shift 到最后一个文件，就可以选中所有的文件，点击这里的文件都已经回到初审提交的状态了。 当然如果你修改内容比较多，你可以让 c c 帮你总结所修改的所有内容，然后让他帮你进行一个编辑提交，这里他就会总结所有的修改内容，比你自己想看 mate 更加的省心。 同样，如果针对回滚的这个操作，你不想自己手动去执行一些指令，你也可以直接跟 c c 说，让他帮你把 mate 退回到某一个版本， 你只要在这边点确认就可以了。那到此为止，你就已经学会了在 cloud code 当中使用 git 的 所有的基础操作，并且已经完成了一次基础的项目版本管理了。 后续我会再讲解 git 更进阶的内容，比如如何创建分支，如何解决冲突，以及如何把你的项目推送到 github git 这种远程仓库上。那今天视频就到这里，这里是七号，如果对你有所帮助，记得点赞、关注、收藏，我们下期视频再见！拜拜！

上周我碰到一个事儿，同时让 cloud code 写三个功能，结果其中一个 agent 切分支的时候，代码直接提交到了 main 上，我花了两个小时才把 main 恢复到正常状态。那一刻我意识到，传统机台 checkout 在 多 agent 场景下就是定时炸弹。复盘一下， 问题出在哪？传统机台的工作目录只有一个 agent a 在 feature 分 支写代码，写到一半， agent b 说我要切到 main 修个 bug。 这一切， agent a 的 改动要么 stash， 要么丢。 更要命的是，有时候 agent 操作太快， stash 还没弹回来，另一个 agent 已经开始改了，代码直接污染。 后来我翻了翻机台文档，发现一个被低估的功能， gitworktree， 它可以让一个仓库同时有多个工作目录。 我试了一下，感觉就像从单车道直接上了三车道高速，每个 agent 一个目录，谁也不爱着谁。现在我的工作流变成这样，主目录永远是 main 分 支，跑着测试，随时可部署。 feature 目录给 agent 的 a 写新功能， hotfix 目录给 agent 的 b 修线上问题，三个目录物理隔离 agent 的 再怎么折腾也不会互相影响，再也不用担心谁把代码提交到错误的分支了。 实际效果，上周没有 work tree， 三个病性任务搞了两个小时，其中一半时间在擦屁股。这周同样的任务量，三十分钟全部完成，零事故。 改动完之后，每个 work tree 里正常 commit， 切回主目录 merge 没有冲突。给准备事的朋友几个建议，一个分支对应一个 work tree， 别搞混。用完了 get work tree remove 删掉，保持干净。 vs code 和 cursor 都支持，同时打开多个目录很方便。对了，如果用 cloud code， 它原生就支持在 work tree 里工作，开箱即用， 从翻车到顺滑，就差一个 gta work tree。 ai agent 时代，这工具真的该会用。评论区入群领邀请码，额外还有十块钱体验金。少走弯路，从现在开始。

二零零五年，一个芬兰的天才因为被一家美国公司掐脖子，暴怒之下花了两周时间，凭一己之力写出了一个工具。这个工具今天仍然被全球超过一亿名程序员每天使用。你现在用的所有的 app， 刷的所有的网页，包括 ai 工具背后的代码，几乎都是用它来管理的。 他叫 kit， 这个芬兰人叫李纳斯托瓦兹，你可能没听过他的名字，但你肯定用过他的作品。他在二十一岁的时候，在赫尔辛基大学的宿舍里随手写了一个操作系统的那盒叫 linux。 今天全球超过百分之七十的服务器，安卓手机底层超算，甚至国际空间站，跑的都是 linux 系统。 可以说这个人随手就改变了世界。那他当年为什么如此愤怒？他愤怒之后造出来的 git 到底是什么？为什么今天连 cloud code 这样前沿的 ai 编程工具 windows 版本装前第一件事就是让你先装 git。 今天咱们一口气把这些都说清楚。在聊 git 之前啊，咱们先搞清楚一件事，程序员在没有 git 之前是怎么工作的。你可以想象这样一个场景，你跟你的同事小王一起修改公司的同一份项目方案， 你们分头改，改完再合并。你改了第三章，小王也改了第三章合并的时候发现完了，改乱了。谁的版本是对的，你们谁也不知道，于是就有了项目方案。最终版，最终版，小王，修改最终版，小王，修改，我又改了 最终版，真的是最终版了，最终版，真的是最终版，别再改了，你笑了，对吧？咱们都经历过的，现在我们把这个场景放大一百倍。 linux 内核是全球几千名程序员一起维护的超级项目， 每天有几百人在里面改代码，你改一行，他改一行，你们的改动之间可能有关联，也可能有冲突。如果没有一个工具来统一管理所有的这些改动，这个项目很快就乱成一锅粥了。那这个时候就需要一个版本控制工具来解决这个问题， 记录每一次改动，谁改的，改了什么，什么时候改的，出了问题，可以回溯，可以对比，可以合并。 get 就是 目前全球最流行的版本控制工具。你可以把 get 想象成一台代码的时间机器。你可能玩过存档的游戏， 在打 boss 之前，你习惯性地存个档，万一打输了，直接读档，从存档点重来，不损失任何进度。 git 干的就是这件事，只不过存的不是游戏进度，而是代码的每一个状态。程序员每完成一小块功能就保存一次。 这个操作叫做 commit， 也就是提交每一次 commit， git 都会记录下来。这就相当于给代码拍了一个快照。以后无论发生什么， 你写了新功能，但发现搞错了。你的同事不小心删掉了重要的代码，或者你的公司说把上周的版本给我还原回来。只要用过 git， 这些都不再是问题， 一个命令就可以让时光倒流。听到这里，你是否也好奇，林纳斯为什么要发明 git 呢？让我们把时间倒回二零零二年。 那个时候， linux 内核团队也在用一个版本控制工具，叫 bitkeeper， 这是一家商业公司的产品，但当时慷慨地给 linux 社区免费用了好几年。到了二零零五年，出事了。 linux 社区有个开发者尝试对 bitkeeper 进行逆向工程，说白了就是想破解它。 bitkeeper 公司发现了之后直接就炸了， 直接宣布停止对 linux 社区的免费授权。林纳斯听到这个消息的时候，估计内心也十分崩溃，他们几千个人每天都依赖这个工具工作，现在你突然说不让用了，普 普通人可能去求人呐，可能去找替代品呐，或者花钱买个授权呐。林纳斯他偏不，他直接撸起袖子自己写了一个，从开始到发布第一个可用版本，只花了十天。这就是 get 诞生的故事。二零零五年四月三号，林纳斯开始写 get。 四月六号， get 已经能管理自己的代码了。 四月七号， git 第一次提交，他用自己管理了自己的开发过程。四月二十九号， linux 内核正式切换到 git 管理。其实说了半天哈， git 只是一个工具，但是真正让它爆发的是二零零八年出现的一个网站 github， 你 可以把它理解为程序员的社交媒体， 他把 get 的 能力搬到了网上，还加了社交的功能。你可以在上面发布你的代码啊，让全世界的人都看到。别人觉得你的项目有问题，可以直接提一数，这就相当于评论区觉得你的代码可以改进，可以直接提 pull request， 缩写叫 pr， 把它的修改建议推给你审阅。这直接引爆了开元文化，全球的程序员开始在 github 上面开放自己的代码，互相学习，互相改进，互相协助。你今天用的很多技术， python 的 各种库啊，安卓啊， vs code 呀，或者 react， 几乎都托管在 github 上面，代码全部公开，全球任何人都可以参与贡献。 github 二零一八年被微软以七十五亿美元收购，这是软件史上最大的并购之一。今天 github 上面托管了超过四亿个代码仓库，活跃用户超过一亿。 你每天用的 app 背后，大概率有 github 上面某个角落里，某个陌生程序员贡献的代码。你可能会想， 我又不是程序员，我让 ai 帮我写代码，为什么我也得装这个东西呢？其实 ai 写代码并不是一次就成的，可能 ai 帮你写了一百行代码，你跑了一下，发现有个地方不对，你让 ai 改 它改完之后，另一个地方又出问题了，改了又改，改到最后哪个版本是对的呢？你自己都不知道了，就乱套了。 get 就是 ai 编程的保险，如果 ai 这次改坏了，没关系， 一个命令就回到上一个存档点，损失为零。所以 git 它相当于现代软件世界里的基础设施，就像是道路和汽车的关系。好的道理讲完了，咱们讲点实际的 git 到底怎么用？举个例子啊， 你开始做一个小项目，比如说做一个自己的个人网站。第一步，告诉 git 这个文件夹我要你管了，你在这个文件夹里打开终端，输入 git in it， 就 这一行时间，机器就开机了。 第二步，你写了一些代码，准备打包。例如你写完了网站的首页，想存一个档，你得告诉他这次我要把哪些改动放进去存档，也就是 get add 点。这个点的意思就是我们这次所有的改动都要存， 就像是收拾行李，你先把所有的东西都扔进箱子里。第三步，正式存档， get commit 横杠 m， 再加个引号， commit 就是 存党的这个动作，后面这个引号里面就是你给这次存党写的备注，以后你再回头看一眼，就知道这次存党干了什么。 这三步就是 get 最核心的工作流，也就是出使划打包行李，正式存党。第四步，把存党上传到云端，就像是游戏存党，可以上传到云端，防止本地数据丢失。 get 也可以把你的存党推到 github 上面， 这样就算你的电脑坏了，代码也不会丢。那有人会问了，现在这么先进，有了 cloud code 的 帮我写代码，还需要自己敲 get 命令吗？其实大多数情况下是不需要的， 程序员日常用的 get 命令其实就屏幕上的这几个。因为有了 ai 你 不用记，混个眼熟就行。 像 cloud code 的 这类 ai 工具，已经把 get 的 常规操作封装进去了，你跟 ai 说帮我保存一下当前进度， 它就自动地执行 add 和 commit， 你 说刚才那个改动有问题，帮我回滚，它就会找到上一个存档点还原。你不用去记命令，也不用记语法，你就理解 get 是 什么，在干什么就行了。 这样你以后再看到一些教程、视频啥的，再提到 get， 咱不就懂了吗？说了这么多，我们再回到开头的那个故事。二零零五年，林纳斯因为版权纠纷被掐脖子，用十天写出了 get。 他当时可能也没想到，这个分奴之下的应急工具，会在二十年后成为全球软件开发的基石，会在二零零八年因为 github 的 出现引爆全球。开元文化 会让非洲的独立开发者和硅谷的工程师在同一个项目上平等写作，会在 ai 时代成为 ai 写代码、管代码不可或缺的地基。这就是 get 一个悄悄支撑起整个数字世界的基础设施。今天的视频就到这里，让我们下期视频再见。拜拜。 mua 拜拜。

呃大家好，呃我是你们的朋友木瓜啊。今天呢呃想和大家聊一聊这个在 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， 谢谢大家啊。

哈喽，大家好，我是小庄老师啊，先点关注后收藏。今天教大家如何恢复拍腔里面的代码。什么意思呢？我们的拍腔不是经常会误删代码吗？其实不要着急啊，可以恢复啊， 比如说我这里有一个文件夹，我先用拍腔启动一下它， ok 啊，这启动好了之后呢？我看到啊，我这里面确实是有一个代码， 我不小心嘎啦没了啊，下面也点删除没了，其实在拍叉这里面进行删除，你回收站是恢复不了的啊，我也不用去看了啊，他恢复不了的， 这个时候怎么办？这个时候你不小心又把这个关了，比如说把这个拍叉关了啊，你急的就跳脚了啊，怎么办怎么办？不要着急啊， ok， 我 们重新打开一次啊， ok 啊，这个时候我们重新又打开它了，我们点击整个文件夹，没错啊， 右击有一个本地历史记录，我们可以去看一下你之前的代码啊，你可以看到啊，我昨天是五月十一号啊，还修改过这个代码，看到没 啊，不说错了啊，这个是整个文件夹所有的更改啊，不是当前的那个代码，你当前那个代码应该是看一下名字，应该叫这个是可以看到他进行的哪些修改啊？ 这个应该是我加了几行空行啊，在最后再看一下这个，这是删除过的啊，已经没有办法进行查看了啊，抱歉，刚刚这是我张老师的失误啊， 如果是已存在的这个代码，右击点那个历史记录会进行分屏比较。两边代码的不一样啊，不过我们当前这个代码已经删掉了，我们直接你可以恢复，你看一下你哪个时间段啊，想恢复哪个时间段，你就点右击有个还原就好了 啊，好了也就恢复过来了啊。还有一点，大家切记，就是你的这个拍卡一定是没有卸载过的， 如果你卸载过了之后，你重新下一个新的拍卡，完了之后你还想这样啊？没有用的，他没有缓存记录我，除非你你是没有卸载过才行的。 这个就是恢复代码，当然他不仅仅可以恢复代码，也可以恢复你文件夹里面其他的东西。大家刚刚也看到了，但是有一点需要注意的是， 如果你恢复的是一些 txt 啊， word 文档啊，或者是 excel 之类的，可能是空的啊，也可能是空文件啊，就恢复不了啊。代码当然是可以恢复的。 ok 啊，记得点个关注，点个收藏，拜拜，下节课再见！