1

I have branches like /QA, /developer and individual branches for each developer.

Any time if I do any changes in developer branch I commit it to my individual branch and merge it developer now if any other developer have to commit any changes he will pull the changes into his branch from developer and merge it to his own branch if conflicts occur's he will solve it and commit his branch and merge it to developer.

Is there any possibility of losing changes if I follow the process explained as above?

To generalize

Can changes be lost if we merge new changes(individual branch) to old (developer branch) or if we merge the old branch with newly changed branch?

smali
  • 4,687
  • 7
  • 38
  • 60
  • It's always possible for the conflict to be solved incorrectly by the developer. Is that what you meant? – Frederick Cheung Jun 10 '16 at 07:00
  • No actually I'm not considering conflict one of my senior team member said don't merge /QA branch to developer instead merge your branch to QA otherwise you will loose changes, but I'm sure that it will not work in that way so just asked to confirmed. – smali Jun 10 '16 at 07:04
  • Merging itself will not loose changes, incorrect merging will. – neevek Jun 10 '16 at 10:50
  • I have seen one case where merging the wrong way "lost data". This was due to bad decisions and planning and use of DVCS and all that, but it was still something that had to be remembered to avoid tripping. The owners of the repo was adamant this was the right way though. Basically they had dev and prod branches. Originally they had only prod branch. To create the dev branch they had branched from prod and then obliterated all prod configuration. From there on you had to graft all changes, and not merge, or you obliterated prod configuration as well. I would talk with your senior developer. – Lasse V. Karlsen Jun 10 '16 at 12:50
  • What your senior developer said makes total sense in as much as you should not be making changes to QA branch ever. That's the downstream recipient of code from your dev branches. You don't want new development happening in a test environment. Whatever changes you do happen to make in QA are suspect to incompatibilities with code developed on dev branch in the meantime. – Jeff Puckett Jun 10 '16 at 22:29

1 Answers1

2

When git is merging and it sees two changes occur in the same place (which means it has to keep one and lose the other). It flags a conflict so the developer decide what to do. The developer, of course, can decide not to keep a change and complete the merge.

Git merge works by discovering the changes for each commit in the 'other' branch and applying them to the 'head' branch, the only reason that it could not apply the change is if it can't find the place to make the change and thus there is a conflict.

Gregg
  • 2,444
  • 1
  • 12
  • 21
  • yes, you are correct but I'm not asking about losing changes is in case of conflict. – smali Jun 11 '16 at 06:36
  • #ail786 On further consideration, if the patch location is discovered via Regular expression, and there are two matches in the destination code, and Git does not check for this, there's a possibility that the patch would be misapplied. – Gregg Jun 13 '16 at 18:52
  • @spazm see this discussion http://stackoverflow.com/questions/38077262/git-rebase-implementation-details. Rebase and merges are implemented similarly, by 'playing' patches from one set of commits on to another. – Gregg Jun 28 '16 at 21:24