0

Maybe this is a stupid question. But. When I started using Git I was told that when working on a feature branch, before merging to master I had to merge everything from master to my branch. Now, that I can understand from a testing point of view. To be able to know that everything is working correctly with my code before merging it to master I should first test in my branch, hence I have to merge from master to my branch. In my current project we have another workflow. I have a feature branch, and then master acts as a staging branch, and then we have another production branch. Nice workflow btw.

But this have forced me start thinking on how branching and merging actually works in git. If developer D1 creates a branch A, and developer D2 later creates a branch B. Developer D1 does some work and merge branch A to master. Now D2 merges his branch B to master. Will only the actually changed files by D2 be merged to master, or will git try to merge every file that existed when D2 created his branch even those not changed? Should D2 before attempting his merge, have merged from master to branch B, or doesn't it matter?

My guess is that git only merge changed files, but I am not 100% sure :)

Andreas Selenwall
  • 5,705
  • 11
  • 45
  • 58

2 Answers2

1

A merge combines the changes of two development lines. So unless you tell Git otherwise it does not overwrite master with B, but it will combine the changes that were done on master and B and as master has A merged into already, those changes are on master.

Vampire
  • 35,631
  • 4
  • 76
  • 102
1

A merge operation in git always acts upon the whole repository, there is no file-based merge.

That said, it is a per-file 3-way merge (as usual). That means, if merging your feature branch A into master:

  • git will find the youngest common commit between A and master; let's call it oldmaster.
  • git will find the differences between oldmaster and A and try to apply those differences (patch) to the current master; file by file. If there are no differences for a certain file, it will of course do nothing for that file.
  • At the end, you get one (merge) commit; all the patches for all the different files will be committed as one; this commit will have both A and master as parents.

To answer your questions specifically:

Will only the actually changed files by D2 be merged to master,

Yes.

or will git try to merge every file that existed when D2 created his branch even those not changed?

Yes, too. git will "try" them, but find that there are no changes, so it's a no-op.

Should D2 before attempting his merge, have merged from master to branch B, or doesn't it matter?

It depends on your workflow (what do you actually do with master), but generally no, there is no technical reason to do it "per default". git is not svn, it can do any kind of merge; there is not (as in the "old days" some limitation like in svn where you had all that "reintegrate" stuff complicating merges).

My guess is that git only merge changed files, but I am not 100% sure :)

That's what "merge" means. Merge does not mean to copy all stuff from A to B, but to look what changed in between, in respect to a common parent C.

AnoE
  • 8,048
  • 1
  • 21
  • 36