Merge conflicts#
Note
This page was not shared with MUDE students in 2023-2024 (year 2).
It may have been a new page, or a modified page from year 1.
There may be pages in year 1 and year 2 that are nearly identical, or have significant modifications. Modifications usually were to reformat the notebooks to fit in a jupyter book framework better.
Merge conflicts arise when people on separate branches modify the same
parts of one (or multiple) files. Since git does not know how to handle
that and whose changes to consider, it prompts the user to decide
instead (mconflict1
).
Let us create a merge conflict ourselves:
We will start by making a new branch change-date-format
. We will
checkout to it, modify the date format and make a commit as show in
figure mconflict2
.
Next, we will return to main
branch. We will edit the same line of the
README.md and then checkout back to change-date-format
branch (mconflict3
).
In figure mconflict3
there is also a graph visualization.
Finally, we will merge main
into change-date-format
and get a merge
conflict as seen in figure mconflict5
}, because we modify the same parts of the file.
The changes on the current branch are preceded by <<<<<<< HEAD,
while the changes from main
branch are preceded by ======= and
followed by >>>>>>>main. In order to fix this conflict, we need
to open the file README.md with some texteditor app and fix the conflict
ourselves. That is, edit out the things we do not need: open a text
editor and remove the parts of the file we do not need. When done, we
just need to make a new commit. Note that the current branch is now in
stage “MERGING”. We have decided to take the best out of the 2 branches
and merge their changes.
Thus, we have succeeded in dealing with a merge conflict! The graph in
figure mconflict6
displays how the 2 branches have now been merged.