So I have two different project in the same repository one for the client side and the other for the server side (they don’t share any code).
When I branch from master and make changes on the client side project and then I want to merge back to master (after a month or so), I face a merge conflict with the server side code (other team member working on the server side).
Is it better to have two different repositories, where one holds the server and the other holds the client side code? Or should I keep it the way it is now?
If you intend to deploy new versions of the client and server software at the same time, then it makes sense to have them in the same repository. You said that the client side and the server side code don’t share any code, so there shouldn’t be any conflicts when merging. But you also said that you were having conflicts, so it sounds like developers on both branches are making changes to the server-side code. The best solutions would be a) tell the client-side developers not to change the server-side code, b) merge more often, and c) communicate between the teams when changes are being made that might be hard to merge.
If you are getting conflicts now, then splitting it into two repositories wouldn’t help you any… presumably your branch would still be making changes to the server code, but now you’d just have two repositories to merge instead of one. I would expect you to get the same conflicts if you tried to use this method instead of what you’re doing now, and there’d be more administrative overhead to maintain the two repositories.