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

[SpiderXiantang]

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

[SpiderXiantang]

是我提出用 git 的 现在都有点难受了 让队友麻烦那么多

[zpf124]

git push -f ?

[SpiderXiantang]

@zpf124 我是用桌面版的 可能直接快进模式了

[zlmdaybreak]

@SpiderXiantang 找一下教程然后大家约定一下怎么开发，合并前需要先 fetch 一下。找工作的时候他们会感谢你让他们用 git。

[michaelcheng]

本地 merge 的时候是否有先 pull develop 的代码

[raysonx]

禁止 force puah

[raysonx]

打错，先禁止 force push 再说

[kimoCHG]

git rebase 了解一下

[msg7086]

先学习如何使用 Git 吧。用东西不看说明书并不见得一直行得通。

[orangeade]

先学会 Git 命令行

[Deville]

不要用图形化界面工具

[SpiderXiantang]

@Deville 我也想用命令行 项目是大家一起写的 所以想让他们简单点 就用的桌面版本

[SpiderXiantang]

@michaelcheng 桌面版本感觉会定期去 fetch 远程仓库的代码

[shily]

每次 push 之前使用 pull --rebase, 先 rebase 一下 代码。可以避免不必要的 merge 节点。

[SpiderXiantang]

@shily 谢谢老哥 我这就去学习一下

[shenxgan]

个人工作中，push 前总会先 pull 一下，将线上的先合并到本地，然后再 push

[SpiderXiantang]

@msg7086 我只学习了廖雪峰的 75%的 git 教程 感觉 git 用起来还是很虚

[Reficul]

merge 之前先 rebase(推荐)或者 merge(不推荐)上游的代码

[sampeng]

你用 svn 成吨的冲突或者一样的错误。。和版本管理软件没关系。和怎么用有关

[sampeng]

在用 svn 的经验告诉我。。所有的分支合并。。挑选合并是最靠谱的。频繁的从 dev 分支把代码 cherry pick.或者合并的时候手动的 cherry pick。而不是无脑 merge。。其实每次从 dev 分支往主干上合并并没多少东西。这样合并几乎不会有任何问题。。。
无脑 merge、rebase。只有知道没有人在我之前提交任何东西。并且的清楚知道合并和开发顺序。其实无所谓，操作完了千万别 push 上去。。检查一下没问题再 push。。。

[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 就可以更新到最新了吧