变基后无法推送到分支

我们使用 git 并有一个 master 分支和开发人员分支。我需要添加一个新功能，然后将提交重新设置为 master，然后将 master 推送到 CI 服务器。

问题是，如果我在变基期间发生冲突，我无法在变基完成后推送到我的远程开发人员分支（在 Github 上），直到我拉出我的远程分支。这会导致重复提交。当没有冲突时，按预期工作。

问题：在变基和冲突解决之后，如何同步本地和远程开发人员分支而不创建重复提交

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 '[email protected] /cdn-cgi/l/email-protection: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

所以听起来这会破坏工作流程：

开发人员 1 正在开发 myNewFeature 开发人员 2 正在开发 hisNewFeature 两者都使用 master 作为主分支

developer2 将 myNewFeature 合并到 hisNewFeature

developer1 变基，解决冲突，然后强制推送到 myNewFeature 的远程分支

几天后，developer2 再次将 myNewFeature 合并到 hisNewFeature

这会导致其他开发人员讨厌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

我这样做有两个原因。首先，因为它允许我查看是否有远程更改，而无需从我的开发分支切换。其次，它是一种安全机制，可确保我不会覆盖任何未隐藏/已提交的更改。另外，如果我无法快进合并到 master 分支，这意味着有人已经重新调整了远程 master 的基础（为此他们需要受到严厉的鞭打），或者我不小心提交了 master 并需要清理我的末端。

然后，当远程发生更改并且我已快进到最新版本时，我将重新设置基准：

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

Don't合并可以随心所欲地来回提交。它不仅会创建重复的提交并使历史记录无法跟踪，而且几乎不可能从特定更改中找到回归（这就是您首先使用版本控制的原因，对吧？）。您遇到的问题就是这样做的结果。

另外，听起来其他开发人员可能正在向您的开发分支做出提交。你能否证实这一点？

合并的唯一时间是当您的主题分支准备好被接受时master.

附带说明一下。如果多个开发人员提交到同一个存储库，您都应该考虑使用命名分支来区分开发人员开发分支。例如：

git branch 'my-name/devel-branch'

因此，所有开发人员主题分支都位于他们自己的嵌套集中。