The hard part of merging is figuring out what the new code is ment to done, in the following code, without any previous knowledge, it is hard to see what's supposed to happen without actually testing different variations of the code
Use a different merge style to clearly show the parent before you merge
git config --global merge.conflictstyle diff3
Putting your changes in a box, so you can review other peoples boxes
Use when
Don't use when
The art of splitting changes, so it looks better in the history
As you can see, splitting changes in different files is easy, because of this, our sass structure has protected us from most conflicts
Use `git add -p`
y - Yes, add this hunk
n - No, don’t add this hunk
d - No, don’t add this hunk and all other remaining hunks.
s - Split the hunk into smaller hunks.
Confirming when and what broke the project
Used for an overview of the branch structure
See also: