这是一个创建于 1974 天前的主题，其中的信息可能已经有所发展或是发生改变。
三个问题哈~
1、lz 平时写项目写项目都喜欢用 rebase，因为这样到时候追 bug 的时候可以将多条 commit 的记录翻出来修，但是公司比较推荐用 merge，这样别人看你的提交只会是一条 commit，比较简洁。
2、刚入职我操作公司的 git 总是会出现一些问题，总让自己的 mentor 帮忙解决非常不好意思，顺便也问一下老哥们我下面的这样的操作 git 的方式 OK 吗，会不会存在什么潜在的问题？
-->[trunk_myself]（我自己的分支）:
git fetch
git rebase origin/company_trunk
[出现冲突：开始修冲突]
git add 冲突文件
git rebase --continue
git add .
git commit -m 'xxx'
-->[company_trunk]（公司的分支）：
git co company_trunk
git rebase trunk_myself
git st
[Your branch is ahead of 'origin/company_trunk'
[编译，防止合并代码的时候有人提交新的代码]
git fetch
git rebase
[查看 sourceTree 节点是否正常]
git push
3、如果用 merge 的话，直接把上面的'rebase'替换成'merge'会不会出现什么问题呢？
1、lz 平时写项目写项目都喜欢用 rebase，因为这样到时候追 bug 的时候可以将多条 commit 的记录翻出来修，但是公司比较推荐用 merge，这样别人看你的提交只会是一条 commit，比较简洁。
2、刚入职我操作公司的 git 总是会出现一些问题，总让自己的 mentor 帮忙解决非常不好意思，顺便也问一下老哥们我下面的这样的操作 git 的方式 OK 吗，会不会存在什么潜在的问题？
-->[trunk_myself]（我自己的分支）:
git fetch
git rebase origin/company_trunk
[出现冲突：开始修冲突]
git add 冲突文件
git rebase --continue
git add .
git commit -m 'xxx'
-->[company_trunk]（公司的分支）：
git co company_trunk
git rebase trunk_myself
git st
[Your branch is ahead of 'origin/company_trunk'
[编译，防止合并代码的时候有人提交新的代码]
git fetch
git rebase
[查看 sourceTree 节点是否正常]
git push
3、如果用 merge 的话，直接把上面的'rebase'替换成'merge'会不会出现什么问题呢？
 |
1
iConsLii 2019-06-30 13:16:40 +08:00
1、公司的项目跟着公司规定走吧
|
 |
3
leo108 2019-06-30 13:41:42 +08:00
你自己的分支怎么 rebase 都无所谓，但是公共的分支（比如你说的 company_trunk ）执行 rebase 操作的话……没被同事打死真是幸运呢。
|
 |
4
Xbluer 2019-06-30 14:09:43 +08:00
|
 |
5
WhoCanBeRich OP @iConsLii 好的 谢谢老哥！
|
|
6
WhoCanBeRich OP @leo108 好的哈哈 那我还是用 merge 啦 谢谢你啦 ：）
|
|
7
WhoCanBeRich OP @Xbluer 好的 谢谢你啦！
|
|
9
leo108 2019-06-30 15:56:54 +08:00
|
|
10
Xbluer 2019-06-30 16:43:58 +08:00
@leo108 #9 比如说本地分支 feature/abc 跟踪远程分支 origin/feature/abc。 在本地 feature/abc 上直接开发并提交到本地，执行 pull --rebase 可以将本地修改的内容在最新的 origin/feature/abc 最新的版本上衍合，然后执行 push 操作就可以，并不需要 push --force。 提交日志只有一条直线，所有开发者的开发活动像是依次顺序完成的，简洁明了。
|
 |
11
wsxyeah 2019-06-30 18:45:59 +08:00 via iPhone
你的 company_trunk 是指 develop，master 这类分支？这类通常会设为 protected branch，是不允许 push 的，只能通过 mr 合进去。
你自己的 feature 分支当然可以 rebase。 |
 |
12
ColinZeb 2019-06-30 20:42:46 +08:00
@leo108 git fetch -> git rebase(这里的是未推送的提交 rebase 到 head 上)-> git push
|
|
13
leo108 2019-07-01 07:15:55 +08:00
@Xbluer 你仔细看楼主贴的操作记录，是在 company_trunk rebase 了自己的分支，这种情况必然需要 force push。
|
|
15
WhoCanBeRich OP @leo108 应该不用 force push 吧，我已经 git fetch 过了，也就是本地的 company_trunk 与远端的一致了
|
|
16
leo108 2019-07-01 09:51:56 +08:00
@WhoCanBeRich 这个就是时间差问题了，假如你在处理冲突时花了较多的时间，那么就有可能出现别人 push 了新的 commit 到远端分支。
你的方法可能在大多数时候是可行的，但不代表这是一个正确的方法， |
|
17
WhoCanBeRich OP @leo108 是 所以我也说[编译，防止合并代码的时候有人提交新的代码]哈
|
|
18
WhoCanBeRich OP @leo108 你有什么建议可以让我完全避免这种潜在问题嘛 （除了 force push..如果 force 我会被打死的
|
|
19
leo108 2019-07-01 10:18:32 +08:00
@WhoCanBeRich 如果对 rebase 理解不够到位，建议还是用 merge 吧。
|
|
20
WhoCanBeRich OP @leo108 但是用 merge 也会存在你说的这个问题呀:"这个就是时间差问题了，假如你在处理冲突时花了较多的时间，那么就有可能出现别人 push 了新的 commit 到远端分支。"
|
|
21
Xbluer 2019-07-08 19:35:13 +08:00
@leo108 #13 company_trunk rebase 自己的分支不是问题。你再看看前面的操作，楼主自己分支 也 rebase origin/company_trunk 了。只要 push 之前没有其他同事 push 更新 origin/company_trunk 就好了。即便有人更新了，直接在 company_trunk 分支执行 pull --rebase 并解决冲突就好了。
|
Select Language