Once all conflicts have been marked as using ‘ ours ’ or ‘ theirs ’, the conflict can be resolved. This will perform a merge of the target branch of the merge request into the source branch, resolving the conflicts using the options chosen.
https://docs.gitlab.com/ee/user/project/merge_requests/resolve_conflicts.html
团队已经被它坑了不少次了，如果使用 Gitlab 提供在在线冲突解决工具的话，本来是将 A 往 B 合并的，结果变成了 B 往 A 合并，导致分支管理混乱。这个设计合理吗？
 |
1
azh7138m Dec 3, 2018
这边有两个选项，一个在 source 上面 merge target，一个在 target 上面 merge source，不要点错就好了.....
（按道理不是在本地先合一下 target 的吗 |
 |
2
WhiteSaber Dec 3, 2018
pu~ 找到上班的 kary 哥
|
 |
3
swulling Dec 3, 2018
你用 Git 自带的合并也是一样的啊，合并冲突的时候没有什么正向反向，只能靠人工在两个修改之间选择。
|
 |
4
wxsm OP |
|
5
wxsm OP @zzbond0517 :D
|
|
6
swulling Dec 3, 2018
@wxsm 分支合并其实也是一样的，git 里的分支从设计上没有说那个是 target，哪个是 origin
当然实际使用的时候会生成一些固定的模式，gitlab 应该加一个配置，固化下模式。 不过在项目人数 <= 8 人的时候，我个人会要求团队保持线性历史，配置禁止 merge commit，有冲突直接不允许 push，后 push 的同学需要自行 rebase 解决冲突后提交。 暂时没有人数 >= 8 人的开发经验 :D |
 |
7
HangoX Dec 3, 2018
我猜楼主其实是想开那个 merge no fast forward,因为不开就会在 dev 上看到是 dev 合并去特性分支，gitlab 上开了之后就不管你怎么合并，合并过去的时候都会创建一个合并点
|
|
8
wxsm OP |
|
9
HangoX Dec 4, 2018
@wxsm 你完全搞错了，第一，这个是 merge request 解决冲突之后是需要审阅才能合并到目标分支的，所以反过来合并 gitlab 没错。第二，feature b 不应该合并到主分支上，要么你们就每个版本不同的公共发布分支，要么就是主分支上只有要发布版本的内容。
|
|
10
wxsm OP @HangoX 退一步说，就算我不把 B 合并到主分支，那么主分支到 B 的合并应该是正常操作吧？那这时候 gitlab 把 B 合到主分支去了，你还觉得没错吗？
|
|
11
HangoX Dec 4, 2018
@wxsm 你要先理解那个东西叫 merge requset，不是 git 上的 merge ,人家就不是给你用来把主分支合并到 feature 分支上的。
|
 |
12
temberature May 9, 2019
Note: 注意: GitLab resolves conflicts by creating a merge commit in the source branch that is not automatically merged into the target branch. This allows the merge commit to be reviewed and tested before the changes are merged, preventing unintended changes entering the target branch without review or breaking the build.
Gitlab 通过在源分支中创建一个 merge commit 来解决冲突，该分支不会自动合并到目标分支中。 这允许在合并更改之前对合并提交进行审查和测试，从而防止意外的更改进入目标分支，而无需审查或中断构建 （ revert 可以解决某些场景） |
Select Language