重设基础后无法推至分支

Question

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

问题是，如果我在rebase期间有冲突，我就不能在rebase完成后推送到我的远程开发人员分支(在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 '[e-mail]: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

因此，听起来这将打破工作流程:

开发人员1开发我的新功能开发人员2开发他的新功能两者都使用master作为主分支

developer2将myNewFeature合并到他的NewFeature中

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

几天后，developer2再次将我的新功能合并到他的新功能中

这会导致其他开发人员讨厌developer1吗？

Answer 1

这里要记住的主要事情是拉和变基在幕后做什么。

拉主要做两件事:获取和合并。当您包含- rebase时，它将执行rebase而不是merge。

重定基础非常类似于存储自分支以来的所有本地更改，将分支快进到目标上的最新提交，并在顶部按顺序取消存储您的更改。

（这就解释了为什么在执行衍合时可能会收到多个冲突解决提示，而不是通过合并可能获得的一个冲突解决。您有机会解决每个提交上的冲突，该冲突正在被重新定位，以便以其他方式保留您的提交。

您永远不要将基于基础的变更推送到远程分支机构，因为这是在重写历史。当然,“从不”有点过了，因为几乎总有例外。例如，您需要维护本地存储库的远程版本，以便在特定的环境中工作。

这将需要您不时地使用强制手段来推动重新设定的变更:

git push -f origin newfeature

或者，在某些情况下，您的管理员可能已删除了强制功能，因此您必须删除并重新创建：

git push origin :newfeature
git push origin newfeature

在任何一种情况下，如果其他人在您的远程分支上与您合作，您都必须绝对确定您知道自己在做什么。这可能意味着您最初使用合并进行合作，并在掌握和删除您的工作分支之前将它们重新调整为更易于管理的提交格式。

请记住，您几乎总是可以通过利用以下优势来回退git的GC：

git reflog

这是一个巨大的救命稻草，因为如果你迷失在所有的重置/冲突管理中，你可以重置回一个更稳定的状态。

Answer 2

当你把提交进一步往下移动时，你需要强制推送，git期望你把提交添加到分支的顶端。git 推送 -f 起源 我的新功能将解决您的问题。

提示：以上是用力推的合法用法。永远不要在可公开访问的存储库上重写历史，否则很多人会恨你。

Answer 3

首先，您和您的同事需要就一个topic/devel分支是用于共享开发还是仅用于您自己的开发达成一致。其他开发人员知道不要在我的开发分支上合并，因为他们会在任何时候被重置。通常工作流程如下:

o-----o-----o-----o-----o-----o       master
 \
   o-----o-----o                      devel0
                \
                  o-----o-----o       devel1

然后，为了与remote保持同步，我将执行以下操作:

 git fetch origin
 git checkout master
 git merge --ff origin/master

我这样做有两个原因。首先是因为它允许我查看是否有远程更改，而不需要从我的devel分支进行切换。其次，这是一种安全机制，确保我不会覆盖任何未隐藏/提交的更改。此外，如果我不能快进合并到主分支，这意味着要么有人已经rebased远程主(为此他们需要受到严厉的鞭笞)，要么我不小心提交到主，需要清理我的结束。

然后，当远程有更改并且我已经快进到最新版本时，我会重新调整：

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

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

另外，听起来其他开发人员可能正在向您的devel分支提交。你能确认一下吗？

只有当您的主题分支准备好被< code>master接受时，才可以进行合并。

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

git branch 'my-name/devel-branch'

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