git 在不丢失更改的情况下合并上游的正确方法是什么？

What is the correct way to merge upstream without losing changes?

提问by Larry Kyrala

I'm in a bit of a pickle.

我有点酸。

I started development on a fork of a repo a few months ago. I made some changes. I was about to push my code back to the master as a pull request, but I realized there were quite a few changes in the meantime...

几个月前，我开始在一个 repo 的分支上进行开发。我做了一些改变。我正准备将我的代码作为拉取请求推回主人，但我意识到在此期间发生了很多变化......

So, following the instructions at Githubunder "Pull in Upstream Changes" I tried:

因此，按照 Github 上“拉入上游更改”下的说明，我尝试了：

$ git remote add upstream ...  # savon/httpi
$ git fetch upstream
$ git merge upstream/master
$ git push origin/master       # coldnebo/httpi

However, now my fork is rather messy. I'm still rather a novice with git, so instead of trying to guess what the terminology is I'll simply show you what I got and what I expected:

但是，现在我的叉子很乱。我仍然是 git 的新手，所以我不会试图猜测术语是什么，而是简单地向您展示我得到了什么和我期望什么：

• wanted this: (Showing 7 changed files with 112 additions and 5 deletions.) https://github.com/savonrb/httpi/pull/59/files

• 想要这个：（显示 7 个更改的文件，其中 112 个添加和 5 个删除。） https://github.com/savonrb/httpi/pull/59/files

This is the diff I want. Is there any way to rebase/revert and do this without losing my changes?

这是我想要的差异。有没有办法在不丢失更改的情况下重新设置/还原并执行此操作？

• got this: (324 commits covering nearly the entire project plus 4 new branches... OUCH!!) https://github.com/coldnebo/httpi/commits/master

• 得到了这个：（324 次提交几乎涵盖了整个项目加上 4 个新分支......哎哟！！） https://github.com/coldnebo/httpi/commits/master

what a mess.

真是一团糟。

maybe git pullwould have been better?

也许git pull会更好？

It's not many changes, so if it's unrecoverable I can always manually diff and remaster it, but I'm looking for the "right way" to do this in the future.

这不是很多变化，所以如果它无法恢复，我总是可以手动差异并重新制作它，但我正在寻找将来执行此操作的“正确方法”。

回答by Larry Kyrala

Ok, if your repo is fubar, then here's steps to recover:

好的，如果你的 repo 是 fubar，那么这里是恢复的步骤：

$ git remote update     # make sure origin and upstream are up to date
$ git checkout master
$ git branch my_changes   # just to make sure my stuff isn't lost
$ git reset --hard upstream/master
$ git status
# On branch master
# Your branch is behind 'origin/master' by 8 commits, and can be fast-forwarded.
#

Ignore that fast-forward crap, it won't help you, just reset the master.

忽略那些快进废话，它对您没有帮助，只需重置主程序即可。

$ git push origin +master   # now, fork matches upstream/master

Now, how to recover the previous work so it's reviewable?

现在，如何恢复以前的工作以使其可？

$ git diff --no-ext-diff --no-prefix master..my_changes > patchfile
$ patch -p0 < patchfile   # apply the patchfile to master
$ git diff     # to verify patch visually.
$ rm patchfile   # clean up
$ rake spec      # verify that it really works.
$ git add .
$ git status     # double triple verify
$ git commit .
$ git push origin master

That sucked. I tried doing rebase, but it kept saying "no changes" and didn't ask me to check anything in? I'm pretty sure I don't understand what's going on here, which is why I posted my struggle so someone can explain how I could have avoided this mess and gotten from A to B more elegantly now that it's fully documented. I'm willing to chalk this up to git inexperience, but I figure that pulling changes should be a really common thing in git -- I must be missing something.

那太糟糕了。我尝试做 rebase，但它一直说“没有变化”并且没有让我检查任何东西？我很确定我不明白这里发生了什么，这就是我发布我的斗争的原因，以便有人可以解释我如何能够避免这种混乱并且现在它已经完全记录下来，并且更优雅地从 A 到 B。我愿意将其归咎于 git 缺乏经验，但我认为在 git 中拉动更改应该是一件非常普遍的事情——我一定遗漏了一些东西。

回答by Wouter J

You should always create new branch for each Pull Request your create. Before you going to push it to github to create the request, you should rebase your branch to the latest upstream branch.

您应该始终为您创建的每个拉取请求创建新分支。在将其推送到 github 以创建请求之前，您应该将分支重新设置为最新的上游分支。

Github says you use git mergefor this, I prefer to use git rebase upstream/masterif there aren't much changes, this will prevent merge commits.

Github 说你用git merge这个，git rebase upstream/master如果没有太多变化，我更喜欢使用，这将阻止合并提交。

---

---

Sometimes the rebasing can't continue, because something what you have changed was already changed in the upstream branch. For instance, assume that you have a text.txtfile like:

有时变基无法继续，因为您更改的某些内容已在上游分支中更改。例如，假设您有一个text.txt类似以下的文件：

Lorem ipsum

You create a PR to update this to Lorem ipsum!and the upstream branch already changed this to Hello WorldIf you do a rebase, to make your code up to date before creating a request, you get a merge conflict. The file is updated with conflict markersand you can choose which version you want to use and you can even edit it, in our example we get this in text.txt:

您创建了一个PR更新这Lorem ipsum!和上游分支已经改变了这Hello World如果你做了重订，然后再创建请求，以使你的代码是最新的，你会得到一个合并冲突。该文件使用冲突标记更新，您可以选择要使用的版本，甚至可以编辑它，在我们的示例中，我们将其输入text.txt：

<<<<<<< YOUR_PR_BRANCH
Lorem Ipsum
=======
Hello World
>>>>>>> THE_UPSTREAM_BRANCH

After this, add the updated files with git addand execute git rebase --continue.

在此之后，添加更新的文件git add并执行git rebase --continue。

回答by aragaer

git pull --rebaseworks for me and keeps the history clean.

git pull --rebase对我来说有效并保持历史清洁。