git git合并重命名的文件

git merge with renamed files

提问by respectTheCode

I have a large website that I am moving into a new framework and in the process adding git. The current site doesn't have any version control on it.

我有一个大型网站，我正在迁移到一个新框架并在此过程中添加 git。当前站点没有任何版本控制。

I started by copying the site into a new git repository. I made a new branch and made all of the changes that were needed to make it work with the new framework. One of those steps was changing the file extension of all of the pages.

我首先将该站点复制到一个新的 git 存储库中。我创建了一个新分支并进行了使其与新框架一起工作所需的所有更改。其中一个步骤是更改所有页面的文件扩展名。

Now in the time that I have been working on the new site changes have been made to files on the old site. So I switched to master and copied all of those changes in.

现在，在我处理新站点的这段时间里，对旧站点上的文件进行了更改。所以我切换到 master 并复制了所有这些更改。

The problem is when I merge the branch with the new framework back onto master there is a conflict on every file that was changed on the master branch.

问题是当我将分支与新框架合并回 master 时，在 master 分支上更改的每个文件都存在冲突。

I wouldn't be to worried about it but there are a couple of hundred files with changes. I have tried git rebaseand git rebase --mergewith no luck.

我不会担心它，但有几百个文件发生了变化。我曾尝试git rebase和git rebase --merge没有运气。

How can I merge these 2 branches without dealing with every file?

如何在不处理每个文件的情况下合并这两个分支？

采纳答案by respectTheCode

I figured out a fix. Since the renaming of the files was done by a script I was able to copy the new .php files and rerun the script before the merge. Since the files had the same name the merge worked without conflicts.

我想出了一个解决办法。由于文件的重命名是由脚本完成的，因此我能够复制新的 .php 文件并在合并之前重新运行脚本。由于文件具有相同的名称，因此合并工作没有冲突。

Here are the steps for the whole process.

以下是整个过程的步骤。

1. Create git repo git init
2. Copy existing files in
3. Commit
4. Run script to rename files
5. Commit
6. Create a branch but don't check it out
7. Make fixes committing changes as you go
8. Checkout the branch you made in step 6
9. Copy the new versions of the files
10. Run the script to rename the files (this should replace the ones from the first run)
11. Commit
12. Checkout master
13. merge the branch into master

1. 创建 git 仓库 git init
2. 将现有文件复制到
3. 犯罪
4. 运行脚本重命名文件
5. 犯罪
6. 创建一个分支但不检查它
7. 进行修复，随时提交更改
8. 签出您在第 6 步中创建的分支
9. 复制文件的新版本
10. 运行脚本以重命名文件（这应该替换第一次运行的文件）
11. 犯罪
12. 结账师傅
13. 将分支合并到 master

This works because to git the changes were made to the files with the new name.

这是有效的，因为 git 对具有新名称的文件进行了更改。

回答by Tilman Vogel

Since git 1.7.4, you can specify the rename threshold for merge as git merge -X rename-threshold=25in order to control that a similarity of 25% is already enough to consider two files rename candidates. This, depending on the case together with -X ignore-space-changemay make rename detection more reliable.

从 git 1.7.4 开始，您可以为合并指定重命名阈值，git merge -X rename-threshold=25以控制 25% 的相似度已经足以考虑两个文件重命名候选者。这取决于情况与-X ignore-space-change可能使重命名检测更可靠。

However, I wanted to have more direct control and was cooking up a related script the last days. Maybe it helps - let me know.

但是，我想要更直接的控制，并且在最近几天编写了一个相关的脚本。也许它有帮助 - 让我知道。

https://gist.github.com/894374

https://gist.github.com/894374

回答by Jakub Nar?bski

Should have work automatically, thanks to rename detection. Below there is sample session:

由于重命名检测，应该可以自动工作。下面是示例会话：

$ git init test
Initialized empty Git repository in /tmp/jnareb/test/.git/
$ cp ~/git/README .    # example file, large enough so that rename detection works
$ git add .
$ git commit -m 'Initial commit'
[master (root-commit) b638320] Initial commit
 1 files changed, 54 insertions(+), 0 deletions(-)
 create mode 100644 README
$ git checkout -b new-feature        
Switched to a new branch 'new-feature'
$ git mv README README.txt
$ git commit -m 'Renamed README to README.txt'
[new-feature ce7b731] Renamed README to README.txt
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename README => README.txt (100%)
$ git checkout master
Switched to branch 'master'
$ sed -e 's/UNIX/Unix/g' README+ && mv -f README+ README
$ git commit -a -m 'README changed'
[master 57b1114] README changed
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git merge new-feature 
Merge made by recursive.
 README => README.txt |    0
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename README => README.txt (100%)

If you were doing "git merge master" on 'new-feature' branch instead of, like above, "git merge new-feature" on 'master', you would get:

如果您在 'new-feature' 分支上执行“git merge master”，而不是像上面那样在 'master' 上执行“git merge new-feature”，您将得到：

$ git merge master
Merge made by recursive.
 README.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Could you tell what you were doing differently?

你能说出你在做什么不同吗？

Note that ordinary "git rebase" (and "git pull --rebase") do not pick up renames: you need to run "git rebase -m" or interactive rebase.

请注意，普通的“git rebase”（和“git pull --rebase”）不会重命名：您需要运行“git rebase -m”或交互式 rebase。

回答by JBCP

In my case when rename detection failed, I found that during merge resolution I could do the following:

在重命名检测失败的情况下，我发现在合并解析期间我可以执行以下操作：

Given:

鉴于：

fileA: A modified file that was moved to the new place but is currently in the old place.
destB: The location where fileB was moved to. This could include a new filename.

Run these commands:

运行这些命令：

git add fileA
git mv fileA destB

Thats all I had to do. Then I committed and the rebase continued.

这就是我所要做的。然后我提交了，rebase 继续。

回答by Kannan Ramamoorthy

Adding to @Tilman's answer, with the recent git the rename option is -X find-renames=<n>

添加到@Tilman 的答案中，使用最近的 git 重命名选项是 -X find-renames=<n>