Is it ok to store two different kinds of code in the same git repository?

Question

I am starting a new project and trying to decide how to organize the code in Bitbucket. I work at a startup where all of us have technical experience, but none of us have worked at software development companies. We have been arguing about the best way to organize our code in our bitbucket repository/ies.

We have some PHP code for the front end of our website, and some Matlab for the backend (the Matlab is being complied to work with the PHP, but I don't think that is relevant). The PHP code is used exclusively for the website, but the Matlab is worked on by many developers making changes, some relevant to the website and some not.

We have come up with three schemes for how to organize the code:

Scheme 1: Put the Matlab and PHP in the same repository. Branch the Matlab into "Website" (a.k.a. stable main branch), "Develop1", "Develop2", etc. The developers work on their own branch, and periodically we merge the Develop branches into the Website branch.

Scheme 2: Put the Matlab and PHP in the same repository. Developers who want to work on the Matlab fork the Matlab into other repositories, then submit pull requests when they want their code merged with the website Matlab code.

Scheme 3: Put the PHP in one repository and the Matlab in another. Then the developers fork or branch as described above.

What are your thoughts? The DBA in our company says that it is a terrible idea to put two types of code in the same repository (and at some point, it would be three, since we will be slowing changing the Matlab code over to C or some other language). On the other hand, I worry that it will be hard to keep track of which versions worked with each other for the PHP and Matlab if they are in separate repositories.

I read a number of posts on stack overflow that partially answered my questions:

This helped me understand the difference between branches and forks - it would appear to me that branches simply require more trust in the developers, since they can merge without permission or code review.

git branch, fork, fetch, merge, rebase and clone, what are the differences?

This seems very close to my question, although when I showed it to the DBA, he said it isn't a good example since Java and Javascript are so similar. However, the answer written here seems to point to my Scheme 1.

How to organize shared code/assets across projects with git repositories

This also helped me understand branches and git in general better.

http://tom.preston-werner.com/2009/05/19/the-git-parable.html

This answer also seems to suggest that even code that that doesn't share any files should be in the same repository if it is part of the same project.

Should I separate client and server side of my project into two Git repositories, or keep them in one?

Answer 1

Use only one repository. There's absolutely no reason to make two repositories just because of the languages. Most projects use more than one language anyway (for example a web application would have some server part, say Java or Go, some HTML, CSS and JavaScript files, a few shell scripts, some SQL scripts, a few utilities used around, etc.). Use two repositories only if you can use one without the other one in some way and you specified a clean interface between them (in that case, it might be useful to make two repositories, but that's obviously not your case). Your concern is right : keeping separate repositories synchronized is a nightmare.

And branches aren't, at all, used to separate languages. They're used to let you have different versions of your whole code (developing a new feature, storing a released version so that you can come back to it for a fix, having a dedicated better tested branch for production, etc.).

Note also that you can have clones of the repository (remember : git is distributed), you may even decide that there's one repository on which only a few maintainers have write access and they fetch from other repositories. But at that point, with your experience, you might want to use a solution built over git rather than pure basic git, be it commercial (look for Atlassian, GitHub, etc.) or free (gitolite for example).