Git - 与其他人在分支上工作时是拉取还是变基

Git - is it pull or rebase when working on branches with other people

提问by Cameron Booth

So if I'm using branches that are remote (tracked) branches, and I want to get the lastest, I'm still unclear if I should be doing git pullor git rebase. I thought I had read that doing git rebasewhen working on a branch with other users, it can screw them up when they pull or rebase. Is that true? Should we all be using git pull?

因此，如果我使用的是远程（跟踪）分支的分支，并且我想获得最新的分支，我仍然不清楚我是否应该使用git pull或git rebase. 我以为我在git rebase与其他用户一起在一个分支上工作时读过这样做，当他们拉或变基时，它可能会把他们搞砸。真的吗？我们都应该使用git pull吗？

回答by webmat

Git pull is a combination of 2 commands

Git pull 是 2 个命令的组合

• git fetch (syncs your local repo with the newest stuff on the remote)
• git merge (merges the changes from the distant branch, if any, into your local tracking branch)

• git fetch（将你的本地仓库与远程最新的东西同步）
• git merge（将远程分支的更改（如果有）合并到本地跟踪分支中）

git rebase is only a rough equivalent to git merge. It doesn't fetch anything remotely. In fact it doesn't do a proper merge either, it replays the commits of the branch you're standing on after the new commits from a second branch.

git rebase 只是一个粗略的等价于 git merge。它不会远程获取任何东西。事实上，它也没有进行适当的合并，它会在第二个分支的新提交之后重放您所在分支的提交。

Its purpose is mainly to let you have a cleaner history. It doesn't take many merges by many people before the past history in gitk gets terribly spaghetti-like.

它的目的主要是让你有一个更干净的历史。在 gitk 过去的历​​史变得非常像意大利面条之前，不需要很多人进行多次合并。

The best graphical explanation can be seen in the first 2 graphics here. But let me explain here with an example.

最好的图形解释可以在这里的前 2 个图形中看到。但让我在这里用一个例子来解释。

I have 2 branches: master and mybranch. When standing on mybranch I can run

我有 2 个分支：master 和 mybranch。站在mybranch上我可以跑

git rebase master

and I'll get anything new in master inserted before my most recent commits in mybranch. This is perfect, because if I now merge or rebase the stuff from mybranch in master, my new commits are added linearly right after the most recent commits.

并且在我最近一次在 mybranch 中提交之前，我会在 master 中插入任何新内容。这是完美的，因为如果我现在在 master 中从 mybranch 合并或重新设置内容，我的新提交会在最近的提交之后线性添加。

The problem you refer to happens if I rebase in the "wrong" direction. If I just got the most recent master (with new changes) and from master I rebase like this (before syncing my branch):

如果我在“错误”的方向上变基，就会发生您提到的问题。如果我刚刚获得了最新的 master（有新的更改）并且从 master 那里我变基了（在同步我的分支之前）：

git rebase mybranch

Now what I just did is that I inserted my new changes somewhere in master's past. The main line of commits has changed. And due to the way git works with commit ids, all the commits (from master) that were just replayed over my new changes have new ids.

现在我所做的就是在 master 过去的某个地方插入我的新更改。提交的主线已更改。由于 git 处理提交 id 的方式，所有刚刚在我的新更改上重播的提交（来自 master）都有新的 id。

Well, it's a bit hard to explain just in words... Hope this makes a bit of sense :-)

好吧，仅用语言来解释有点困难......希望这有点道理:-)

Anyway, my own workflow is this:

无论如何，我自己的工作流程是这样的：

• 'git pull' new changes from remote
• switch to mybranch
• 'git rebase master' to bring master's new changes in my commit history
• switch back to master
• 'git merge mybranch', which only fast-forwards when everything in master is also in mybranch (thus avoiding the commit reordering problem on a public branch)
• 'git push'

• 'git pull' 来自远程的新更改
• 切换到 mybranch
• 'git rebase master' 将 master 的新更改带入我的提交历史记录
• 切换回主
• 'git merge mybranch'，仅当 master 中的所有内容也在 mybranch 中时才快进（从而避免公共分支上的提交重新排序问题）
• 'git push'

