我遇到了类似的问题,我通过重新调整我的工作以匹配目标文件组织来解决它。这是有效的,因为 git 会跟踪文件content,因此通过在重命名之上进行变基,可以根据需要应用更改。
更准确地说,假设您修改了original.txt
在你的分支机构(local
分支),但在主分支上,original.txt
已被复制到另一个,比如说copy.txt
。
此副本已在我们命名为 commit 的提交中完成CP
.
您想要应用所有本地更改,提交A
and B
下面,是在original.txt
, 到新文件copy.txt
.
---- X -----CP------ (master)
\
`--A---B--- (local)
创建一个一次性分支move
在你的改变的起点git branch move X
。也就是说,把move
提交时分支X
,您要合并的提交之前的那个;最有可能的是,这是您分支以实施更改的提交。作为用户@迪戈里杜写在下面,你可以做git merge-base master local
找到X
.
---- X (move)-----CP----- (master)
\
`--A---B--- (local)
在此分支上,发出以下重命名命令:
git mv original.txt copy.txt
这会重命名该文件。注意copy.txt
此时您的树中尚不存在。
提交您的更改(我们将此提交命名为MV
).
,--MV (move)
/
---- X -----CP----- (master)
\
`--A---B--- (local)
您现在可以在以下基础上重新调整您的工作move
:
git rebase move local
这应该没有问题,并且您的更改将应用到copy.txt
在您当地的分行。
,--MV (move)---A'---B'--- (local)
/
---- X -----CP----- (master)
现在,您不一定想要或需要提交MV
在主分支的历史记录中,因为移动操作可能会导致与提交时的复制操作发生冲突CP
在主分支中。
您只需再次重新调整您的工作,放弃移动操作,如下所示:
git rebase move local --onto CP
... 在哪里CP
是提交在哪里copy.txt
被引入到另一个分支。
这将重新调整所有更改的基础copy.txt
在上面CP
犯罪。
现在,你的local
分支就像你总是修改一样copy.txt
并不是original.txt
,并且您可以继续与其他人合并。
,--A''---B''-- (local)
/
-----X-------CP----- (master)
重要的是,这些更改要应用到CP
或以其他方式copy.txt
将不存在并且更改将应用回original.txt
.
希望这一点是清楚的。
这个答案来晚了,但这可能对其他人有用。