What Should You Put in Source Control?
What Should You Put in Source Control?
Source control is crucial to development projects, but there's always temptation to put everything in there. Here are some guidelines to help you determine what goes in.
Join the DZone community and get the full member experience.
Join For FreeThe State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.
I am currently working on source code that is over 5 GB in size. This is mostly due to a poorly thought-out folder structure; there are code files, images, and Excel files all jumbled together. I think a clear distinction should be made between source code and data.
Source Code
I will define source code as anything that is written in order to compile and run the project. If it is a webpage, it will be all the HTML, CSS, and Javascript or any file used to produce these. I would also include any configuration files and files used to build or deploy the website or project. Anything that is compiled from your source files can safely be ignored.
Data
I would define data as anything that is added to the project during its life. So, if you have an upload option, anything that is uploaded would be described as data. The site should still function without (or with very little) data.
Images
Images can fit into both groups. Any icons or images attached to the functionality of the project should be classed as source code. However, anything that is uploaded should be classed as data.
Database
The database should also be classed as both. The data, anything that is inside a database table, should normally be classed as data. Stored procedures, functions, and views are all source code and would benefit from version control.
Source Control != Backup
Source control is not an excuse not to backup things. Don’t just commit files to source control so you know you can restore them if you need to. In general, files in source control are there so that you can see how they changed over time as the code base changed. Files in you backup are a snapshot of what the application was at a point in time and will include ALL the data.
One last point before I end: If you are hosting on a cloud computing platform like Azure, it gives you an easy way to distinguish between data and code.
Anything in your web app is code.
Anything in blob storage is data.
Anything having to do with SQL is data and code.
Each project is unique and there will always be exceptions to these suggestions, but I think this is a good goal to have. What do you think?
Your API is not enough. Learn why (and how) leading SaaS providers are turning their products into platforms with API integration in the ebook, Build Platforms, Not Products from Cloud Elements.
Like This Article? Read More From DZone
Published at DZone with permission of Simon Foster , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}