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 FreeWSO2 is the only open source vendor to be named a leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report. Download the report now or try out our product for free.
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?
Read the WSO2 Methodology for Agility to see how you can transform your integration projects from semi-agile to a scalable continuous agile approach.
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 }}