粉丝1.5万获赞8.6万

kidlab 和 sdn 都是用于项目版本管理的软件,不过我用 sdn 的时候更多, 但在接手的项目里仍旧有一部分需要用 deed。 今天就教大家如何创建和删除 good lab 项目。在 good lab 的控制台上点击 create a project, 开始创建一个新项目。输入项目的名称建议是拼音或英文, 必须选择一个分组,分组的名称通常就是你的登录账号仓库类型默认是 private, 此处为了方便演示,改成了 public, 点击 create project, 完成项目创建。 gila 默认的分支名称 称是 main, 并不是以往常用的 master, 这是因为维护 gitlab。 本人认为 master 有主人的意思,而他们不喜欢这类带有奴隶历史的词汇。我觉得做出这样考虑的人挺有意思。 因此最新的 get up 使用 main 作为默认分支名称。我在介绍下如何在 get up 中删除项目。 打开项目的 settings, 再点击 general, 将页面往下拖动。 再展开的贩子,继续往下拖动页面,将页面拖动到底部,可以看到 得利 project 按钮,点击得利 project 按钮, 根据提示在此处输入确认词语, 最后点击 yes, delete project 按钮,这样就删除了项目,学会了吗?

大家好,我是 night killer, 欢迎观看我的 night killer dewalbs 首渣视频开视频是 night killer dewalbs 首渣电子书的配套视频。在上一期视频我们学习的是 gelab 项目管理,今天我们学习的内容是多任务并行开发。 为什么要做这期视频呢?这是所有创业团队跟中小企业必经之路。其实并性开发并不复杂, 但对于创业团队跟中小企业来说,这是一件非常复杂的事情,因为在团队当中没有人参与过这样的开发。那么能不能从大型企业挖一个人过来就解决问题呢?这要看你挖过来的人 他是什么样的岗位,如果是一个基层工作岗位,那么他是执行者,他也不清楚上面是怎么管理的,也就是说他只见过猪跑,并没有吃过猪肉。 其实软件项目管理、并行开发这些就如同一层窗户纸,一捅就破。本期视频学习的内容是多任务并行开发, 要实现多任务平行开发,需要三点,第一点是任务的分解,第二点是提供配套环境,第三点就是分支的合并。任务分解就是讲项目化整为零,拆分成一个一个任务,然后只派到指定的人去执行。 认得夫的分解需要注意几点,就是叫尽可能的结偶,尽量避免交叉,要理清他项目之间的依赖关系,避免出现一些循环。 在项目分解当中遇到最大的问题就是项目的藕和跟依赖关系,说白了就是各项功能的前后开发顺序。 产品经理在设计产品的时候就可能会影响到任务的分解,例如 ui 交互跟业务逻辑的冲突,也就是说 ui 上的两个按钮点击顺序就有可能影响到任务。分解, 虽然都叫产品经理,但是产品经理也是分几个档次的,分别是战略型产品经理、业务型产品经理和功能型产品经理。而初创团队跟中小企业通常是功能型产品经理为主, 功能性产品经理都相对比较年轻,功能性产品经理通常是比较年轻,没有在这个行业当中做过,所以对业务不是很熟悉,所以就无法从宏观的角度去规划 产品,也就是理清他们之间的业务逻辑关系。同样,架构师我也把它分成了三个层次,分别是企业架构师、业务型架构师跟功能型架构师。跟产品一样,中小企业通常是以功能型架构师为主, 产品经理跟架构师的大局观这个观点在我的多维度架构视频当中谈到过,这里我就不读一遍了。 要实现并行开发,也就是多个任务同时进行,那么 我们就需要一套配套的软件跟硬件环境。配套的环境是指开发跟测试环境。我们以生产环境为例,最小化实力、最小化节点满足运行项目的环境要渐渐减少。环境之间的差异, 差异包括了软件环境、硬件环境、网络环境,还有资源的配置以及应用软件的安装配置差异。 需要多少环境,需要根据我们项目规模而定,通常我们至少有三个环境,分别是开发、测试跟生产。 如果项目稍微大一点,我们还会增加一个用户交付测试环境和功能分支测试环境, 每个环境又对应了版本库当中的对应分支。通过持续集成跟持续部署,我们只需要向相应的分支当中合并代码, 就可以完成环境的部署。例如我们向开发分支当中提交代码,就会自动部署到开发环境。测试分支是不允许提交代码的,只能用于合并。 测试分支的部署通常由测试人员手工部署,我们会在持续的集成当中设置一个按钮,点击一下,自动部署到测试分支。开发环境跟测试环境两台夫妻是放在办公室的, 用户交付,测试环境跟生产环境是放在云浮器上的病性开发,需要开发人员遵守严格的合并流程。我们会对分支做一些保护,就是有些分支是不允许提交代码的,只允许合并。 例如当前屏幕列出的五个分支,只有开发分支是允许提交代码的,其他分支都不允许直接提交代码。太个标签是只读的,他 只能被创建,不能被修改。最后讲一下功能分支,任务分为分解之后,就会分配给每个开发人员。开发人员进入一题,然后创建功能分支,将工程分支代码克隆到本地,然后进行开发工作,开发完毕以后进行提交。 提交之后,功能分支的部署是需要测试员手工部署的,因为开发分支是共用的,如果持续集成跟持续部署进行自动部署以后就会相互覆盖, 这是需要开发人员讲这个议题的。标签改为测试,并且只拍给测试人员。测试人员接受到这个任务之后,进入持续继承持续部署菜单,点击部署, 当流水线运行完成之后,该功能就被部署到了功能测试服务器。接下来就是紧张 测试工作了,当测试完成之后,如果有 bug 会打回给开发人员,如果没有 bug 就把它变为挂起的状态。 并性开发,我们会产生很多功能分支,开发完成之后就变成挂起的状态放在那里,当我们需要上线的时候,就通知开发人员将功能分支合并到开发分支进行一次集成测试。 测试过程仍然是发现 bug 就修复 bug, 如果测试通过的话,就将开发分支在合并到测试分支进行第二轮的测试。测试分支 ok 之后就是交付测试环境跟生长环境的升级了。 最后总结一下功能分支的操作步骤,首先创建议题分配给指定的开发人员,然后开发人员从开发分支创建功能分支, 获取功能分支的代码,然后进行开发提交。最后测试通过以后,将功能分支在合并到开发分支, 一切都完毕之后关闭题,下一期视频我们会重点演示分支的合并。 今天录视频比较晚,所以有点困,经常说话短路。关于病性开发,今天就先讲到这里,有什么问题可以给我,在评论区留言,喜欢我电子书跟视频的小伙伴请关注我,给我点赞转发,谢谢观看!

