#Git merge branch to master how to
#Git merge branch to master plus

See commit c25d98b () by Junio C Hamano ( gitster). Written to suggest that ' -s theirs' exists, which is not the case. The documentation for ' -X' for merges was misleadingly

#Git merge branch to master how to

While I mention in ' git command for making one branch like another' how to simulate git merge -s theirs, note that Git 2.15 (Q4 2017) is now clearer: In this or other similar/advanced cases the low-level command git commit-tree can be used. If the commit of branchB is an ancestor of branchA, git merge does not work (it just exits with a message like ' Already up to date.'). This is what Paul Pladijs's answer does (without requiring a temporary branch). # Change content of merge commit to current index (i.e. # This ensures branchA will move when doing 'commit -amend'. # Move HEAD to branchA without changing contents of working tree and index. # -detach ensures branchB will not move when doing the reset in the next step. # Change working tree and index to desired content. The content of this commit does not matter, the first parent comes from branchA and the second from branchB.

only that from branchB) but the order of parents is correct, i.e. It has the same content as in the option before (i.e. This is the real 'theirs version for git merge -s ours'. Use content from B only and keep correct parent order Note that the merge commits first parent now is that from branchB and only the second is from branchA. # Set branchA to current commit and check it out. # Do the merge an keep current (our) content from branchB we just checked out.

# else it will be advanced to the merge commit in the next step. # If you want to keep branchB at the current commit, you can add -detached, This creates a merge commit for both branches but discards all changes from branchA and only keeps the contents from branchB.

This is not the 'theirs version for git merge -s ours' but the 'theirs version for git merge -X ours' (which is short for git merge -s recursive -X ours): git checkout branchA I try to give an overview and see the following three options: See Recovering from upstream rebase.It is not entirely clear what your desired outcome is, so there is some confusion about the 'correct' way of doing it in the answers and their comments. If someone has pulled your branch, or you have pushed it somewhere, you should merge into it instead, to avoid confusion and extra work on the other end. The actual result after git rebase master in branch feature is this: ( A-B-C ) A'-B'-C' featureĬommits A, B, C are dangling after the rebase, but are reachable through git reflog feature as Merge

#Git merge branch to master plus

However, git rebase is only suitable when nobody else is working on it, or there will be confusion and extra work for them, because the old commits A, B, C are now replaced by new commits A', B', C', plus F and G that were not there before. Taking the example from the git rebase manual, git rebase master in branch feature: A-B-C feature A'-B'-C' featureĭ-E-F-G master D-E-F-G master If the branch has not been distributed to other people, in this case i would prefer git rebase.īecause git rebase makes it as if the changes on the feature branch were made on top of the changes on the master branch, which makes the version graph simpler. You can either git merge master or git rebase master.