git - rebase 后无法推送到分支

标签 git merge rebase git-merge git-rebase

我们使用 git 并有一个 master 分支和 developer 分支。我需要添加一个新功能,然后将提交 rebase 到 master,然后将 master 推送到 CI 服务器。

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

问题:在 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

编辑

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

developer1 正在处理 myNewFeature developer2 正在处理 hisNewFeature 都使用 master 作为主要分支

developer2 将 myNewFeature merge 到 hisNewFeature

developer1 rebase ,解决冲突,然后强制推送到 myNewFeature 的远程分支

几天后,developer2 再次将 myNewFeature merge 到 hisNewFeature

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

最佳答案

首先,您和您的合作伙伴需要就主题/开发分支是用于共享开发还是仅用于您自己的开发达成一致。其他开发人员知道不要 merge 我的开发分支,因为它们会随时重新设置基础。通常的工作流程如下:

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

我这样做有两个原因。首先,因为它允许我查看是否有远程更改,而无需从我的开发分支切换。其次,它是一种安全机制,可确保我不会覆盖任何未 stash/提交的更改。另外,如果我不能快进 merge 到 master 分支,这意味着要么有人重新设置了远程 master 的基址(为此他们需要被严厉鞭打),要么我不小心提交到 master 并且需要清理我的结束。

然后当远程发生变化时,我已经快速转发到最新的我将重新设置基准:

git checkout devel0
git rebase master
git push -f origin devel0

然后其他开发人员就知道他们需要将他们的开发分支从我的最新分支中 rebase :

git fetch <remote>
git checkout devel1
git rebase <remote>/devel0

这会产生更清晰的历史记录:

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

不要随心所欲地来回 merge 提交。它不仅会创建重复提交并使历史无法追踪,而且几乎不可能从特定更改中找到回归(这就是您首先使用版本控制的原因,对吗?)。您遇到的问题是这样做的结果。

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

merge 的唯一时间是当您的主题分支准备好被master接受时。

旁注。如果多个开发人员提交到同一个存储库,你们都应该考虑命名分支以区分开发人员开发分支。例如:

git branch 'my-name/devel-branch'

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

关于git - rebase 后无法推送到分支,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15143042/

相关文章:

git - git "added by us"是什么意思?

Git 将修补程序分支 merge 到功能分支,然后删除修补程序分支?

git - 解决 SmartGit 中的冲突 - 查找冲突文件

git - 从另一个分支重新建立一个分支,该分支是从 master 重新建立的

ruby-on-rails - 使用 Git 和 Heroku 进行适当的持续集成和持续部署

git - 有没有办法将 Git 限制为稀疏 checkout ?

Git .. 压缩特定的提交

php - 使用 phpSpreadSheet 在 excel 中合并

r - 我可以在不使用 merge() 函数的情况下使用 data.table 执行此操作吗?

mercurial - 如何将一些变更集移动到 Mercurial 中的新分支