1

Trying to figure out how the file1.cpp will look after merging merge request in Gitlab . I(dev1) am working on the dev branch and changed line 2 of file1.cpp, committed and raised merge request . Now, I waited 1 day before merging . By the time another developer(dev2) changed the line 4 of file1.cpp, committed and merged in master . Now, the line 4 is different in my file1.cpp, if compared to file1.cpp from master .So if I merge now my request then how the final version of file1.cpp will look like ?

1) file1.cpp:  
line 2 by dev1 
... 
line 4 by dev2

2) file1.cpp: 
line 2 by dev1
...
line 4 by dev1

My doubt is whether line 4 from my will change will be present in final file or line 4 from dev2 will be finally present . If line 4 from dev2 will be finally present , then why it is so ? Because my changes are coming after dev2's changes .

Prashant Singh
  • 426
  • 7
  • 17
  • 1
    The date of the change is irrelevant here, it'll generate a conflict and *you* will determine which version should be kept, not git. – Romain Valeri Jun 09 '20 at 08:04

1 Answers1

2

git will not silently discard your colleague's changes, nor your own changes.

It will either :

  • find a way to combine both your changes,
  • or trigger a so called merge conflict, and ask someone to take manual action to determine what should be the end result.

If a merge conlict occurs, a generic manual action is :

  • fetch all changes on your machine,
  • rebase your work on top of the updated master branch,
  • fix the merge conflicts locally,
  • push your updated branch.

Note that "the changes are automatically merged by git" is not a guarantee that your code will work.

Two examples :

Suppose your change is : renaming function computeThis to computeThat,
and dev2's change is : call function computeThis,
your combined changes would lead to something that doesn't compile.

Suppose your change is : add a x -= 1 instruction,
and dev2's change is : add a double d = 1 / x,
and for some reason, before your change the code explicitly stated that x > 0 in that function,
the result would compile, but there could be a new bug case when x == 1.

Just to highlight :

the end result should still be tested and reviewed.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • But I am thinking like , what I would if I have to create a system for merging two commits . As per me, option 1 looks proper where dev2 changes are reflected for line 4 . Because if we track the history of changes for line 4 , then in final version i will write that "line 4 was most recently changed by dev2" and "line 2 was most recently changed by dev 1" . The point here is that line 2 I changed explicitly but line4 in my file1.cpp is not changed by me but it is different from file1.cpp from master . I think there is a subtle difference on how we or git sees the changes . – Prashant Singh Jun 09 '20 at 09:03
  • I'm not sure I get your point. `git` only looks at : the content of a file within a specific commit. If you ask `git` to merge two specific commits, it will do so, and build a new commit with new files. The choice of the commits to merge and the correctness of the end result are things to be evaluated by you. – LeGEC Jun 10 '20 at 11:39