【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>
我知道有些人默认使用git pull --rebase
,而其他人坚持不使用它。 我相信我理解合并和变基之间的区别,但我试图把它放在git pull
的上下文中。 它只是不想看到很多合并提交消息,还是有其他问题?
#1楼
我认为这归结为个人偏好。
你想在推动改变之前隐藏你的愚蠢错误吗? 如果是这样, git pull --rebase
就是完美的。 它允许您稍后将提交压缩到几个(或一个)提交。 如果您在(未按下的)历史记录中进行了合并,那么稍后进行git rebase
就不那么容易了。
我个人不介意发布我所有的愚蠢错误,所以我倾向于合并而不是rebase。
#2楼
我认为你应该在与同一分支上的其他人合作时使用git pull --rebase
。 你正在工作→提交→工作→提交周期,当你决定推动你的工作时,你的推动被拒绝,因为在同一个分支上有并行工作。 在这一点上,我总是做一个pull --rebase
。 我不使用squash(以展平提交),但我重新设置以避免额外的合并提交。
随着您的Git知识的增加,您发现自己在历史上看起来比我使用的任何其他版本控制系统更多。 如果你有大量的小合并提交,很容易失去你历史上正在发生的大局的焦点。
这实际上是我唯一一次进行变基(*),而我的工作流程的其余部分都是基于合并的。 但只要你最常见的提交者这样做,历史最终会看起来好多了。
(*)在教授Git课程的同时,我让一名学生逮捕了我,因为在某些情况下我也主张改变特色分支。 并且他已经阅读了这个答案;)这种变基也是可能的,但它总是必须根据预先安排/商定的系统,因此不应该“始终”应用。 而那时候我通常也不会pull --rebase
,这就是问题所在;)
#3楼
你应该使用git pull --rebase
- 您的更改不值得单独的分支
确实 - 为什么不呢? 它更清楚,并且不会对您的提交强加逻辑分组 。
好吧,我想它需要一些澄清。 在Git中,您可能知道,我们鼓励您进行分支和合并。 你拉动更改的本地分支和远程分支实际上是不同的分支,而git pull
则是关于它们的合并。 这是合理的,因为你不经常推动并且通常在它们构成完整特征之前累积一些变化。
然而,有时 - 无论出于什么原因 - 你认为如果这两个 - 远程和本地 - 是一个分支实际上会更好。 就像在SVN中一样。 正是在这里git pull --rebase
发挥作用。 您不再合并 - 您实际上在远程分支上提交 。 这就是它的实际意义所在。
无论是否危险,问题在于你是否将本地和远程分支视为一个不可分割的东西。 有时它是合理的(当你的变化很小时,或者如果你处于强劲发展的开始阶段,当小的提交引入了重要的变化时)。 有时它不是(当你通常创建另一个分支,但你懒得这样做)。 但这是一个不同的问题。
#4楼
我不认为有任何理由不使用pull --rebase
- 我pull --rebase
将代码添加到Git以允许我的git pull
命令始终对上游提交进行pull --rebase
。
查看历史记录时,知道何时处理该功能的人/ gal停止同步是非常有趣的。 当他/她这样做时,它对于那个人/ gal可能是有用的,但这就是reflog
的用途。 这只会为其他人增加噪音。
#5楼
也许最好的解释方法是举个例子:
- Alice创建主题分支A,并对其进行处理
- Bob创建了不相关的主题分支B,并对其进行处理
- 爱丽丝做
git checkout master && git pull
。 师父已经是最新的。 - Bob做
git checkout master && git pull
。 师父已经是最新的。 - Alice做
git merge topic-branch-A
- Bob做
git merge topic-branch-B
- Bob在Alice之前做了
git push origin master
- Alice执行
git push origin master
,因为它不是快进合并而被拒绝。 - Alice查看origin / master的日志,发现提交与她的无关。
- 爱丽丝做
git pull --rebase origin master
- Alice的合并提交被解除,Bob的提交被撤销,并且在Bob的提交之后应用Alice的提交。
- Alice确实是
git push origin master
,每个人都很高兴他们在将来查看日志时不必阅读无用的合并提交。
请注意,要合并的特定分支与示例无关。 在这个例子中,Master可以很容易地成为发布分支或dev分支。 关键点在于Alice和Bob同时将其本地分支合并到共享远程分支。
来源:oschina
链接:https://my.oschina.net/stackoom/blog/3145665