git rebase 到远程更新

git rebase onto remote updates

提问by Blake Chambers

I work with a small team that uses git for source code management. Recently, we have been doing topic branches to keep track of features then merging them into master locally then pushing them to a central git repository on a remote server. This works great when no changes have been made in master: I create my topic branch, commit it, merge it into master, then push. Hooray.

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

However, if someone has pushed to origin before I do, my commits are not fast-forward. Thus a merge commit ensues. This also happens when a topic branch needs to merge with master locally to ensure my changes work with the code as of now. So, we end up with merge commits everywhere and a git log rivaling a friendship bracelet.

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

So, rebasing is the obvious choice. What I would like is to:

所以，rebase 是显而易见的选择。我想要的是：

• create topic branches holding several commits
• checkout master and pull (fast-forward because i haven't committed to master)
• rebase topic branches onto the new head of master
• rebase topics against master(so the topics start at masters head), bringing master up to my topic head

• 创建包含多个提交的主题分支
• 结帐大师和拉（快进，因为我还没有承诺掌握）
• 将主题分支重新绑定到新的 master 头上
• 针对 master 重新设置主题（因此主题从 masters 头开始），将 master 带到我的主题头

My way of doing this currently is listed below:

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

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

Is there a faster way to do this?

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

采纳答案by Blake Chambers

I have found, over time, my favorite solution is:

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

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

回答by Martin Owen

Do you know about git pull --rebase? It rebases rather than merging when you pull, and prevents merge commits from polluting your history.

你知道git pull --rebase吗？它会在您拉取时变基而不是合并，并防止合并提交污染您的历史记录。

You can also set it up as the default behaviour for a branch with the branch.<name>.rebaseand branch.autosetuprebaseconfig options.

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

回答by Peter Tillemans

For our team we set something up which works very well and does not use rebase at all.

对于我们的团队，我们设置了一些非常有效并且根本不使用 rebase 的东西。

We cut our work in Jira tickets which do not take too long, typically 1-2 days effort. Each dev creates a branch per ticket and works on this branch. When ready to share this is pushed to the central server.

我们减少了在 Jira 票证方面的工作，这不会花费太长时间，通常需要 1-2 天的时间。每个开发人员为每个工单创建一个分支并在该分支上工作。当准备好共享时，它会被推送到中央服务器。

The central server is monitored by a hudson CI server which pulls the changes, merges all updated branches, rebuilds the software, runs the tests and pushes everything to the central master git repository.

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

From there we pull it back to our repositories. We do regularly (i.e. every couple of days) merge our working branches with the central master to keep them 'close'.

从那里我们将其拉回我们的存储库。我们定期（即每隔几天）将我们的工作分支与中央主节点合并，以保持它们“关闭”。

Since nobody is working on the 'merging' machine and nobody other than the CI server touches the master, we have very infrequently merging issues (in about 1-2% of the commits). And these are quickly resolved on the build server by cleaning the workspace. We found we could have avoided most of these by keeping the branches short and merging with the remote master before pushing.

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

I also fond that merging is much more robust than rebasing and requires a lot less of rework.

我也喜欢合并比变基更强大并且需要更少的返工。

回答by Andy V

You can also just rebase against the up-to-date master

你也可以只根据最新的主人

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

Which obviates the need for the pull (at least until the EOL of your feature branch). Our process uses GitHub pull requests so I never need to do that locally.

这消除了拉取的需要（至少在您的功能分支的 EOL 之前）。我们的流程使用 GitHub 拉取请求，因此我永远不需要在本地执行此操作。