啊？ VSCode 的冲突合并不是这样的吗？和 IDEA 也差不太多啊，只不过 IDEA 是三列，而 VSCode 上下两行

https://i.imgur.com/5QFcF1v.png

但其实如果已经 VibeCoding 了，直接让 AI 去解决冲突就好了。

https://i.v2ex.co/n3r4T901s.png

你姐结婚不算特殊原因，什么算特殊原因。老板的姐姐结婚吗？

@ZeawinL #71 ，社保可以转移，换城市工作也可以申请。
但是医保之类日常会用的保险，不可能因为我今天要去 XX 地看病了就把社保转移到 XX 地，毕竟需要在转入地正常参保缴费之后才可用。所以都是申请异地就医。

如果嫌贵，那就是在老家缴职工社保，然后看广州有没有可能申请在广州异地就医，但是报销的比例和类型肯定是不一样的。

说实际一点的，毕竟从各方面收缴上去的钱就已经不一样了。
就算医保全国通用了，老家医疗条件也是比不了大城市的，这个是跟城市的经济投入和人口规模直接相关的。
最终还是得异地就医。同样的转换一下不同城市的公共交通能力也有极大的差距。

头部城市的虹吸效应不会消失，除非社会可以发达到无限降低交通的时间成本和运输成本。

不用扯上户籍只会进水生火热，没啥好讨论的。直白一点就是地广人也多，收入水平和医疗资源也有很大差异。在没有好的解决方案之前就是地区自己统筹。

跨端框架看上去方便了，但只是把原本三个人的活变成一个人来干而已，前期低成本快速试错是可以的。
想要长期有好的用户体验和好的开发体验，最终就是拆回原来的多个独立 App 项目来干。

除非以后有一个大一统的客户端，不然怎么样都没办法避免需要多个平台开发的踩坑经验。一个开发 + AI 辅助，能干是能干，但是干不好。

其实就是入门的心智负担问题。
Vue 官方直接给了一个开发套路，以及常用周边库，所以可以很上手和接盘项目。遇到不知道了的东西有一个明确的地方可以找到解答。
React 因为没有一个官方推荐的套路，所以在上手和接盘的时候容易两眼一抹黑。在没有摸清开发套路之前，遇到的坑也只能在自己在互联网上漫无目的的去检索。

不知道你说的疲惫是指哪些，是通勤的累，还是周末无法休息需要陪伴家人的累。

如果是通勤的累，坐高铁 3 个小时多一点其实还好吧，而且高铁上面也是可以休息的呀。
要是自己开车，大哥咱真的坐高铁吧，便宜还轻松……

@nuansediao #32 ，飞机算上值机和飞行时间，其实也要 3 个小时了。而且时间段也没有高铁那么自由。其实感觉 OP 应该不是通勤的累。

https://i.imgur.com/agAJ0Rd.png 好难猜啊，为什么这些可以用 `v-bind` 绑定的事件都叫 [事件处理器属性]( https://developer.mozilla.org/zh-CN/docs/Web/HTML/Reference/Attributes#事件处理器属性) 呢。

- [#其他事件监听器机制 | 事件介绍 - 学习 Web 开发 | MDN]( https://developer.mozilla.org/zh-CN/docs/Learn_web_development/Core/Scripting/Events#其他事件监听器机制)

看你怎么用，如果只是轻量用，Github Copilot 是现在最具性价比的，毕竟只要 10 刀。
如果愿意折腾可以尝试 Gemini （现在应该还能找到白嫖的路子？）

一般如果不准备高强度用和 20 刀以上的费用，买 Cursor 和 Copilot 这样的就可以了，模型可以选择的面多。
Nano Banana 对于绝大部分一线开发来说都是尝个鲜。有最好，没有也没差。

然后模型被地区限制的问题其实很简单，代理调整一下就行了，不管是用 TUN 还是配置 DOMAIN-SUFFIX ，最简单就是在编辑器中开启 Proxy 。

----
如果不想花钱，那就还是用国产的那些编辑器就好了。日常简单用用还是可以的。

@Aleks #10 ，习惯一个好的工作流很重要。某一个调整的改动量大没关系，但没有小步提交/限制影响范围的话，可能会在发布环节造成困扰。

以前经常会遇到一些同事在开发的时候用一个提交混合了几个调整，或者用一个分支去开发多个功能或者调整。
如果有一些因为测试没通过，或者临时决定暂停开发。就会拖累其他的功能的正常发布。
虽然可以通过 rebase 调整或者拆分单一开发分支来解决。但是如果遇到一个提交中包含了多个调整的情况，那么就很麻烦了。特别是遇到两个功能还改到同一个文件，真的会麻烦。很多人不知道要怎么去操作。
所以在前期稍微麻烦一下，后面就算遇到问题也会容易解决起来。

-----
用简短的话去描述，大部分开发同事都是可以的，但遇到总结汇报真的是大部分开发同事的噩梦，很多还有数字要求。所以我一般在这个阶段用 AI 读 Git Commit 去写工作总结 😂

@Aleks #7 ，还好吧，就说一下这个是什么功能，或者修了什么 bug 就行了。简短明了，也不用说的很清楚。
按照格式第一行是 title ，第三行开始才是 details 。

毕竟在写代码的时候其实就是知道自己现在在干什么的。很多时候我可能都会先写好 Commit Message 再开始写代码。因为叉出来的分支就已经是 `fix/dashboard-charts-style-issue` 的形式了

大部分情况都是简单的 `fix(dashboard): 修复 XX 图表的显示问题`。
如果没有特别需要备注的就是直接提交了，如果有一些特殊备注才会另起一行单独写内容。
```
fix(dasboard): 修复 XX 图表的显示问题

- 修复遇到页面缩放时图表文字过大；
- 修复多图表标题未联动；
```

但其实这些 details 应该在提交的时候拆开来提交，最后在 squash 的时候，再把一些小步提交的信息放到 details 中，然后标题就是简单的概括成是 “fix(dasboard): 修复 XX 图表的显示问题”。

@Cu635 #14 ，只是说试试看万一呢，毕竟现在还没有替代品。从社区反馈来看 JectBrains 系列的产品要比 VS 好用。

听说要 $2,400 所以完全期待不起来……

还有“三星计划明年为苹果大规模生产 1100 万块内折叠 OLED 显示屏，以及同等数量的配套外屏”的供应链传闻。

> 辛辛苦苦写完了一天的代码，到了提交的时候，大脑却一片空白。

所以才要小步提交，干完一件事就提交一次，而不是把一天所有输出的内容在一个 Commit 中一下子全提交上去……
如果嫌提交的 commit 太多了，最后在 MR/PR 之前用 squah 把相关的 commsit 合并起来。

招聘 APP 如果你海投很大概率会被平台标记。

https://i.imgur.com/e0aw4gU.png
🥺 $199 ，打扰了

https://busy.bar/shop

注册的原始邮箱发邮件给 [email protected] 请求取消 2FA 验证