My project is a monorepo where the top level directory contains build infrastructure and a set of project directories for different services. Each service has its own branch of development. The branches have rc and release tags: service1-14.0-rc1 for the first service and so on.

The issue is the build infrastructure that is shared between the products. I do not know if shared work should be done on the master branch and then merged into all the product branches, and the branches should be merged back into master occasionally, and at what cadence, etc. What is a good git methodology for this setup where the product branches will exist forever? Should tags be used for master at all?



In a comment you wrote

“Each branch changes a few lines in a Makefile”

I think there is your problem. Create one makefile which allows to build each product/platform individually, maybe by calling “make platform1”, “make platform2” etc. Proceed the same way with other shared components – make sure they don’t differ between platforms, but provide a compile time or runtime mechanics to adapt themselves to the specific platform where they are used for.

Now you can merge everything back into master without abusing branches for different products / platforms, which should make your issues vanish.



You can’t just put everything in one git repo and call it a “monorepo”

If you don’t have any cross over between the products sub directories then make them separate repos and save yourself this pain.

If you do have shared code then you need to be releasing from master and merging back. Which, if you are doing a monorepo probably means you need custom merging procedures to detect conflicts and reject based on whether you can build and deploy with no test failures.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *