blocks|key|664389|text|您可以通过使用git+push的--force选项来禁用检查(如果您确实知道自己在做什么)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|664390|entityMap^0|7|8|G|7|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

You can disable the check (if you're really sure you know what you're doing) by using the <code>--force</code> option to <code>git push</code>.

blocks|key|664458|text|因为您在新的master之上重新建立了feature的基础，所以您的本地feature不再是origin/feature的快进。所以，我认为，在这种情况下，完全可以通过执行git+push+origin+%2Bfeature来覆盖快进检查。您也可以在配置中指定这一点|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|664459|git+config+remote.origin.push+%2Brefs/heads/feature:refs/heads/feature|code-block|syntax|javascript|664460|如果其他人在origin/feature上工作，他们会受到这种强制更新的干扰。您可以通过将新的master合并到feature中而不是重新设置基址来避免这种情况。结果确实是快进的。|664461|entityMap^0|6|6|J|7|10|7|1A|E|2E|O|0|0|6|E|1B|6|1K|7|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|Z|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|N|$]]

Because you rebased <code>feature</code> on top of the new <code>master</code>, your local <code>feature</code> is not a fast-forward of <code>origin/feature</code> anymore. So, I think, it's perfectly fine in this case to override the fast-forward check by doing <code>git push origin +feature</code>. You can also specify this in your config 

<pre><code>git config remote.origin.push +refs/heads/feature:refs/heads/feature
</code></pre>

If other people work on top of <code>origin/feature</code>, they will be disturbed by this forced update. You can avoid that by merging in the new <code>master</code> into <code>feature</code> instead of rebasing. The result will indeed be a fast-forward.

blocks|key|664526|text|归根结底，这个功能是由一个人使用的，还是其他人正在使用它的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|664527|如果只有你一个人，你可以在rebase之后强制推送：|664528|git+push+origin+feature+-f|code-block|syntax|javascript|664529|但是，如果其他人正在处理它，您应该合并，而不是从master重新建立基础。|664530|git+merge+master
git+push+origin+feature|664531|这将确保您与与您合作的人有共同的历史。|664532|在不同的层面上，你不应该做反向合并。你所做的是用其他不属于该功能的提交来污染你的功能分支的历史记录，使得后续的工作变得更加困难-不管是不是重新建立基础。|664533|这是我的一篇题为branch+per+feature的文章。|offset|length|664534|希望这能有所帮助。|664535|entityMap|0|LINK|mutability|MUTABLE|url|http://dymitruk.com/blog/2012/02/05/branch-per-feature/^0|0|0|0|0|0|0|0|8|I|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|17|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|18|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@$S|1C|T|1D|1|1E]]|A|$]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

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:

<pre><code>git push origin feature -f
</code></pre>

However, if others are working on it, you should merge and not rebase off of master.

<pre><code>git merge master
git push origin feature
</code></pre>

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 <a href="http://dymitruk.com/blog/2012/02/05/branch-per-feature/">branch per feature</a>.

Hope this helps.

blocks|key|881705|text|很高兴你提出了这个话题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|881706|这是git中一个重要的东西/概念，许多git用户将从了解中受益。git+rebase是一个非常强大的工具，可以让你一起挤压提交，删除提交等。但和任何强大的工具一样，你基本上需要知道你在做什么，否则可能会出现真正的错误。|881707|当您在本地工作并处理本地分支时，只要您没有将更改推送到中央存储库，就可以做任何您想做的事情。这意味着你可以重写自己的历史，但不能重写其他人的历史。通过只摆弄你本地的东西，任何东西都不会对其他库产生任何影响。|881708|这就是为什么重要的是要记住，一旦你推送了提交，你就不应该在以后重新建立它们的基础。这很重要的原因是，其他人可能会把你的提交工作拉进来，并将他们的工作建立在你对代码库的贡献上，如果你后来决定将内容从一个地方移动到另一个地方(重新建立基础)并推动这些更改，那么其他人就会遇到问题，不得不重新建立他们的代码基础。现在假设你有1000名开发人员:)这只会导致大量不必要的返工。|881709|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Nice that you brought this subject up.

