The interactive rebase command was originally designed to handle individual patch series. As such, it makes sense to exclude merge commits from the todo list, as the developer may have merged the then-current master while working on the branch, only to rebase all the commits onto master eventually (skipping the merge commits).
CONFLICT (rename/rename): Rename "will-be-renamed.txt"->"new-name-1.txt" in branch "HEAD" rename "will-be-renamed.txt"->"new-name-2.txt" in "branch2"
Automatic merge failed; fix conflicts and then commit the result.
If you want to keep one file, say new-name-2.txt:
git add new-name-2.txt
git rm new-name-1.txt will-be-renamed.txt
git commit
git revert -m 1 <merge-commit>
With ‘-m 1’ we tell git to revert to the first parent of the mergecommit on the master branch. -m 2 would specify to revert to the first parent on the develop branch where the merge came from initially
(lieber vorher prüfen welcher branch welcher ist)
git merge -s ours branch1
The Ours strategy operates on multiple N number of branches. The output merge result is always that of the current branch HEAD. The "ours" term implies the preference effectively ignoring all changes from all other branches. It is intended to be used to combine history of similar feature branches.
You can force Git to detect the history of the copied file:
Instead of copying, switch to a new branch and move the file to its new location there.
Switch to the original branch and rename the file.
Merge the new branch into the original branch, resolving the trivial conflict by keeping both files.
Restore the original filename in a separate commit.