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.