This is an important thing/concept in git that a lof of git users would benefit from knowing. git rebase is a very powerful tool and enables you to squash commits together, remove commits etc. But as with any powerful tool, you basically need to know what you're doing or something might go really wrong.

When you are working locally and messing around with your local branches, you can do whatever you like as long as you haven't pushed the changes to the central repository. This means you can rewrite your own history, but not others history. By only messing around with your local stuff, nothing will have any impact on other repositories.

This is why it's important to remember that once you have pushed commits, you should not rebase them later on. The reason why this is important, is that other people might pull in your commits and base their work on your contributions to the code base, and if you later on decide to move that content from one place to another (rebase it) and push those changes, then other people will get problems and have to rebase their code. Now imagine you have 1000 developers :) It just causes a lot of unnecessary rework.

blocks|key|664801|text|我不熟悉GitBash的使用，我在这里为使用TortoiseGit的开发者添加了一个答案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|664802|​|664803|📷|atomic|offset|length|664804|664805|就像上面提到的许多人一样，如果只使用你的“私有”repo分支，就可以做到这一点，这意味着没有人会因为用你的本地副本重新建立远程“开发”或“功能”分支的基础而向你扔椅子。其他开发人员已经提交并推动了他们一周(或更多)的工作，他们将从分支的历史记录(日志)中删除。|664806|没有办法恢复它们-当然，你的联合开发人员仍然会在他们的更改上，因为他们的拉动很可能会抛出错误，因为他们将远远领先于分支当前历史或最新提交与他们的。好在Git是一个分布式版本控制系统。|664807|因此，要小心恢复远程分支的能力。特此警告你。;)|664808|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/9496b4ddeb424161c18637526a7e57db.png|imageAlt^0|0|0|0|1|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@$G|11|H|12|1|13]]|A|$]]|$1|I|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|17|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W|X|-4]]]]

I am unfamiliar using GitBash and I am adding an answer using TortoiseGit (GUI for newbees) here for those devs using Windows:
<a href="https://i.stack.imgur.com/tAbL0.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/tAbL0.png" alt="Force re-basing remote branch with local branch using TortoiseGit" /></a>
Like many mentioned above, do this if only with your &quot;private&quot; repo branch and that means no one will ever throw a chair at you for re-basing the remote &quot;develop&quot; or &quot;feature&quot; branch with your local copy. The other devs who've committed and pushed their week's worth (or more) of work will be ERASED from the branch's history (log).
There will be no way to recover them - of course your co-developers will still have their changes on theirs as their PULL will most likely throw an error as they will be way way ahead of the branch current history or latest commits vs. theirs. Good thing Git is a distributed versioning system.
So, be careful with this power to reverting a remote branch. You are hereby warned. ;)

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:

<pre><code>remote:
 master

local:
 master
 feature
</code></pre>

I can successfully push my feature branch back to the remote, and end up with what I expect:

<pre><code>remote:
 master
 feature

local:
 master
 feature
</code></pre>

I then re-setup the branch to track the remote:

<pre><code>remote:
 master
 feature

local:
 master
 feature -&gt; origin/feature
</code></pre>

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:

<pre><code>git checkout master
git pull
git checkout feature
git rebase master
git push origin feature
</code></pre>

To keep the remote feature branch up-to-date with the remote master. However, this method causes Git to complain:

<pre><code>To &lt;remote&gt;
 ! [rejected] feature -&gt; feature (non-fast-forward)
error: failed to push some refs to '&lt;remote&gt;'
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.
</code></pre>

<code>git pull</code> does the trick but causes a merge commit that I'd like to avoid. I'm concerned that the message states <code>feature -&gt; feature</code> rather than <code>feature -&gt; origin/feature</code> 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.

Rebasing remote branches in Git

版本控制系统

服务器

我正在使用一个中间的Git存储库来镜像一个远程SVN存储库，人们可以从其中进行克隆和工作。中间存储库的主分支每晚从上游SVN重新定位，我们正在处理功能分支。例如：remote:  masterlocal:  master  feature我可以成功地将我的功能分支推送回遥控器，并最终得到我期望的结果：remote:  ...

问在Git中重置远程分支的基础
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Git中重置远程分支的基础EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Git中重置远程分支的基础
EN