When you check in code, and have a conflict, the merge tool from Visual Studio is presented.Īll fine. You can choose 2 local files, a source control file and a local file, 2 source controlled files etc. When comparing two files from Source Control Explorer or the Solution Explorer you get this nice tool that shows a nice visual compare of two files. Also, I usually toggle the ancestor pane so that I can see what the original version (before the conflicting edits) looked like.Probably you are familiar with the Diff tool that Visual Studio provides when doing Source Control. For my part, I prefer using the “pre-merged ‘ours’ version” because it automatically takes care of merging the non-conflicting lines, and lets you focus on the conflicts without having to manually remove conflict markers. In case that you change your mind later on, you can adjust this setting in the “Diff/Merge” preferences:Ĭhoosing between these three merge modes is largely a matter of personal taste. If you select the check box “Don’t ask again”, Eclipse will (as you might have guessed) stop asking you for the merge mode, and always use the option that you have chosen last. in the left half: the merged non-conflicting lines, and the lines from the master branch (“ours”) for conflicting edits.“Use the git pre-merged ‘ours’ version of conflicting files” Violet: Changes only in the feature branch (which have not been merged in this mode).In addition to the previously mentioned colors, this mode adds another one: in the left half: the file’s contents from the master branch (i.e., the local version before the merge operation).“Use HEAD (the last local version) of conflicting files” None: No changes, or changes only in the feature branch (which have already been merged in this mode).Red: Changes in both branches (conflict).Grey: Changes only in the master branch.The highlight colors for the lines have the following meaning: Note that you can toggle the display of the common ancestor (the original file version before the changes in master and feature) by clicking on the “Show Ancestor Pane” button in any of the three merge modes: The description “pre-merged by Git” refers to both the Git conflict markers, and the fact that the changes in the non-conflicting lines have already been merged in the working tree version. in the right half: the file’s contents from the feature branch (as always).in the left half: the file as it is in the working tree (i.e., in your file system, with Git conflict markers).“Use the working tree version of conflicting files (pre-merged by Git)” The right half of the compare editor always shows the file’s contents from the feature branch. Or by selecting “Merge Tool” from the file’s context menu in the Project Explorer:Īn important aspect to understanding the three merge modes is that their descriptions refer to what will be displayed in the left half of the resulting compare editor. The merge tool can either be started by double-clicking the conflicting file in the “Git Staging” view Now let’s inspect what the three different merge modes will show us for this simple scenario. Note that the non-conflicting edits (lines 2 and 4) have already been merged in this file. As expected, the text file contains the usual Git conflict markers after the merge: In the master branch, the following edits are performed:Īnd here are the edits from the feature branch:Īs you can see, whereas lines 2 and 4 have been edited in just one of the branches, line 6 was changed in both of them, leading to a conflict when performing a merge:Ī Linux shell script that automates this process is given at the end of this post. This file will be edited in the master and feature branch as indicated by its original lines.
0 Comments
Leave a Reply. |