The key point to remember is that the feature branch was reset to the current master, and changes were applied from there onwards. The final new history looks like this: E-F-G feature The intermediate history looks like this now: E-F-G (saved in a temporary area)Īfter the reset, all the changes in the temporarily saved area (i.e “E”, “F”, & “G”), are applied in turn onto the master branch. Reset feature branch to current commit on master.Save all changes made by commits in the feature branch, but that are not in master, to a temporary area.Roll back to the common ancestor commit of the feature and the master branch (i.e “A”).When you rebase onto master via git rebase master, the process goes through the following steps: Let’s assume we have the following history with the feature branch checked out: E-F-G feature If you wish to understand the reasoning behind why the order was reversed, you need to first understand how rebasing works. Understanding the reverse conundrum in rebasing So, if you are on your feature branch, the command you need to run will be: git rebase master -XtheirsĪnd to keep master branch changes over yours, you need to do: git rebase master -Xours Interestingly, it works in reverse order if you want to do rebasing of your branch onto the master and want to keep your changes over the master. If you want to override the changes in the master branch with your feature branch, you can run the following command after checking out to master: git merge -Xtheirs featureĪnd to keep the master branch changes, you can use: git merge -Xours feature In those situations where you just want to override changes from one branch to another, you can use two merge strategy options: -Xtheirs and -Xours. Resolving conflicts using “Xours” and “Xtheirs” You can use git merge -abort command to abort the merge process when a merge conflict has already occurred. It handles the control back to you instead of overriding things on its own, which might not be desirable. And now git doesn’t know what changes to keep and what to discard. This is because the feature and testing branch both have modified the same file. The git merge feature will try to replay changes made on the feature branch since it diverged from master (i.e “A”) until its current commit (i.e “G”). You ran git checkout master followed by git merge feature. It’s time to merge your branch to master. feature), the master (pointer) can move forward - your colleague’s branch (testing) has been merged into the master already. While you are happily working on your branch (e.g. You can read more about this concept in official git docs and an article written by yours truly.
This is how Git knows which branch you are on. When you create a new branch off from master with git branch feature, a new pointer is created as shown in the figure below: featureĪnd when you switch branch with git checkout feature, Git moves the HEAD pointer, which was initially pointing to master, to your branch. Why do merge conflicts occur?Ī branch is just a lightweight, movable pointer to one of the commits you are on. If you already know git internals, you can skip straight to the command. In this article, I’ll first explain the reasoning behind the conflicts, and then I’ll show you a command which allows you to do the same in a few keystrokes. What if you just want to override your changes in master with another branch, or vice-versa? You can resolve all the conflicts manually by navigating to each file, and accepting all incoming changes to the master. In a few cases, it could cause merge conflicts where Git doesn’t know what to do and hands control back to you. Once your work is completed, you can merge your branch back into the master. Git branching allows developers to work in isolation. Settings Light theme Dark theme Strategies to resolve git conflicts using "theirs" and "ours"
0 kommentar(er)