代码写完了,测试全率了,审查通过了,然后呢?很多人就停在这里,东西能跑就行,分支留着就留着,下次再说。但 superpowers 告诉你,这不是结束,收尾和闭环才是专业和业余的分水岭。 这是 superpowers 深度教程的最后一集。 e p 八,今天讲最后两个技能, finishing a development branch。 完成开发分支,还有 writing skills 创建你自己的技能。而且咱们会在结尾回顾整个系列的八级内容,给你一张完整的十四技能全景图。 先说第一个技能, finishing a development branch 什么时候触发。当你所有任务都做完了,测试全率,代码审查也通过了, ai 会自动调用这个技能。它不再问你接下来做什么,而是直接给你四个明确的选项, 每个都有对应的清理流程。第一个选项,本地合并,这是最常用的。如果你的分支代码已经准备好进入主分支,选择 merge to main a 哀会先确认没有未提交的更改,然后合并清理工作区适合功能已经完全完成,测试通过,不需要他人审查的场景。第二个选项,推送并建 pr。 如果你的项目有 code review 流程,或者你想让团队成员看看你的改动, 选这个 ai 会促使分支到远程,然后创建 po request 适合多人协助项目,或者你想留一个正式的审查记录。 第三个选项,先保留。如果分支上的工作还没完全做完,或者你在等后端接口,等设计稿确认,但你当前想切换到其他任务,选这个 ai 会把当前状态保存好,让你干净的切走,不留半成品污染工作区, 这里有一个核心铁律,不允许半成品留在工作区。 superpowers 要求你每次结束工作的时候,要么把东西收尾干净, 要么清楚地标记为进行中,但先保留,不能有那种你也不知道这个分支是干嘛的状态。第四个选项,丢弃。如果这个分支的实验方向错了,或者你决定不继续了,选择丢弃, ai 会直接删除分支,清理所有相关的工作区文件, 不纠结、不内耗,干净利落,适合那些试试看但发现走不通的探索分支。这四个选项覆盖了所有收尾场景,关键不是选项多,关键是每次结束工作的时候,你必须选一个,不能什么都不选就跑了, 这就是闭环,每一次打开的工作都有一个明确的关闭动作好。第二个技能, writing skills。 这是 superpowers 十四个技能里最特殊的一个,它不是一个给别人用的工具技能,而是一个教你创造工具的原技能。 当你在 ai 编程中反复做同一类事情,比如每次提交前都要运行某个格式检查, 每次创建新文件都要套用某个模板,每次部署都要执行一串固定命令,这时候你就应该把这个流程写成技能。一个技能由四个部分组成,第一, s、 k、 i、 l l 点 md。 技能的入口文件 定义触发条件,当用户说了什么关键词,或者在什么场景下,这个技能会被自动触发。第二, c l、 a、 u、 d、 e 点 md。 给 ai 的 行为指令包括铁律、工作流步骤,不该做什么。 第三, references 目录放参考资料、文档、规则、文件视力。第四, scripts 目录放可执行的脚本, python 或 shell 都行。创建技能的时候有一个核心铁律,好技能向法律条文精确无歧义,可执行。 你说代码格式要好看, ai 不知道怎么执行,你说用 preiter 默认配置格式化所有 ts 和 t s x 文件, ai 就 知道怎么执行了。定义触发条件有两种方式,一种是关键词触发,用户说了包含某些词的话,既能自动激活。另一种是场景触发, 在某些文件类型被创建或者某些 get 操作发生后,技能自动激活。好的触发条件要精确,但不要太窄,太窄了,技能永远触发不了,太宽了,技能在不该触发的时候也跳出来。 技能的工作流要写成步骤,每一步写清楚在什么条件下执行什么动作,预期的输出是什么,出错了怎么处理。不是写散文,是写操作手册。纸上谈兵,不如看个实力, 咱们来做一个技能,叫代码格式化检查,需求是每次提交代码之前,自动检查所有 type script 文件的格式是否符合 prety 规范。第一步,创建 s k, i, l, l, 点 m d, 开头写出发条件,当用户说格式化检查,检查格式 format check 或者执行 git commit 之前触发本技能。 第二步,写 c l, a, u, d, e, 点 m, d, 这是 ai 的 行为指令。核心铁律写清楚, 只检查不改写,如果格式不对,报告差异,但不要自动修改,除非用户明确要求。工作流分三步,先用 npx printer check 扫描文件,如果发现不符的,列出文件和行号,最后问用户要不要自动修复。 第三步, references 不 需要放,因为这个技能很简单, scripts 可以 放一个 shell 脚本,把 prettier check 的 命令封装好,方便直接调用。 这个例子很小,但它展示了技能的核心,把一段你反复做的事定义成一个结构化的 ai 可以 自动执行的流程。你今天写一个小技能,明天就多了一个不知疲倦的 ai 搭档帮你盯着格式。 最后一步是验证,建完后自己用一次,看看触发是不是准确,工作流是不是顺畅,有没有奇异的地方。好的技能靠迭代不是一蹴而就。好技能讲完了,现在咱们站在终点,回头看看这八级走了多远。 ep 一, 全景认知咱们知道了 superpowers 是 什么,不是工具,是方法论。七步强制工作流十四、技能覆盖从需求到收尾的全链路,核心理念四个字,流程优先。 ep 二, brainstorming 设计先于代码 hard gate 硬门禁,没有设计文档就不许写代码,没有例外。九步清单, 从探索上下文到用户审批,每一步都不可跳过。 e p 三, writing plans 完美实施计划,铁律是 t b d 和 t o d o 一 律禁止考计划向乐高积木,每个步骤完整独立可验证。 e p 四, work trees 加 sub agent 工作区隔离与多代理开发。 get work tree 让每个功能独立运行在一个干净沙箱里。 sub agent 让多个 ai 代理并行干活, 两轮审查才通过。 e p 五, t d d 测试驱动开发红绿重构循环,没有失败的测试就不许写实现代码,先想清楚这个功能要验证什么,再写怎么验证, 最后才写怎么实现。 e p 六, systematic debugging 系统性调试四阶段调查分析、修复验证。没有根音分析就不许动手改 bug 不是 碰运气修,是定位到根音再修。 ep 七, review and verification 代码审查与完成前验证,自动派遣独立的审查代理。 critical, important, minor 三级分类,完成前最后一道关卡 verification before completion ep 八,就是今天分支收尾与技能创建四个收尾选项,保证每次工作都有闭环。 writing skills, 让你从技能的创造者把这八级串起来,就是 superpowers 的 十四技能全景图。 他们不是十四个孤立的工具,而是一条完整的链路,从需求到设计,从设计到计划,从计划到实施, 从实施到测试,从测试到审查,从审查到收尾,每一步都有明确的入口和出口, 每一个环节都有不可跳过的质量关卡。最后了点行而上的 superpowers 的 核心哲学三句话,第一句,不是更快,而是更稳。 ai 已经够快了,你不需要让它更快,你需要让它更可靠。 superpowers 所有技能的目的不是加速 ai 写代码, 而是保证 ai 写的代码是经过思考的,经过验证的,经过审查的。第二句,不是更聪明,而是更守规矩。 ai 已经很聪明了,但他没有判断力,他不知道什么时候该停,什么时候该检查,什么时候该问。 superpowers 给 ai 的 不是更多智商,而是一套什么时候做什么事的纪律,纪律写在技能里,技能就是 ai 的 操作规程。第三句,流程释放能力。 很多人觉得流程是束缚错了,流程不是束缚,流程是释放。当你不需要每次都决定下一步做什么, 当你有一套标准工作流可以依赖,你的大脑就被释放出来,去想真正重要的事情。 需求对不对,设计好不好?方案优不优?流程处理怎么做?你处理做什么和为什么。这三句话就是 superpowers 全部十四技能背后的底层逻辑。 八级十四技能,一条完整的 ai 编程方法练录。如果你是从一 p 一 一路看过来的,现在你已经不是一个用 ai 写代码的人了,你是一个知道怎么让 ai 在 你设定的框架里,按照你定义的流程达到你要求的标准的人。这两者之间的差距就是 professional 和 amateur 的 差距。 superpowers 在 github 上已经有十五万 star, 因为它解决了一个真实的问题, ai 编程的随机性。它不是让你多写代码,是让你少写反攻。当然,这个系列结束了,但你的 superpowers 之旅才刚刚开始, 因为你今天学会了 writing skills, 创建自己的技能。从今天起,你遇到的每一个最好每次都这样的操作,都可以变成你的专属技能。 你的 superpowers 工具集会随着你的工作越来越多,越来越好,别忘了点赞收藏这个系列,如果你觉得有用,分享给那些被 ai 编程随机性折磨的朋友。 superpowers 深度教程八集全部完结,咱们后会有期。

一个让程序员爱不释手的宝藏神器! an o g tub 主要包括 joba c q 拍翻等流行语言的各种入门的项目工具、书籍、学习心得笔记,内容以乐刊的形式更新,不仅有项目的名称和链接,还有点赞数和关注量。不知道研究哪些项目可以拿到高薪的小伙伴们,赶紧去畅游 g t t 吧!
