@noobakong @kongkongyzt @davelm @tangyujing99
哈哈哈 操 原来 [不明白] 播客是 一个播客名字
傻逼了 忽略我吧哈哈哈 尼玛真尴尬

@kongkongyzt
@davelm
不谈播客内容本身质量很高 能让人启发收获很多外 就单纯的播客形式而言
可以把博客当作生活中的背景音
不用像视频图文一样要付出很大的精力去看去理解

比如周末在家打扫房间 放个博客
通勤环境很乱 看手机图文或者视频很累 就可以用听的方式

还有一点是播客一般都是长内容
停下来一期平均一两小时
很轻松的能锻炼人对内容吸收的耐力

我也最近俩月才开始听博客
个人感觉下来收获还是挺多的
对世物的认知会更全面一点

得意忘形

之前也看过 17 楼的视频
社交壁垒 只能选小天才咯
如果真的加不上好友
无法和别人聊天
被别的小伙伴的圈子拒之门外
对于一个小朋友的心里打击太大了

刚看完阿凡达看到了这个贴 也是咸鱼随便找的 美团 90 咸鱼 55 3 分钟省三四十块钱

a 流程的过程中可以加一个公共分支
比如从 mater 最新分支 建一个 版本的公共分支 20221216 分支

然后开发者 A ，开发者 B ，开发者 C 从 20221216 切各自的功能分支进行开发
开发者 A 切分支 feature/aaaaa
开发者 B 切分支 feature/bbbbb
开发者 C 切分支 feature/ccccc

开发完毕 下面 ABC 要做的就是把代码合到 20221216
怎么合 是有讲究的

为了保证 ABC 各自功能的 commit 合到 20221216 后是线性的
如何合 有讲究：以 A 为例
在 feature/aaaaa 分支 rebase 最新的 20221216 分支 保持 A 的 commit 始终奠基在最新的 20221216 分支上
然后再在 20221216 分支 merge feature/aaaaa

这样的话 20221216 分支上始终是一条线性的直线 各自的功能 commit 紧凑在一起 非常清晰

然后就是测试 预发 生产的发布了 因为大家在 20221216 各自 merge 自己的功能分支时 都是解决了冲突的
所以 20201216 分支 merge 到 测试 预发 生产分支的时候 是没有任何冲突的

这样是不是就会清晰很多
---------------------------------------------
相关的几个点：
1. 弄清楚 rebase 和 merge 的区别，有的团队只会 merge 导致分支混乱 和织蜘蛛网一样 难免会有各自冲突，有的一个冲突要解决 n 遍 丢代码更是家常便饭

2. git push -f 慎用 但是必要时要用

3. git 操作过程中不要靠猜 每个人 要清晰的知道自己敲的每一个 git 命令 不能明确自己在做什么的时候 立即停止 请教熟悉 git 的人

4. 公共分支 的代码 自从建立之后 原则上应该都是各自的个人开发分支 merge 过去的产物

5. 善用 git rebase -i 交互式命令 去整理自己的 commit

没结婚 情侣同居 一样的问题

@Vegetable 草 10 点多刷到你的帖子 点进去 刚出来 这玩意是真不能碰

最近也在研究这块的内容 可以交流下么楼主 wx dnZ2YWtvbmc=

如无必要 勿增实体 我选 Alfred

换个角度
你父亲虽然出去还知道戴口罩
有很多喜欢天天出去不戴口罩的老父亲
劝他的同时 也帮他多屯点口罩

今年的数学是真的。。妈的 我也要找工作了

20 届全职实习能转正么

楼主可以先手机拍摄学技术 学后期
如果到了要求设备的点
再考虑专业设备
到那个时候你也懂了
设备直接一步到位
---------------

但是大概率是拍着拍着就。。 放弃了

我是今年的考研 er
所以有点担忧三年后的互联网发展

虽然这种东西谁有没有定论
还是想听一听前辈们的看法

@saluton 是这个理 也不知道互联网还能疯狂纪念

@Torpedo emm 30k 是算好的了 但是 20k 真的是白菜（参考牛客

@Nicoco 赞同