GeruzoniAnsasu

排除 merge.

merge 绝对不能在双向相互合并的两个分支上进行，否则大概率丢代码。 双向相互合并是指同时存在 D->M 与 M->D 两个方向的合并（ merge. cherry-pick 会产生不同 hash 的 commit 所以不会踩三路合并丢代码的坑）


一般这种岔出去比较远了又想统一回来的场景最好的方法是 squash + 重新分岔，但有个缺点是历史可能会丢（因为重新分岔后新的 dev 或者新的 main 就不是原来的了，在非直属继承的那个分支上只能看到一个很大改动的 squash commit ）不过 git flow 发展到你现在这个场面就是没严格遵循或根本就没定好清晰的规范导致的，所以大概率历史对你们来说也不是那么重要，squash 掉也不会不可接受。


我们过去的实践是 dev 分支必须包含主线所有分支上的所有改动，包括 bugfix 但不包括 release-featureA / release-featureB 这种版本特化的 commit. dev 永远保持线性历史，即它不会接受其它分支的 merge ，只接受 rebase. 这样一来 bugfix 也好，feature commit 也好，都会拍平成对等的 commit ，不会结出 merge 蜘蛛网。feature 分支在并入（ rebase ）到 dev 上之前 reviewer 会要求一定程度的 squash, 保证一个 commit 既不太大没法 diff 也不至于太琐碎 spam 历史线。 然后 master 只作为 tag 使用，打 tag 时往 master 上 merge 一份（ dev->master ）打在 master 上。只要保证 master 上不自行产生 commit ，只接受 dev 的合并，它就永远不需要解决冲突

说了这么多， 只字不提你「心目中的原型」的关键定义是什么


- 是一个可交互的「类产品」页面？
- 是其它维度（数据结构、逻辑流程）的抽象？
- 是一个可参考的包含核心 story 的 demo ？（例如竞品或示例代码实现的）


我能不能作为产品经理发难说 sb 开发人话都不会说连他要什么都表达不清楚呢，我觉得从你表达方式和情绪来看你们之间的沟通是完全无效的。

- 拿着一千万存款自己瞎捣鼓量化策略，然后每周去收一套房的租金

- 联合一帮几十年的老关系搞投资，名义上挂个 IT 公司的顾问或者董事，实际上只需要出钱收钱看账本

- 不在国内

> 我就想知道，现在程序员的群体里，都已经这样了么？话不能直接说，沟通不能简洁有效 什么都得长篇大论，生怕

这个主题有 2138 个字符长。

BWV 988
BWV 1004

你就不能下个 VS 创建个 winform 项目看一眼吗（恼

？？？？？


还真有没拖过控件的桌面 GUI 程序员？

上手发现两个问题：

- 快捷菜单（ alt+space ）不能 esc 取消
- 全屏状态无法呼出悬浮窗口所以在浏览器的典型场景中这个选字翻译无法工作

其实我不是很喜欢抢着白嫖别人会员，因为总有一种义务感，需要帮别人真的评测出什么东西，提出有建设的观点才好意思试用。 但我确实又比较想关注一下这类产品的发展情况，以及隔壁帖子看两天的回复量也远未达标，确实能算见者有份，那也不算跟别人抢了，所以还是回复一下吧。 希望有机会能一起讨论下产品方向的东西。