We have the following Git hierarchy structure in place, where each child is forked from the parent. If we build something in Client1 that will be useful in the entire hierarchy, what is the best way to push the changes up to the parents (whether just one level up or all the way to the root), given that we don't wish to push all the Client-specific customizations up the chain. Now, while the ideal solution might be to do the development at the highest required level, the modules can only really be tested down the chain where all the customizations are instantiated. E.g. If we develop a Module-New in Client1 repo, and need to push it to Core, what would the best way for that to be done given that we don't want Client1's customizations in the core? On the other hand, if we had originally developed ModuleA directly in CORE, we would have had to push the changes downstream all the way to Client1 to test Module-New (and iterate for every change).Are there any Git Workflows or any other tools that can help establish these rules. We currently use GitFlows to manage our master, develop and feature branches for all repos. Also, is there a way to disable direct pushes into a remote repository?                            CORE                              |                ------------------------            Product 1               Product 2                |                       |            ----------              ----------        Client1     Client2     Client3     Client4           |-v1.0              |-v1.1           ...
Fork Management of Git Multi-level Hierarchies
architecture;git;github;workflows;gitflow