用了以后, 树可以非常清晰, 某种程度上便于追踪, 但是 push --force 就多多了,
不用呢, 合并没有远程仓库被修改的麻烦, 可是追踪又不清晰...
怎样取舍? 团队里一般怎么取舍?
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
11
2438
收藏
除非只有自己一个人用，不然用
push --force的都该去死。本地分支和远程分支的绑定（tracking)，加上 rebase 策略：
这样一来，更新代码（
pull）的时候就会自动应用 rebase 而不是产生 merge commit，除非有其他情况产生，比如三方合并造成了冲突需要人共去干预。大部分时候还是很聪明的，只要团队里的习惯都良好，那么可以保持一个非常干净漂亮的树形。其实想让树形结构漂亮些清晰些是有很多办法的，但是首先要取决于团队用的是什么样的 Git Model，对症下药即可。在这里就无法一言以蔽之了。
另外，楼上说得对，慎用
push -f！这应该是一个git workflow的问题，我们团队也一直在使用rebase保证commit信息的整洁，但不会用到
push -f这样的操作。关于git workflow就是一个见仁见智的问题了，下面几篇文章你可以看下，再找出一套适合自己团队的就可以了，不过最重要的是要保证团队的每个人都熟悉git，防止犯愚蠢的错误。
如果使用github来团队合作的话，用好pull request，它可以解决
push -f这种愚蠢问题！每个人提交前，都应该把自己的修改rebase到服务器的最新代码之上，遵守这个规则就不会有任何问题。如果你需要force push，说明你做反了，把服务器代码rebase到你本地分支之上才会需要force push，这是错误的用法。
不需要push -f啊，如果分支落后就用pull --rebase
楼上的答案都很正，个人认为，除非某个分支只有你自己搞，你怎么rebase都是没有问题的，但是如果你在master或者develop这种分支上来rebase，估计团队里每个人都想拍死你，尤其是对git不熟悉的队友，手足无措是非常正常的表现。
rebase之后 push -f的情况只有一个，就是题主像我一样有强迫症，害怕电脑宕机、系统崩溃这种蛋疼的事情(悲惨的血泪史)，完成一个特性commit之后迅速push到远程只属于你的分支上，每天为了拿到develop的新特性，才在自己的分支上rebase develop,重复执行push的操作，这个个人认为是没有问题的，毕竟你只影响了你自己(而你知道这是对的)。
个人认为， 当你在某个分支进行团队合作的时候， 常用rebase真的是不合理。而且容易出问题。慎用 push --force
git rebase 一般自己一个人开发时使用，用来保持提交记录的整洁。一旦上传到github后，不应该使用git rebase,不然被骂死。
rebase的风险