One last word. I strongly recommend using rebase when the differences are trivial (e.g. people working on different files or at least different lines). It has the gotcha I tried to explain just up there, but it makes for a much cleaner history.

最后一句话。我强烈建议在差异很小时使用 rebase（例如，人们处理不同的文件或至少不同的行）。它有我试图在上面解释的问题，但它使历史更加清晰。

As soon as there may be significant conflicts (e.g. a coworker has renamed something in a bunch of files), I strongly recommend merge. In this case, you'll be asked to resolve the conflict and then commit the resolution. On the plus side, a merge is much easier to resolve when there are conflicts. The down side is that your history may become hard to follow if a lot of people do merges all the time :-)

一旦可能出现重大冲突（例如，同事在一堆文件中重命名了某些内容），我强烈建议合并。在这种情况下，系统会要求您解决冲突，然后提交解决方案。从好的方面来说，当存在冲突时，合并更容易解决。不利的一面是，如果很多人一直合并，您的历史可能会变得难以追踪:-)

Good luck!

祝你好运！

回答by Pat Notz

Git rebaseis a re-write of history. You should never do this on branches that are "public" (i.e., branches that you share with others). If someone clones your branch and then you rebase that branch -- then they can no longer pull/merge changes from your branch -- they'll have to throw their old one away and re-pull.

Gitrebase是对历史的改写。您永远不应该在“公共”分支（即您与他人共享的分支）上执行此操作。如果有人克隆了你的分支，然后你重新设置了那个分支——那么他们就不能再从你的分支中拉取/合并更改——他们将不得不扔掉旧的并重新拉取。

This article on packaging software with gitis a very worthwhile read. It's more about managing software distributions but it's quite technical and talks about how branches can be used/managed/shared. They talk about when to rebase and when to pull and what the various consequences of each are.

这篇关于使用 git 打包软件的文章非常值得一读。它更多地是关于管理软件分发，但它非常技术性，并讨论了如何使用/管理/共享分支。他们谈论何时变基、何时拉动以及每种方法的各种后果是什么。

In short, they both have their place but you need to really grok the difference.

简而言之，它们都有自己的位置，但您需要真正理解其中的区别。

回答by Greg Hewgill

git pulldoes a merge if you've got commits that aren't in the remote branch. git rebaserewrites any existing commits you have to be relative to the tip of the remote branch. They're similar in that they can both cause conflicts, but I think using git rebaseif you can allows for smoother collaboration. During the rebase operation you can refine your commits so they look like they were newly applied to the latest revision of the remote branch. A merge is perhaps more appropriate for longer development cycles on a branch that have more history.

git pull如果您的提交不在远程分支中，则进行合并。git rebase重写您必须相对于远程分支的尖端的任何现有提交。它们的相似之处在于它们都可能导致冲突，但我认为git rebase如果可以的话，使用可以让协作更顺畅。在 rebase 操作期间，您可以细化您的提交，使它们看起来像是新应用于远程分支的最新版本。合并可能更适合具有更多历史的分支上更长的开发周期。

Like most other things in git, there is a lot of overlapping functionality to accommodate different styles of working.

像 git 中的大多数其他东西一样，有很多重叠的功能来适应不同的工作风格。

回答by webmat

Check out the excellent Gitcasts on Branching and mergingas well as rebasing.

检查出的优秀Gitcasts分支与合并以及基础重建。

回答by Lee H

If you want to pull source without affecting remote branches and without any changes in your local copy, it's best to use git pull.

如果你想在不影响远程分支的情况下拉取源代码，并且在本地副本中没有任何更改，最好使用 git pull。

I believe if you have a working branch that you have made changes to, use git rebase to change the base of that branch to be latest remote master, you will keep all of your branch changes, however the branch will now be branching from the master location, rather than where it was previously branched from.

我相信如果你有一个你已经改变的工作分支，使用 git rebase 将该分支的基础更改为最新的远程 master，你将保留所有分支更改，但是该分支现在将从 master 分支位置，而不是它以前分支的地方。