使一个分支类似于另一个分支的git命令

Question

使一个分支类似于另一个分支的git命令

我试图把一个分支的变化，并使它回到相同的上游，它发散。这些更改都是本地的，并且已经被推送到GitHub，所以两者都没有。git reset或git rebase实际上是可行的，因为他们改变了历史，这对已经被推开的分支来说是一件坏事。

我也试过git merge使用不同的策略，但它们都不能撤消本地更改，也就是说，如果我添加了一个文件，合并可能会使其他文件恢复正常，但我仍然拥有上游没有的文件。

我可以在上游创建一个新的分支，但我真的想要一个合并，在修改历史方面，应用所有的更改，将分支重新与上游完全相同，这样我就可以在不破坏历史的情况下安全地推动这个变化。有这样的命令或一系列的命令吗？

Answer 1

您可以将您的上游分支合并到您的dev树枝，有一个自定义合并驱动程序“memtheir”:见““git merge -s theirs“需要-但我知道它不存在".在你的情况下，只有一个.gitattributes是必要的，而且keepTheirs剧本：mv&nbsp;-f&nbsp;$3&nbsp;$2 exit&nbsp;0git merge --strategy=theirs模拟#1显示为合并，上游作为第一个父级。杰弗罗米提到(在评论中)merge -s ours，将您在上游(或从上游开始的临时分支)上的工作合并，然后将您的分支快速转发到合并的结果：git&nbsp;checkout&nbsp;-b&nbsp;tmp&nbsp;origin/upstream git&nbsp;merge&nbsp;-s&nbsp;ours&nbsp;downstream&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;ignoring&nbsp;all&nbsp;changes&nbsp;from&nbsp;downstream git&nbsp;checkout&nbsp;downstream git&nbsp;merge&nbsp;tmp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;fast-forward&nbsp;to&nbsp;tmp&nbsp;HEAD git&nbsp;branch&nbsp;-D&nbsp;tmp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;deleting&nbsp;tmp这样做的好处是将上游祖先记录为第一个父级，以便合并的意思是“吸收这个过时的主题分支”，而不是“摧毁这个主题分支并将其替换为上游的分支”。.(编辑2011年)：此工作流已在“行动纲领”的博客文章:为什么我又想要这个？只要我的回购与公开版本无关，这一切都很好，但由于现在我想要与其他团队成员和外部贡献者一起整理WIP的能力，我想确保我的公共分支对于其他人来说是可靠的，可以支点和退出，即不再重新建立和重新设置我已经推送到远程备份的东西，因为它现在GitHub和public上。所以这就给我留下了我该怎么做的问题。99%的时间，我的拷贝将进入上游的主人，所以我想工作我的主人，并推动上游的大部分时间。但偶尔，我所拥有的wip会因为上游的东西而失效，我会放弃我的一部分wip.在这一点上，我想让我的主人回到与上游同步，但不破坏任何提交点，我的公开推动的主人。也就是说，我想要一个与上游的合并，最终与使我的副本与上游相同的变更集结束。.这就是git merge --strategy=theirs应该可以。git merge --strategy=theirs模拟#2显示为合并，我们作为第一个父级。(提议)jcwenger)git&nbsp;checkout&nbsp;-b&nbsp;tmp&nbsp;upstream git&nbsp;merge&nbsp;-s&nbsp;ours&nbsp;thebranch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;ignoring&nbsp;all&nbsp;changes&nbsp;from&nbsp;downstream git&nbsp;checkout&nbsp;downstream git&nbsp;merge&nbsp;--squash&nbsp;tmp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;apply&nbsp;changes&nbsp;from&nbsp;tmp&nbsp;but&nbsp;not&nbsp;as&nbsp;merge. git&nbsp;rev-parse&nbsp;upstream&nbsp;>&nbsp;.git/MERGE_HEAD&nbsp;#record&nbsp;upstream&nbsp;2nd&nbsp;merge&nbsp;head git&nbsp;commit&nbsp;-m&nbsp;"rebaselined&nbsp;thebranch&nbsp;from&nbsp;upstream"&nbsp;#&nbsp;make&nbsp;the&nbsp;commit. git&nbsp;branch&nbsp;-D&nbsp;tmp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;deleting&nbsp;tmpgit merge --strategy=theirs模拟#3这，这个博客文章提到:git&nbsp;merge&nbsp;-s&nbsp;ours&nbsp;ref-to-be-merged git&nbsp;diff&nbsp;--binary&nbsp;ref-to-be-merged&nbsp;|&nbsp;git&nbsp;apply&nbsp;-R&nbsp;--index git&nbsp;commit&nbsp;-F&nbsp;.git/COMMIT_EDITMSG&nbsp;--amend有时候你确实想这么做，而不是因为你的历史上有“垃圾”，但是也许是因为您希望更改公共存储库中的开发基线，从而避免重新建立基础。.git merge --strategy=theirs模拟#4(同一篇博客文章)或者，如果您希望保持本地上游分支的快速转发，一个潜在的折衷方案是理解对于SID/不稳定，上游分支可以不时地被重置/重基(基于最终超出您在上游项目的控制范围内的事件)。这并不是什么大问题，使用这种假设意味着很容易将本地上游分支保持在一个只需要快速更新的状态。git&nbsp;branch&nbsp;-m&nbsp;upstream-unstable&nbsp;upstream-unstable-save git&nbsp;branch&nbsp;upstream-unstable&nbsp;upstream-remote/master git&nbsp;merge&nbsp;-s&nbsp;ours&nbsp;upstream-unstable git&nbsp;diff&nbsp;--binary&nbsp;ref-to-be-merged&nbsp;|&nbsp;git&nbsp;apply&nbsp;-R&nbsp;--index&nbsp;--exclude="debian/*" git&nbsp;commit&nbsp;-F&nbsp;.git/COMMIT_EDITMSG&nbsp;--amendgit merge --strategy=theirs模拟#5(提议)巴拉克·皮尔穆特):git&nbsp;checkout&nbsp;MINE git&nbsp;merge&nbsp;--no-commit&nbsp;-s&nbsp;ours&nbsp;HERS git&nbsp;rm&nbsp;-rf&nbsp;. git&nbsp;checkout&nbsp;HERS&nbsp;--&nbsp;. git&nbsp;checkout&nbsp;MINE&nbsp;--&nbsp;debian&nbsp;#&nbsp;or&nbsp;whatever,&nbsp;as&nbsp;appropriate git&nbsp;gui&nbsp;#&nbsp;edit&nbsp;commit&nbsp;message&nbsp;&&nbsp;click&nbsp;commit&nbsp;buttongit merge --strategy=theirs模拟#6(由同一人提议)迈克尔·格贝茨):MichaelGebetsroither插嘴说我是在“作弊”；)并给出了另一个解决方案，提供了更低级别的管道命令：(如果只使用git命令是不可能的，那么git就不是git了，使用diff/修补程序/应用的git中的所有东西都不是真正的解决方案；)#&nbsp;get&nbsp;the&nbsp;contents&nbsp;of&nbsp;another&nbsp;branch git&nbsp;read-tree&nbsp;-u&nbsp;--reset&nbsp;<ID> #&nbsp;selectivly&nbsp;merge&nbsp;subdirectories #&nbsp;e.g&nbsp;superseed&nbsp;upstream&nbsp;source&nbsp;with&nbsp;that&nbsp;from&nbsp;another&nbsp;branch git&nbsp;merge&nbsp;-s&nbsp;ours&nbsp;--no-commit&nbsp;other_upstream git&nbsp;read-tree&nbsp;--reset&nbsp;-u&nbsp;other_upstream&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;#&nbsp;or&nbsp;use&nbsp;--prefix=foo/ git&nbsp;checkout&nbsp;HEAD&nbsp;--&nbsp;debian/ git&nbsp;checkout&nbsp;HEAD&nbsp;--&nbsp;.gitignore git&nbsp;commit&nbsp;-m&nbsp;'superseed&nbsp;upstream&nbsp;source'&nbsp;-a

Answer 2

我觉得你只需要做：$&nbsp;git&nbsp;reset&nbsp;--hard&nbsp;origin/master如果没有任何改变来推动上游，而您只是希望上游分支成为您的当前分支，这将做到这一点。在当地这样做是无害的。但您将失去任何未被推送到主控的本地更改。*实际上，如果您已在本地提交更改，则更改仍然存在，因为提交仍在您的git reflog，通常至少30天。

Answer 3

现在您可以很容易地做到这一点：$&nbsp;git&nbsp;fetch&nbsp;origin $&nbsp;git&nbsp;merge&nbsp;origin/master&nbsp;-s&nbsp;recursive&nbsp;-Xtheirs这将使您的本地回购与原始同步，并保存历史记录。