git 合并分支的时候为什么老是把老的覆盖到新的上面

[SpiderXiantang]

最近和大学的室友一起做比赛项目 我们大家都是各自维护分支 然后往 dev 上合并分支
刚遇到一个事情就是 我首先合并了分支 然后我队友也合并分支上去了 但是他更新的部分还是原来的样子

[CoderEQ]

rebase.或者 merge 了解一下吧

[thedrwu]

--no-ff
或者在 config 文件里把 fast foreward 关了

[thedrwu]

也许没看懂楼主的意思，是说 push 的时候-f 了吗

[hasbug]

2 个不懂 git 的人

[KeatingSmith]

提交代码不要直接提交到 dev，

通过 pull request 合并代码到 dev。

[bombless]

最简单就是不要在一个分支开发，比如如果用 gitlab 可以用 merge request

[msg7086]

@SpiderXiantang Git 这玩意儿，说简单也简单，说复杂可以搞得非常复杂。这货完美继承了 Linux 的血统，想要吃透 Git，没个两三年的沉淀积累，我觉得难。初期我建议试试 SmartGit 这个 GUI 工具，比较直观。后期如果想换命令行的话，可以学他的命令行玩法，我敢说他命令行玩得比这帖子里很多人都要溜。

[leconio]

手动 pull 试试，先 reset 到要提交的 commit。然后 merge 远程分支到本地，最后 force push。

[geelaw]

对于 GitHub 用户的我来说，我通常只用 GitHub 的 pull request ……

[jasperjia]

新手先用 GUI，sourcetree 中的分支图表对于你前期理解 git flow 很有帮助，吃透 git flow 后再上命令行。

[RainyH2O]

git 就好好把 pro git 看了，特别是内部原理那章
廖雪峰的入个门还行，但毕竟没把原理讲明白
见到 force，hard，rebase 之类的，没懂原理千万要慎用
甚至 git checkout branch file 都是有丢本地文件的风险的
这点 pro git 就有讲到，总归你用一条指令或是一次操作之前你就得清楚仓库，历史树，缓存，本地即将会发生什么
话说 GUI 还是有用的， 但不要依赖，主要是用来看每条指令发生了什么，理解原理最重要
不过你这描述老实说让人看不懂，你是说远程库没更新到你队友的提交？
那不就压根没 push 成功？

[dangyuluo]

你这描述不清啊。不过常用的方法是：
1. 禁止 `git push --force`, 仅允许使用`git push --force-with-lease`
2. 修改开发流程，不要所有人都在同一个分支上开发。做什么 feature 就单独开一个分支，然后 master/dev branch 仅允许 merge request，不接收任何人 push。

[shm7]

楼上有理，但是任然解决不了要从主分支合并到开发分支的“ bug ”，事实上公司的 build cicd 之类的也会这么干。都是为了不冲突啊，保证 git 分支的基础 commit 是一样的，因为 git 就是一个 commit 基于前一个 commit

[WuwuGin]

怕不是本地代码落后版本，然后强行 push 了。正常的命令行操作是先 pull 再 push。尽量不要用 gui 的 git，鬼知道会有什么问题。

[Deville]

@SpiderXiantang 命令肯定是要懂的，不然图形化工具出错了怎么回滚都会懵逼。先了解节点概念，了解 merge 和 rebase 的节点管理差别，另外推荐 rebase ..

[sherardxu]

先命令行再 GUI 会好很多
命令行还不熟悉的话
找一个靠谱的 GUI 也行

我用 jetbrains 家的 IDE 比较多
大部分使用时间没什么问题
但是偶尔遇到本地有更改 GUI 不显示
导致后续操作冲突

还是去命令行看 git status 靠谱

[shalk]

我觉得是你们处理冲突的问题，尤其是 eclipse gui，我遇到有人在冲突时，把别人修改的其他文件拖拽成恢复原样。这样提交之后，这个文件的修改就丢了。历史记录里很难追踪到罪魁祸首。

[watzds]

少改同一个文件，估计是合并时冲突，选择了放弃自己的版本

[DongDongXie]

提交之前先切换到 master 分支 pull 最新代码，然后切回自己的分支，再 rebase 就可以更新到最新了吧