重新设置基准后无法推送到分支 [英] can't push to branch after rebase
问题描述
我们使用git并具有master分支和developer分支.我需要添加一个新功能，然后将提交重新分配到主服务器，然后将主服务器推送到CI服务器.
问题是，如果我在重新设置基准时遇到冲突，则在完成重新基准设置后，我无法将其推送到我的远程开发人员分支(在Github上)，直到我拉出远程分支为止.这将导致重复的提交.没有冲突时，按预期方式工作.
问题:在重新设置基础和解决冲突之后，如何在不创建重复提交的情况下同步本地和远程开发人员分支
设置:
// 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
编辑
所以听起来这会中断工作流程:
developer1在myNewFeature上工作 developer2正在研究他的NewFeature 都使用master作为主要分支
developer2将myNewFeature合并到他的NewFeature
developer1重新定位，解决冲突，然后为myNewFeature强制推送到远程分支
几天后，developer2将myNewFeature再次合并到他的NewFeature中
这会导致其他开发人员讨厌developer1吗?
首先，您和与您一起工作的人都需要同意主题/开发分支是用于共享开发还是您自己的.其他开发人员知道不合并在我的开发分支上，因为它们会随时重新设置基础.通常，工作流程如下:
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分支进行切换.其次，这是一种安全机制，可确保我不会覆盖任何未隐藏的/已提交的更改.另外，如果我无法快速合并到master分支，则意味着有人重新建立了远程master的基础(需要对其进行严重干预)，或者我无意中承诺要掌握master并需要清理末端.
然后，当遥控器发生更改并且我已将其快速转发到我将要重新定位的最新版本时:
git checkout devel0
git rebase master
git push -f origin devel0
其他开发人员然后知道他们需要根据我的最新消息重新建立其devel分支:
git fetch <remote>
git checkout devel1
git rebase <remote>/devel0
这将导致更清晰的历史记录
o-----o master
\
o-----o-----o devel0
\
o-----o-----o devel1
请勿合并会随心所欲地来回提交.它不仅会创建重复的提交，并使历史记录无法遵循，而且从特定更改中查找回归几乎变得不可能了(这就是为什么首先要使用版本控制，对吗?).您遇到的问题就是这样做的结果.
另外，听起来其他开发人员可能正在对您的devel分支进行提交.你可以确认吗?
唯一的合并时间是您的主题分支准备好被接受到master中.
在旁注.如果多个开发人员正在提交同一个存储库，则所有人都应考虑使用命名分支来区分开发人员开发分支.例如:
git branch 'my-name/devel-branch'
因此，所有开发人员主题分支都位于其自己的嵌套集中.
We use git and have a master branch and developer branches. I need to add a new feature and then rebase the commits to master, then push master to CI server.
The problem is that if I have conflicts during rebase I cannot push to my remote developer branch (on Github) after the rebase is complete, until I pull my remote branch. This causes duplicate commits. When there are no conflicts, works as expected.
question: after rebase and conflict resolution, how do I sync up my local and remote developer branches without creating duplicate commits
Setup:
// 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
EDIT
So it sounds like this will break the workflow:
developer1 working on myNewFeature developer2 working on hisNewFeature both use master as main branch
developer2 merges myNewFeature into hisNewFeature
developer1 rebases, resolves conflicts, then force pushes to remote branch for myNewFeature
a couple days later, developer2, merges myNewFeature into hisNewFeature again
Will this cause the other developers to hate developer1?
First, you and those you're working with need to agree whether a topic/devel branch is for shared development or just your own. Other developers know not to merge on my development branches because they'll be rebased at any time. Usually the workflow is as follows:
o-----o-----o-----o-----o-----o master
\
o-----o-----o devel0
\
o-----o-----o devel1
Then to stay up-to-date with remote I'll do the following:
git fetch origin
git checkout master
git merge --ff origin/master
I do this for two reasons. First because it allows me to see if there are remote changes without needing to switch from my devel branch. Second it's a safety mechanism to make sure I don't overwrite any un-stashed/committed changes. Also, if I can't fast-forward merge to the master branch that means either someone has rebased the remote master (for which they need to be flogged severely) or I accidentally committed to master and need to clean up my end.
Then when remote has changes and I've fast forwarded to the latest I'll rebase:
git checkout devel0
git rebase master
git push -f origin devel0
Other developers then know they'll need to rebase their devel branches off my latest:
git fetch <remote>
git checkout devel1
git rebase <remote>/devel0
Which results in much cleaner history:
o-----o master
\
o-----o-----o devel0
\
o-----o-----o devel1
Don't merge commits back and forth at your whim. Not only does it create duplicate commits and make history impossible to follow, finding regressions from a specific change becomes near impossible (which is why you're using version control in the first place, right?). The problem you're having is the result of doing just this.
Also it sounds like other developers may be making commits to your devel branches. Can you confirm this?
The only time to merge is when your topic branch is ready to be accepted into master.
On a side note. If multiple developers are committing to the same repository you should all consider having named branches to distinguish between developers devel branches. For example:
git branch 'my-name/devel-branch'
So all developers topic branches reside within their own nested set.
这篇关于重新设置基准后无法推送到分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
