How to structure your Git repo - Azure Tutorial

- Scaling Git for Enterprise DevOps How to Structure Your Git Repo So let's talk about structuring our Git repositories. There's two ways in which we can structure our Git repos. One is the monorepo model. And monorepo is just as it sounds. It's the single repo model, single repository, all your code artifacts. Everybody works out of a single repository. We also have what we call the multi repository, which as you can think of is multiple repositories. And there's a couple of benefits to working with each one of 'em. We'll talk about some of those. Mono repositories are like kind of putting all your eggs in one basket, but it causes less friction when it comes to working with the code base because everything exists in the single repository, whereas the multi repo might work better if you're in a microservices type organization where the application you're building is a microservices type application, you may want to break it up into multiple repos. The best thing is to determine is what's best for your team to start with. And you can change it later. If you start with a model, you can always break it into a multi or vice versa. You can take a multi and condense it down into a monorepo. So again, figure out what works for your team best to start with and just get started. Here's an example of structuring, Git repository and a monorepo model. You can see here, we have a couple different ways. The Dependency model versus the File Structure model. Most folks go with the File Structure type of model, but again, whatever works best for your team. So, why do we want to work with monorepo as well? They're better for developer testing. Developers can run the entire platform on their machines. So, with Git you bring down the entire platform, you run it on your machine. They get to understand all the different pieces and how they work together, which means it's easier for them to find the bugs on their machines locally. So again, the developers can be testing on their machines prior to it ever getting into a master branch or into a QA environment for testing. You reduce the code complexity. Your senior engineers can now enforce complexity rules and standardization rules for your code basis. So again, if you, all your services, you want to keep them against some kind of a standardization across the enterprise, you have the ability to do so and keep track of all those changes that are going in and out very easily across the repository. Again, because the code is all in there, it's not as complex to have to figure out what's going on because of the fact that everything lives in a single repo. You can do effective code reviews. Again, developers have a better understanding of the code base end-to-end, because again, from the testing portion of it, if they've brought the platform down to their machine, are used to working across the entire platform and testing across the platform, and so therefore they understand the platform and therefore can hopefully, the idea is offer better code reviews because they have better understandings of the platform. Easier components sharing. Again, you can see what's happening across all the projects within the repository. And so rather than having to share the components across multiple repositories, as some kind of a component like a DLL or a library from like, as your artifacts or something, you could actually just go ahead and use the code that's in the repo itself and not have to worry about pulling in from a third party. And then easy refactoring again it's if you want to rename something, you'd just run your grub commands and do some renames and Git, and everything should be done. It'll be restructured. And again, if you want to structure your project differently, like I said, you can go from a mono to a multi, a multi, to a mono, you can restructure within your monorepo. All that is easy to do with the mono repository. So what about a multi repository? Well, that gives us clear ownership. Again, if you're in a, some kind of a microservices type application development environment, clear ownership of each service may be important to you. And so therefore you'll break it up into multiple repos for each service, and therefore then assign ownership of each individual repository to its owner, and they can work down their portion of the service. It'll scale better because smaller code bases tend to scale better. And if you have a model repo everything exists in that single repository. Scaling the repo may be a little more difficult. Narrow clones, I bring this up because I wanted to show you why the benefit of a multi-repo small code base is to your benefit. Narrow clones is the idea that you could pull down a portion of the repository. You could basically just do a pull and not bring the whole repository. Unfortunately, you can't clone part of a repository, you clone a repo. And therefore, narrow clones is not something that's usually allowed in most source control systems and in Git, especially, it's not allowed. So why do we say that's a benefit here, is because in the multi-repo, because of the smaller code base, you're not bringing down such a large code base, narrow clones may not be common issue for you. In the monorepo, when you're bringing down a majority of the repository to your machine or all the repo to your machine, it's going to take more time. It's going to take more space, everything. So again, the multi-repo, if bringing down smaller portions of the repository are really important to you and having it broke up like this, the multi-repo may be your option for you. So, again, monorepo, multi repo, whichever is best for your organization, there's some benefits to both of those. And yeah, that should get you to where you need to go with setting up your initial Git repository.