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.
You can actually do an empty rebase with:
git rebase --interactive HEAD
Now, just paste in additional hashes that you want to pick:
pick 1efd396b * Fixed a bug in frob function
pick f01934db * Awesome feature added
pick 6fd109c1 * Refactored the widgets layer
squash 3900fd77 * Refactored the widgets layer s'more
To produce the pick lists for this method, use git log --oneline --reverse from..to, then trim the output needed and prepend the rebase commands to each line: pick, squash
ref~ is shorthand for ref~1 and means the commit's first parent. ref~2 means the commit's first parent's first parent. ref~3 means the commit's first parent's first parent's first parent. And so on.
ref^ is shorthand for ref^1 and means the commit's first parent. But where the two differ is that ref^2 means the commit's second parent (remember, commits can have two parents when they are a merge).
# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32
# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop