@msg7086 感谢回复. 我看了你的图, 你们的 tip 分支是作为什么样的角色存在的呢? 是每人在自己的 feature 开发, 然后 rebase 到 tip, tip 有更新后 rebase 完 merge tip 到自己的 feature 继续开发, 要发版时, 由 tip 创建 release 发版. 这样的一个流程么?

@Eoston 啊, 成功可能是因为本地认为 dev 已经是最新的了, 队友做 A 向 dev merge 的时候, 当成了更改吧.或者如果队友使用了 source tree, 会有丢弃更改的功能, 踩过一次坑

@Eoston 通过 checkout 某一个正确的提交恢复后, 强行 push 回去, 可以解决这个问题么? 如果之前的 commit 没有被覆盖的情况下.

@msg7086 啊, 我目前的做法是 feature merge into release, 产生冲突解决会写改动, 不过大部分服务是我一个人维护, 都还好, ABmerge 方向不同, 使用的算法不同这点, 会导致结果不同么? 另: 做 rebase 的时候, 你们是 feature onto release,然后再 merge 的这步, merge 方向是怎样的呢?

PS:feature 是我自己的新功能分支, release 作为大家共同编辑的分支~

@PazuLee 啊, 感谢, 其实是我队友的问题, 我实际不是这样操作的~只是用 AB 做了模拟

@PazuLee 有没有 commit 顺序对这个影响的文章可以研究一下?

@iSecret A 是由 B 拉出来的, 在 A 开发的过程中, 队友向 B 做了 PR, 我 A 向 B 做 PR 的时候, 就冲突了, 但是我反向 BA 的时候, 就 success 了...

看一下 GC, 之前我有一次是因为频繁 gc, 导致的吞吐量下降

啊, 我还挺喜欢的...

凉是凉不了的, 毕竟还是有人买的起啊~

打水印, 要清晰, 要大~
否则... 我数数啊, 爬虫解析 DOM 获取 URL, 模拟调用接口, 模拟截屏, 实在不行, 我还能用手机拍...

所以终端到底支持什么命令 [:捂脸]

因为他们没有库房呀~