Does Git override entire file when you merge, or cherrypick, or just the parts changed?

Question

This question applies to any situation in which one is using Git with other team mates. Lets say we both are changing the same file, but not in such a way to cause a conflict.

Lets say I have the code:

#define client_view 500
#define server_view 1000
#define client_destroy 750
#define server_destroy 1250

I'm asked to change client_view and related, my colleague is asked to change server_view.

I change it client_view to 570, e.g. I think in this hypothetical scenario 570 is a good value. Likewise, my colleague chooses 1066 for server_view.

When we both pull request, and the manager merges these to master,

What will it display?

#define client_view 570
#define server_view 1000
#define client_destroy 750
#define server_destroy 1250

or

#define client_view 500
#define server_view 1066
#define client_destroy 750
#define server_destroy 1250

or

#define client_view 570
#define server_view 1066
#define client_destroy 750
#define server_destroy 1250

I ask this because I want to know if my changes will overwrite my colleagues changes. I have never sent a pull request on the same file someone else has worked on, so I don't know the answer, and couldn't find one on SO or other.

Answer 1

Git is doing something called a "3 way merge". This means, there will be three commits involved:

• A: your commit
• B: their commit
• C: the common ancestor of A and B

The 3-way-merge now (basically) finds all changes between C-A and C-B. If a particular set of lines was only changed by either A or B, it applies them. If any lines were changed in both A and B (with respect to C), then it is flagged as a conflict, and you are required to pick a resolution manually.

The algorithm used in Git is generally very, very good at giving you what you would intuitively expect. So in your case, both of your changes would simply be applied (because they are not in conflict with each other). So you get your third result.

Incidently, a thing that often confuses people, is that Git does not care a bit about whatever happens inbetween C...A or C...B. For example, you can delete and restore a file in between, and it will not influence the merge operation at all.

Also, it will not somehow go through all the intermediate commits, it will only look at exactly these three commits. This is very useful to now, since in extreme cases of merge conflicts (for example, if one of your colleagues changed the indentation of all lines, rendering the whole file a big conflict), you can somehow help yourself by changing A or B on their own (in this example, undo their indentation, or apply the same indentation to your files), commit that change, and then try to merge again, hopefully getting a lesser conflict.