Your questions is too broad/generic but I’ll try to give a shot anyways.
Most merge strategies in modern Version Control Systems, can’t deal with the following:
Suppose you have files A B C in commit 001 in a repository.
Developer Dev1 branch of commit 001 and changes one line in file A, commits as 001a.
Developer Dev2 branch of commit 001 and changes the same line in file A and commits as 001b.
If someone wants to merge commits 001a and 001b, the merge system wouldn’t be able to tell which is the correct change for the line, maybe the correct change for the project would be using the content in commit 001a or maybe the one in commit 001b, or maybe even mix of both changes in the line (that someone would have to create).
That’s usually how you get a conflict that need manual intervention, because two developers are working in the same file and line and wrote different changes.
In the rest of the cases the result is obvious:
- No changes in either commit? No changes in the merge result.
- Changes in either of the commits? The change is applied in the merge.
- Changes in the same file but different lines (for example, two devs working in different methods)? Both changes are applied in the merge.
solved file grained vs line grained version control systems