0

We have a single repo for an app that has multiple modules/sub-apps (not git submodules), written by multiple people. Each is separated into subfolders:

/topFolderInGit
--/module1SubDir
--/module2SubDir
...

We have two branches under active development, one in production receiving hotfixes/updates, and another that contains some rewrite/more features, under the typical master and develop branching model.

Merges from master into develop consistently produce conflicts, across multiple modules that some people have never worked on. The ideal would be to allow merging for specific files/subdirectories by one person, so that another person can merge files they are familiar with at a later time.

splitting a merge in git seems close perhaps, but the answer is not specific enough.

Is it possible to selectively merge (or split a merge) so that people don't have to resolve conflicts in one bulk commit? That is, I want to leave the files that aren't merged in their pre-merge state, so someone else can take them later on, which would rule out this answer: https://stackoverflow.com/a/12473774/3879

Community
  • 1
  • 1
ray
  • 1,966
  • 4
  • 24
  • 39

1 Answers1

0

I don't think you can do this. It kind of goes against the way git works. Git tracks entire project snapshots, and merges are atomic things between those whole snapshots. You could undo things and make a new commit, but then you'd be telling future 3-way merges to continue to skip those things.

Why are you merging from master to develop, especially often enough to use the term "consistently?" If someone has never changed part of the code, why wouldn't that part of the code simply fast-forward in their repo? There shouldn't be the possibility of a conflict unless the old history is being overwritten.

If you're resolving literally the same conflicts over and over, read up on rerere.

Gary Fixler
  • 5,632
  • 2
  • 23
  • 39