
1 iConsLii 2019 年 6 月 30 日 1、公司的项目跟着公司规定走吧 |
3 leo108 2019 年 6 月 30 日 你自己的分支怎么 rebase 都无所谓,但是公共的分支(比如你说的 company_trunk )执行 rebase 操作的话……没被同事打死真是幸运呢。 |
4 Xbluer 2019 年 6 月 30 日 |
5 WhoCanBeRich OP @iConsLii 好的 谢谢老哥! |
6 WhoCanBeRich OP @leo108 好的哈哈 那我还是用 merge 啦 谢谢你啦 :) |
7 WhoCanBeRich OP @Xbluer 好的 谢谢你啦! |
9 leo108 2019 年 6 月 30 日 |
10 Xbluer 2019 年 6 月 30 日 @leo108 #9 比如说本地分支 feature/abc 跟踪远程分支 origin/feature/abc。 在本地 feature/abc 上直接开发并提交到本地,执行 pull --rebase 可以将本地修改的内容在最新的 origin/feature/abc 最新的版本上衍合,然后执行 push 操作就可以,并不需要 push --force。 提交日志只有一条直线,所有开发者的开发活动像是依次顺序完成的,简洁明了。 |
11 wsxyeah 2019 年 6 月 30 日 via iPhone 你的 company_trunk 是指 develop,master 这类分支?这类通常会设为 protected branch,是不允许 push 的,只能通过 mr 合进去。 你自己的 feature 分支当然可以 rebase。 |
15 WhoCanBeRich OP @leo108 应该不用 force push 吧,我已经 git fetch 过了,也就是本地的 company_trunk 与远端的一致了 |
16 leo108 2019 年 7 月 1 日 @WhoCanBeRich 这个就是时间差问题了,假如你在处理冲突时花了较多的时间,那么就有可能出现别人 push 了新的 commit 到远端分支。 你的方法可能在大多数时候是可行的,但不代表这是一个正确的方法, |
17 WhoCanBeRich OP @leo108 是 所以我也说[编译,防止合并代码的时候有人提交新的代码]哈 |
18 WhoCanBeRich OP @leo108 你有什么建议可以让我完全避免这种潜在问题嘛 (除了 force push..如果 force 我会被打死的 |
19 leo108 2019 年 7 月 1 日 @WhoCanBeRich 如果对 rebase 理解不够到位,建议还是用 merge 吧。 |
20 WhoCanBeRich OP @leo108 但是用 merge 也会存在你说的这个问题呀:"这个就是时间差问题了,假如你在处理冲突时花了较多的时间,那么就有可能出现别人 push 了新的 commit 到远端分支。" |
21 Xbluer 2019 年 7 月 8 日 @leo108 #13 company_trunk rebase 自己的分支不是问题。你再看看前面的操作,楼主自己分支 也 rebase origin/company_trunk 了。只要 push 之前没有其他同事 push 更新 origin/company_trunk 就好了。即便有人更新了,直接在 company_trunk 分支执行 pull --rebase 并解决冲突就好了。 |