![the the](https://c1.lmlphp.com/image/static/default_avatar.gif)
本文介绍了在Git中重新设置远程分支的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!
问题描述
我正在使用中间Git存储库来镜像远程SVN存储库,人们可以从中进行克隆和处理。中间存储库的主分支夜间从上游SVN重新分发,我们正在开发功能分支。例如:
远程:
主人
本地人:
主人
功能
我可以成功地将我的功能分支返回到远程,并最终得到我预计:
远程:
主人
功能
local:
master
功能
然后重新设置分支来跟踪远程:
远程:
主人
功能
本地:
大师
功能 - >原产地/特征
一切都很好。我想从这里做的是将功能分支重新绑定到远程主分支,但我想从我的本地计算机执行此操作。我希望能够做到:
git checkout master
git pull
git checkout功能
git rebase master
git push origin feature
要保持远程功能分支与远程主机保持最新状态。但是,这种方法会导致Git抱怨:
要< remote>
! [被拒绝]功能 - >功能(非快进)
错误:无法将某些参考推送到'<远程>'
为防止您丢失历史记录,非快进更新被拒绝
合并在再次推送之前,远程更改(例如'git pull')。有关详细信息,请参阅git push --help的快速转发部分的
'注意事项。
git pull
合并提交,我想避免。我担心这条消息显示功能 - >功能
而不是功能 - > origin / feature
但这可能只是一个演示文稿。
我是否错过了某些东西,或者完全以错误的方式解决这个问题?避免在远程服务器上执行rebase并不重要,但它可以更大限度地解决来自rebase的任何合并冲突更难。
解决方案这涉及到该功能是由一个人使用还是其他人正在使用它。
如果只是你,你可以强制推出rebase之后推送:
git push origin feature -f
然而,如果其他人正在处理它,你应该合并
git merge master
git push origin特性
这将确保您与您合作的人有共同的历史记录。
这是我关于这个主题的文章,名为。
希望这有助于。
I am using an intermediate Git repository to mirror a remote SVN repository, from which people can clone and work on. The intermediate repository has it's master branch rebased nightly from the upstream SVN, and we are working on feature branches. For example:
remote:
master
local:
master
feature
I can successfully push my feature branch back to the remote, and end up with what I expect:
remote:
master
feature
local:
master
feature
I then re-setup the branch to track the remote:
remote:
master
feature
local:
master
feature -> origin/feature
And all is well. What I would like to do from here is to rebase the feature branch to the master branch on the remote, but I would like to do this from my local machine. I'd like to be able to do:
git checkout master
git pull
git checkout feature
git rebase master
git push origin feature
To keep the remote feature branch up-to-date with the remote master. However, this method causes Git to complain:
To <remote>
! [rejected] feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
git pull
does the trick but causes a merge commit that I'd like to avoid. I'm concerned that the message states feature -> feature
rather than feature -> origin/feature
but this may just be a presentation thing.
Am I missing something, or going about this in completely the wrong way? It's not critical to avoid doing the rebase on the remote server, but it makes fixing any merge conflicts from the rebase much harder.
解决方案
It comes down to whether the feature is used by one person or if others are working off of it.
You can force the push after the rebase if it's just you:
git push origin feature -f
However, if others are working on it, you should merge and not rebase off of master.
git merge master
git push origin feature
This will ensure that you have a common history with the people you are collaborating with.
On a different level, you should not be doing back-merges. What you are doing is polluting your feature branch's history with other commits that don't belong to the feature, making subsequent work with that branch more difficult - rebasing or not.
This is my article on the subject called branch per feature.
Hope this helps.
这篇关于在Git中重新设置远程分支的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!