经过rebase后不能推到分支
我们使用git并拥有主分支和开发者分支。 我需要添加一个新功能，然后将提交重新设置为主，然后将主服务器推送到CI服务器。
问题是，如果我在重新绑定期间发生冲突，在重新绑定完成后，我无法将其推送到远程开发者分支（在Github上），直到我拉到远程分支。 这会导致重复的提交。 没有冲突时，按预期工作。
问题：rebase和冲突解决后，如何在不创建重复提交的情况下同步本地和远程开发者分支
建立：
// master branch is the main branch
git checkout master
git checkout -b myNewFeature
// I will work on this at work and at home
git push origin myNewFeature
// work work work on myNewFeature
// master branch has been updated and will conflict with myNewFeature
git pull --rebase origin master
// we have conflicts
// solve conflict
git rebase --continue
//repeat until rebase is complete
git push origin myNewFeature
//ERROR
error: failed to push some refs to 'git@github.com:ariklevy/dropLocker.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
// do what git says and pull
git pull origin myNewFeature
git push origin myNewFeature
// Now I have duplicate commits on the remote branch myNewFeature
编辑
所以这听起来像会打破工作流程：
在处理hisNewFeature的myNewFeature developer2上开发的developer1都使用master作为主分支
developer2将myNewFeature合并到他的NewFeature中
developer1重设，解决冲突，然后强制推送到myNewFeature的远程分支
几天后，开发人员2再次将myNewFeature合并到他的NewFeature中
这会导致其他开发者讨厌developer1吗？
首先，你和你一起工作的人需要同意一个主题/ devel分支是用于共享开发还是只用于你自己的开发。 其他开发人员不知道在我的开发分支上进行合并，因为他们随时都会进行重新设计。 通常工作流程如下：
o-----o-----o-----o-----o-----o master
o-----o-----o devel0
o-----o-----o devel1
然后为了与远程保持同步，我将执行以下操作：
git fetch origin
git checkout master
git merge --ff origin/master
我这样做有两个原因。 首先，因为它允许我查看是否存在远程更改而无需从我的devel分支切换。 其次，这是一个安全机制，以确保我不会覆盖任何未执行或未完成的更改。 另外，如果我不能快速合并到主分支，这意味着有人已经重新启动了远程主控（他们需要严重鞭打），或者我不小心承诺要掌握并需要清理我的结局。
然后，当遥控器发生变化，并且我已经快速转发到最新的时候，我会变成：
git checkout devel0
git rebase master
git push -f origin devel0
其他开发人员则知道他们需要将我的最新开发分支重新分配给他们：
git fetch <remote>
git checkout devel1
git rebase <remote>/devel0
这导致更清洁的历史记录：
o-----o master
o-----o-----o devel0
o-----o-----o devel1
不要将你的兴致来回提交。 它不仅会创建重复的提交，并且无法追踪历史记录，从特定更改中找到回归几乎是不可能的（这就是为什么您首先使用版本控制，对吗？）。 你遇到的问题就是这样做的结果。
这听起来像其他开发人员可能会提交给你的开发分支。 你能证实这一点吗？
合并唯一的时间是当你的主题分支准备好接受master 。
在旁注中。 如果多个开发人员正在提交同一个存储库，则应该考虑命名分支来区分开发人员开发分支。 例如：
git branch 'my-name/devel-branch'
所以所有开发人员主题分支都驻留在自己的嵌套集合中。
您需要强制推送，因为您已将提交进一步向下移动git期望您向提交分支添加提交。 git push -f origin myNewFeature将解决你的问题。
提示：以上是强制推送的合法用法。 永远不要在可公开访问的存储库上重写历史记录，否则很多人会恨你。
这里要记住的主要是拉和底座在幕后进行。
拉将基本上做两件事：取和合并。 当你包含--rebase时，它会做一个rebase而不是合并。
rebase几乎就像是分支后的所有本地更改，将分支快速转发到目标上的最新提交，并按顺序排列更改。
（这就解释了为什么您在进行重新分配时可能会得到多个冲突解决方案提示，而您可能会通过合并获得一个冲突解决方案。您有机会解决每个正在重新分配的提交的冲突，以便保留您的提交。 ）
因为这是重写历史记录，所以您不希望将重新发布的更改推送到远程分支。 Ofcoarse，从来没有强大，因为几乎总是有例外。 例如，您需要维护本地存储库的远程版本以在特定环境中工作。
这将需要您在使用强制的时候推送重新发布的更改：
git push -f origin newfeature
或者在某些情况下，您的管理员可能已经删除了强制的功能，因此您必须删除并重新创建：
git push origin :newfeature
git push origin newfeature
无论哪种情况，如果有人在您的远程分支上与您合作，您必须绝对确定自己在做什么。 这可能意味着，在开始掌握并删除工作分支之前，您最初与合并一起工作，并将这些合并到一个更易于管理的提交格式中。
请记住，您几乎总是可以在git的GC上使用：
git reflog
这是一个巨大的生命保护，因为如果你在所有的重设/冲突管理中迷路了，你可以重置回更稳定的状态。
链接地址: http://www.djcxy.com/p/49229.html