Git中远程分支的重定基

nsc4cvqm  于 2022-12-25  发布在  Git
关注(0)|答案(6)|浏览(218)

我正在使用一个中间Git仓库来镜像一个远程SVN仓库,人们可以从这个仓库中克隆和工作。中间仓库的master分支每晚都从上游SVN重新定基,我们正在处理feature分支。例如:

remote:
  master

local:
  master
  feature

我可以成功地将我的特性分支推回遥控器,并以我所期望的结果结束:

remote:
  master
  feature

local:
  master
  feature

然后我重新设置分支来跟踪遥控器:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

一切都很好,我想从这里做的是把feature分支的基重定为远程的master分支,但是我想从我的本地机器上做,我希望能够做到:

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

保持远程特性分支与远程主特性分支同步更新。然而,这种方法会导致Git抱怨:

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pull确实有效,但会导致合并提交,这是我希望避免的。我担心消息声明feature -> feature而不是feature -> origin/feature,但这可能只是一个演示问题。
我是否遗漏了一些东西,或者是完全错误的方式?避免在远程服务器上执行重定基并不重要,但它会使修复重定基中的任何合并冲突变得更加困难。

z5btuh9x

z5btuh9x1#

这取决于该功能是由一个人使用还是其他人使用。
如果只有您,您可以在重定基础后强制推送:

git push origin feature -f

但是,如果其他人正在处理它,则应该合并而不是从母版中变基。

git merge master
git push origin feature

这将确保你和你正在合作的人有共同的历史。
在另一个层面上,你不应该做反向合并,因为你所做的是用其他不属于特性的提交污染特性分支的历史,使该分支的后续工作更加困难--无论是否重定基。
这是我关于branch per feature主题的文章。

oxalkeyp

oxalkeyp2#

很高兴你提起这个主题。
这是git中的一个重要概念,很多git用户都会从中受益。git rebase是一个非常强大的工具,可以让你压缩提交,删除提交等。但是和任何强大的工具一样,你基本上需要知道你在做什么,否则可能会出问题。
当你在本地工作,并且在本地分支上乱来乱去的时候,你可以做任何你想做的事情,只要你没有把修改推到中央仓库。这意味着你可以重写你自己的历史,但是不能重写其他人的历史。只在本地乱来乱去,不会对其他仓库产生任何影响。
这就是为什么要记住一旦你推送了提交,你就不应该在以后重定提交的基础。这一点之所以重要,是因为其他人可能会拉入你的提交,并将他们的工作建立在你对代码库的贡献上,如果你后来决定将这些内容从一个地方移到另一个地方(rebase它)并推动那些更改,那么其他人就会得到问题,不得不重新编写他们的代码。现在想象你有1000个开发人员:)它只是造成了大量不必要的返工。

js5cn81o

js5cn81o3#

因为您在新的master上重定了feature的基,所以本地feature不再是origin/feature的快进,所以,我认为,在这种情况下,通过执行git push origin +feature来覆盖快进检查是非常好的。

git config remote.origin.push +refs/heads/feature:refs/heads/feature

如果其他人在origin/feature上工作,他们会被这个强制更新所干扰,你可以通过将新的master合并到feature中来避免这种情况,结果确实是一个快进。

m2xkgtsf

m2xkgtsf4#

我不熟悉GitBash的使用,我在这里为那些使用Windows的开发人员添加了一个使用TortoiseGit(新蜜蜂的GUI)的答案:

像上面提到的许多人一样,如果只在你的“私有”回购分支上这样做,那就意味着没有人会因为你用本地副本重定远程“开发”或“特性”分支的基础而向你扔椅子。其他已经承诺并推动了他们一周(或更多)工作的开发人员将从分支的历史记录(日志)中删除。
没有办法恢复它们--当然,你的合作开发者仍然会保留他们的修改,因为他们的PULL很可能会抛出一个错误,因为他们会远远领先于分支的当前历史记录或最新提交。
所以,要小心使用这个恢复远程分支的能力。在此警告你。)

mqxuamgl

mqxuamgl5#

如果你和其他人一起在一个特性分支上工作,那么很可能他们已经提交了一些东西。从那时起,你不能简单地推送你的修改,因为它们与提交历史冲突。你可以做的是调用git pull,这是一个git fetch + git merge命令。这将创建另一个合并提交。
我会尽量避免历史记录中出现不必要的合并提交,并通过简单地调用git pull --rebase来保持git提交历史记录的整洁,这将把你的提交放在现有提交之后。
当然,你应该只添加本地分支的git历史,而不要修改远程分支的git历史。

fhity93d

fhity93d6#

您可以使用git push--force选项来禁用检查(如果您确实确定自己知道自己在做什么)。

相关问题