看区域, 各个区域都必然有一家不行的, 还不重样~

啊, 我下面有隔板... 对面还没人

讲个悲剧: 我没买到有座的票, 7 个小时的无座.

我干过两件傻事, 第一件是下载今日头条, 评论了一下, 然后被喷卸载.
第二件是又下了一次, 看了看文章下面的评论氛围, 卸载.
所以我在想, 其实真的有那么多人评论么...还是都是机器人啊

啊, 让我想起了有一年大雪, 路面都是压实了的雪, 像冰一样滑, 我骑电动车, 我媳妇和另外一个人跟着我前进, 我到路口一个车出来, 捏了一下车闸, 然后就开始左右打滑, 我没有撒开车闸, 双脚放到地面上支撑, 尽力保持平衡, 最后车子转了一圈, 稳定的停下来了, 我媳妇在后面向右侧上人行道, 也停下来了, 最惨的是后面那人, 学我, 没学好...

我教你, 喂? 对方:xxxxxxxx, 你静等一会, 然后喂?喂~喂?没声啊...挂掉

@msg7086 啊, 好的, 谢谢~ 果然是很灵活, 了解了另外一种思路.

@msg7086 我大概看懂了, 不知道你们有没有遇到这样的情况, 在 AB 都 merge 完之后, 由于排期更改, A 需求暂定不随着下次发版发出去了, 这个时候 B rebase 过来的 commit 会不会带上了 A 的 feature 呢? 如何保证的下次发版仅包含 B 的 feature 的呢?

可以, 不影响他人, 领导也不管, 没问题, 我的建议是不要洗冷水澡, 尤其是从头上冲下去那种. 相信我, 等你岁数大点, 就知道为什么了.

@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 了...