A git parent-child architecture

Here is how it all started. Back at the office, we were making software that will cater to many clients. But soon after its release, we realized clients had custom requirements. I am sure most of us will have, at some point in life, faced this dilemma.

We started with git branches to solve our problem. The master branch had the common code and each client branch had the custom code the client requested for. A custom code could vary from a simple text/color change on a page to an entirely new page for them.

Everything was fine. But that is when it struck us. How do we merge branches now? Let’s say we roll out a new feature that all the clients are asking for. We were not able to merge our master into the client branches because we would run into conflicts now. We needed something that would allow us to merge the common code into all client branches as well as add custom code in the branches.

We initially tried out the git submodules thing. Although it did work, it seemed kind of complicated because we had to create and maintain separate repositories for each client now.

That is when we came across .gitattributes and merge drivers in git. Before I annoy you with the commands, what it basically does is allow us to ignore certain files during a merge. This allowed us to preserve files in client branches during a merge from the master.

Here is what we did,

1. Run this in the git repository

git config --global merge.ours.driver true

2. Make a file called .gitattributes in the root

3. Add all the files to be preserved across branches into that file

<filename> merge=ours
<foldername/*> merge=ours

4. Commit the file onto our branches.

With this done, we could make changes to the files and folders in our master/client branches and merge to and fro without having conflicts.

Although this seems like a temporary solution to our problem, we are still looking out for better solutions if you have any. Please let us know in the comments.

Happy programming!