 |
netabareV2EX 第 125600 号会员，加入于 2015-07-05 07:57:57 +08:00 |
| 发现自己的 commit 标题和内容越来越长了 程序员 • netabare • 57 天前 • 最后回复来自 netabare | 31 |
| Arc 浏览器用 Swift 来实现，是否意味着用 Swift 来写跨平台软件的未来也不远了？ 编程 • netabare • 119 天前 • 最后回复来自 DTCPSS | 5 |
| 这年头，参与开源项目还要付费才能参加了吗 程序员 • netabare • 150 天前 • 最后回复来自 netabare | 50 |
| 打算把 blog 从 hexo 迁移出去，不知道 nuxt content 合适吗？ Blog • netabare • 150 天前 • 最后回复来自 netabare | 19 |
| 感觉最近 Safari 好像很不稳定，不知道为什么 Safari • netabare • 171 天前 |
| 用 SwiftUI 做了个简易的找工作记录用的 App
1 分享创造 • netabare • 268 天前 • 最后回复来自 sherlockwoo
|
2 |
| 往 SwiftData 的 context 里面塞东西的时候该怎么正确处理 relationship 的关系？ iOS • netabare • 281 天前 • 最后回复来自 hogus | 1 |
| 疑似发现了 Swift 的 NavigationStack 和 NavigationPath 的 bug？ iOS • netabare • 280 天前 • 最后回复来自 alexcding | 5 |
| 为什么很多个人 blog 都会弹 cookie 提示 Blog • netabare • 288 天前 • 最后回复来自 renfei | 4 |
| DHH 移除 TypeScript 后的反静态类型主义营销号刷屏有点让人绷不住
1 程序员 • netabare • 335 天前 • 最后回复来自 cailinunix
|
64 |
netabare 最近回复了
13 天前 回复了 pythonee 创建的主题 › 程序员 › 你遇到过哪些比较难理解的编程语言概念 |
DDD 和六边形那套东西，函数式编程的概念反而没什么难的
36 天前 回复了 keepRun 创建的主题 › 程序员 › 分享些小红书有关计算机相关或有趣的博主 |
「小红书」和「有趣的计算机」这两个词居然可以在同一句话里出现吗。
扫了一眼基本上也都是些大企业老板、富哥富姐或者产品经理之类的，很好奇这些 title 跟「有趣的计算机」有什么联系？
要看彩虹屁我还不如去推特看马斯克喷人去。
扫了一眼基本上也都是些大企业老板、富哥富姐或者产品经理之类的，很好奇这些 title 跟「有趣的计算机」有什么联系？
要看彩虹屁我还不如去推特看马斯克喷人去。
38 天前 回复了 happydayandnight 创建的主题 › 投资 › 割肉卖房 110 万，投资纳斯达克血亏 10 万，现在 100 万如何投资实现年化 5% |
年化 5%的方法，大概你标题里面已经给出来了。
48 天前 回复了 mainjzb 创建的主题 › 程序员 › 对接群里看到别的公司发的代码截图，有点绷不住 |
头一回见到把类型、参数名和注释垂直对齐的格式，这种格式要是稍微改个参数名感觉要维护起来会很难受
52 天前 回复了 shinonome 创建的主题 › Python › 函数的返回建议是 list|[] 还是 list|None 呢 |
能不返回 None 就不要返回 None
54 天前 回复了 fallen42 创建的主题 › 程序员 › 怎么在不恶心自己的情况下进行防御性编程 |
首先，这不叫防御性编程
57 天前 回复了 netabare 创建的主题 › 程序员 › 发现自己的 commit 标题和内容越来越长了 |
@UncleCAT4 是指大四大五啦，法国的大学学制是五年的。
@roundRobin 主要也是看团队里面并没有把 PR 细化到这个地步，一般一个 issue 就是一个 PR ，如果大家的 commit 和 PR 都很细的话我肯定是跟着他们做的。GitHub 上的个人项目倒是不会做那么细就是……
@Contextualist 好建议，我倒是还没太熟悉 rebase 的用法，感谢提醒。
@tolbkni 注释我感觉问题在于后面改来改去的很容易就会丢掉上下文……
@GeruzoniAnsasu 示例这个确实不太好，不过一方面也有看团队里一个 PR 也就几个 commit ，我自然会倾向于避免上来就推几十个 commit 的巨型 PR ，所以也会有想要把 B 「虽然是不同的事情但在功能上相互联系的几件事组合在一起」的倾向，尤其是发了两次包含连续四五个 Refactor 的 PR 之后。
@Scarb 这个模版倒是不错，有时候我感觉我也有点像在往这方面靠。
@janus77 会的，会先看 git blame 找出 commit 的历史记录，问题是一般来说别人都是简单的一句话甚至没有提到他的代码意图，所以我才感觉如果有个 commit message 会清晰很多。
@roundRobin 主要也是看团队里面并没有把 PR 细化到这个地步，一般一个 issue 就是一个 PR ，如果大家的 commit 和 PR 都很细的话我肯定是跟着他们做的。GitHub 上的个人项目倒是不会做那么细就是……
@Contextualist 好建议，我倒是还没太熟悉 rebase 的用法，感谢提醒。
@tolbkni 注释我感觉问题在于后面改来改去的很容易就会丢掉上下文……
@GeruzoniAnsasu 示例这个确实不太好，不过一方面也有看团队里一个 PR 也就几个 commit ，我自然会倾向于避免上来就推几十个 commit 的巨型 PR ，所以也会有想要把 B 「虽然是不同的事情但在功能上相互联系的几件事组合在一起」的倾向，尤其是发了两次包含连续四五个 Refactor 的 PR 之后。
@Scarb 这个模版倒是不错，有时候我感觉我也有点像在往这方面靠。
@janus77 会的，会先看 git blame 找出 commit 的历史记录，问题是一般来说别人都是简单的一句话甚至没有提到他的代码意图，所以我才感觉如果有个 commit message 会清晰很多。
59 天前 回复了 netabare 创建的主题 › 程序员 › 发现自己的 commit 标题和内容越来越长了 |
@roundRobin 对一个 PR 来说，这个 algorithm 可能只是其中一小部分，issue 里面提到的东西经常需要改蛮多东西的，而且产品那边也可能也会反复需求。
Select Language