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

时间:2013-01-07 15:48:55

标签: git github

我有点发脾气。

几个月前,我开始在一个回购的分支上开发。我做了一些改变。我打算将我的代码作为拉取请求推回到主服务器,但我意识到在此期间有很多变化......

所以,{Pull in Upstream Changes'中的following the instructions at Github我试过了:

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

然而,现在我的叉子很乱。我仍然是git的新手,所以不要试图猜测术语是什么,我只会告诉你我得到的和我的预期:

这是我想要的差异。有没有办法在不丢失我的更改的情况下进行rebase / revert并执行此操作?

真是一团糟。

也许git pull本来会更好?

这并没有太多变化,所以如果它不可恢复,我总是可以手动区分并重新管理它,但我正在寻找将来这样做的“正确方法”。

3 个答案:

答案 0 :(得分:5)

您应始终为您创建的每个Pull Request创建新分支。在您将其推送到github以创建请求之前,您应该将您的分支重新绑定到最新的上游分支。

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


有时,变基不能继续,因为您已更改的内容已在上游分支中更改。例如,假设您有一个text.txt文件,如:

Lorem ipsum

您创建一个PR以将其更新为Lorem ipsum!,并且上游分支已将其更改为Hello World如果您执行了rebase,要在创建请求之前使代码保持最新,您将获得合并冲突。该文件已使用冲突标记进行更新,您可以选择要使用的版本,甚至可以对其进行编辑,在我们的示例中,我们会在text.txt中进行编辑:

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

在此之后,使用git add添加更新的文件并执行git rebase --continue

答案 1 :(得分:5)

好的,如果你的回购是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.
#

忽略那个快进的垃圾,它不会帮助你,只是重置主人。

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

现在,如何恢复以前的工作,以便可以审核?

$ 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

那很糟糕。我尝试做rebase,但它一直说“没有变化”,并没有要求我检查任何东西?我很确定我不明白这里发生了什么,这就是为什么我发布了我的斗争所以有人可以解释为什么我可以避免这种混乱,并且更加优雅地从A到B从现在已经完全记录下来了。我愿意用这些来解决经验不足的问题,但我认为拉动变化应该是git中非常普遍的事情 - 我必须遗漏一些东西。

答案 2 :(得分:1)

git pull --rebase适合我并保持历史清洁。