git rebase到远程更新

我与一个使用git进行源代码管理的小团队一起工作。最近，我们一直在做主题分支，以跟踪功能，然后将它们合并到主机中，然后将它们推送到远程服务器上的中央git存储库。这在master中没有更改时很有用：我创建我的主题分支，提交它，将它合并到master中，然后推送。万岁。git rebase到远程更新

但是，如果有人在我之前推送到原点，我的提交并不是快进。因此合并提交随之而来。当主题分支需要本地合并以确保我的更改能够与代码一起工作时，也会发生这种情况。所以，我们最终得到了各处的合并提交以及与友谊手镯相媲美的git日志。

因此，重新定义是明显的选择。我想是：

制造话题分行持有多次提交
结账主拉（快进，因为我没有犯下掌握）
底垫的特性分支上的新掌门人掌握
重订对主议题（这样的主题在主人开始头），使主到了我的头上话题

我目前这样做的方式如下：

git checkout master 
git rebase master topic_1 
git rebase topic_1 topic_2 
git checkout master 
git rebase topic_2 
git branch -d topic_1 topic_2

有没有更快的方法来做到这一点？

来源

2010-05-26 Blake Chambers

我发现，随着时间的推移，我最喜欢的解决办法是：

git checkout topic 
# make [n] commits 
git rebase -i HEAD~[n] #clean up time 
git checkout master 
git pull --rebase 
git checkout topic 
git rebase master 
git checkout master 
git merge topic 
git push origin

来源

2010-12-18 05:57:42

是最后一次合并所必需的。我可以想象在图上看到所有工作分支的新颖性，但是代码已经集成到了主分支中，如果没有成为真正的分支，我认为抛弃工作代码是不合理的。否则恕我直言，这个答案是完美的。 – 2012-03-20 23:16:17

对于我们的团队，我们设置了一些很好的工具，并且根本不使用rebase。

我们削减了我们在Jira门票上的工作，这些门票不需要太长时间，通常需要1-2天的时间。每个开发者为每个票据创建一个分支并在这个分支上工作。准备好分享时将其推送到中央服务器。

中央服务器由哈德森CI服务器进行监控，该服务器将更改，合并所有更新的分支，重建软件，运行测试并将所有内容推送到中央主git存储库。

从那里我们把它拉回到我们的仓库。我们经常（即每隔几天）将我们的工作分支与中央主人合并，以保持他们的“关闭”。

由于没有人在“合并”计算机上工作，除CI服务器之外没有人接触到主服务器，所以我们很少出现合并问题（约占提交的1-2％）。通过清理工作区，可以在构建服务器上快速解决这些问题。我们发现我们可以通过保持分支简短并在推送之前与远程主机合并来避免其中的大部分。

我也很喜欢合并比基础更加强大，并且需要少得多的返工。

来源

2010-05-26 23:25:32

这对于较慢的开发很有用，但是我们有一个环境，需要一些提交每晚上去，而其他人则等待较大的版本。我想一种方法来处理，就是在夜间安装并在远程仓库上发布分支......但听起来好像它可能会邀请更多的这些合并提交，如果没有完全遵守。虽然我也相信合并更加“健壮”，但我们的团队能够搞清楚git-rebase并解决问题。具有更可读的提交历史对我来说同样重要。 – 2010-05-27 17:06:48

个人而言，我认为合并的叉子在历史中是丑陋/混乱的，所以我总是将温度/发育分支重新定位到偏远的原点。不过，我觉得有趣的是，您的团队有效实施了合并计划，但几乎没有问题和可衡量的收益。你是否按照正常的时间表进行改版以保持与中央主人的距离更近？ “清理工作区”需要做什么？而且，在与中央存储库合并之前，您是否拉取和重新分配以检查冲突？ – 2012-03-20 23:27:50

@EvanPlaice清理工作区将擦除Jenkins上的工作目录。下一次制作新的克隆。 – 2012-03-28 12:48:45

您是否知道git pull --rebase？它在你拉动时不是合并，而是防止合并提交污染你的历史。

您也可以将其设置为branch.<name>.rebase和branch.autosetuprebase配置选项的分支的默认行为。

来源

2010-12-17 20:28:34

是的，我在将共享代码库更新到远程的最新版本时经常使用它。然而，这篇文章更多的是关于功能分支更加简化的方式来做到这一点，并且git pull rebase不是IMO。但是，分支汽车重新绑定是一个很棒的功能，我已经将它添加到了几个仓库。伟大的提示！ :) – 2010-12-18 05:47:51

你也可以变基对跟上时代的主

git checkout topic_1 
git rebase refs/remotes/origin/master

这消除了对拉的需要（至少直到功能分支的EOL）。我们的流程使用GitHub pull请求，所以我从不需要在本地执行此操作。

来源

2013-11-11 14:38:59 Visser

git rebase到远程更新

回答

相关问题