Oh boy, how time has changed!

With a little bit of luck, we were right. Today git is a de facto tool for version control, and most important, a central piece in most of DevOps CI/CD infrastructure. However, we made some bad choices regarding storage format. Initially, git was just an internal implementation detail, to simplify and cut some corners, we ended up storing multiple projects in a single repository.

Git became popular, and our community and users asked us not to hide it anymore. And this is where our initial decision of sharing multiple projects in a single repository became a problem.

In our git backed storage, every file change translates to a commit, however with multiple users interacting in a project, you end up with several commits from several different people doing different modifications. So, at the end of the day, the git history isn’t much useful.

There’s also the fact that multiple projects in the same repository may have different life cycles, making almost impossible to provide a reasonable maintenance branch structure.

So in v7, we were able to revisit it, and now Business Central has a one-to-one relationship between project and repository, which enables a real-world maintenance branching strategy. As a positive side effect of this change, we managed to streamline the project creation, and the getting started experience, completely hiding git repository information for less technical users.

In v6 we used to provide what we called Organization Unit, but it was just a logical organization, a decision that we revisited in v7.

Spaces replaced Organization Units, and now Space is a real object and provides an organizational structure that represents a tenant, and projects are created under (and isolated) by it.

As already mentioned, a git repository backs every project in business central. To have direct access to it, go to the project settings tab, and you’ll be able to see it in the first section:

Direct access to git is available via two protocols: git and ssh. The git protocol is available for convenient read-only access, and SSH for read-write. The direct access to git allows users to clone a project from Business Central, make changes locally using their preferred tool, and push changes back to Business Central.

Projects are the most obvious information that is stored in git. But Business Central uses git to store all sorts of data, including configurations and internal data. Here’s the list of the “system” repositories and its content (all of them are under system space):

Git is not only popular but also a powerful version control tool and a good portion of the success of Business Central relied on the fact it uses git. In this post you and got some of the historical contexts of Business Central adoption of it and learned how Business Central uses it and exposes it. If you’re interested in understanding what’s under the hood, keep an eye in this series of posts about Business Central and git.