One person controls only one folder, in a repository

Question

How can I give complete control of one folder to one person, while the rest is in the control of another person. Control means they have the power to approve pull requests and commit to master and development.

I think the answer is git subtree or git submodule but I'm not sure which or if there's something better. I'm concerned that it will be impractical with all the feature branches where both will be being actively changed.

Rationale: We have a complicated logic system. The way we verify that it's working after we add new features, is that we have two completely different implementations in different languages and we make sure they produce the same outputs from the same inputs. Two people are intended to be in charge of either implementation respectively. One implementation is production and one is not and is contained within one folder in the top level directory in the git repository. We found out someone had changed both in the same way erroneously and it snuck through when we were under time pressure.

Answer 1

Git submodule might be a solution, but this really turns your repository into multiple unrelated repositories, where a top-level repository includes the submodules at a specific commit. To change code in a submodule, you first need to commit the code changes in the submodule repository and then commit the submodule's version change in the top-level repo. This might be rather cumbersome, and will require changes to your tooling. And this can't prevent the problems you encountered unless individual contributors only have write access to one implementation's submodule.

An alternative would be to enforce a pull request based workflow, where changes in some folders need approval from specific people. Many review tools (incl. GitHub and others) support a CODEOWNERS file to describe a folder → responsible user mapping.

If you have a CI system, you could also add checks that a commit or branch does not span multiple special directories. Checking the output of git diff --name-status master..HEAD might work.

In your question, the incident you described had two causes: (1) There were no access controls, allowing arbitrary changes, and (2) people were to busy to care about your normal processes. Any technical solution can only help with (1) and by calling more attention to other's peoples changes, but they are at risk of being disabled or circumvented under “time pressure”. Consider also how you can address this social problem to foster a safe and relaxed working environment where there's enough time to follow your agreed-upon procedures.