Version Control Systems

Version Control Systems

General 

All the rules should be enforced and overlooked horizontally by the entire team. If a new person 
joins the team, then he/she should be introduced to the processes. The person responsible for 
the process should overlook compliance with the rules.

Company GitHub 

Each commit must be reviewed by the person responsible for the repository;
Each commit must have a good level of documentation;

Rules: 

Repository Convention: 
● The repository must be created by the company Software Manager 
● The repository name should clearly show what this project is for. Suggested repository 
name:
 Example: project_name-backend, project_name-frontend, project_name-
android, project_name-ios,project_name-frontend. 

● Topics - the name of technology 

- Project_name - must be named according to the contract signed 
 
● Each repository should have a .gitignore file that contains all files which 
can't be committed to the remote repository. This is obligatory. 
- All publish config files that contain settings and credentials to the server 
- All config files (appsettings.json, webconfig.json, etc.) that contain the DB 
credentials, email providers, SMS providers, AWS keys, secret keys general, etc. 
(all possible credentials to all possible providers) 
- Or secret manager on the server side should be included in the project 
● All applications should be containerizing by DevOps only 

Pushing project: 

● The project has to be shared from the company 's account only. 
● Before sharing the project, a person that is willing to share has to communicate with the 
user that is responsible for this process. (Only for TechLead and roles that have 
permissions to invite other people to the project. If you don’t have permission and need 
to add another member to the repository, you have to contact your TechLead or Software 
Manager) 
 

Commit Rules: 

● A commit should be a wrapper for related changes. For example, fixing two different 
bugs should produce two separate commits. 
● You should only commit code when a particular task/bug is completed. This doesn‘t 
mean you have to complete a whole, large feature before committing. Features should be 
split into logical chunks and respective tasks/subtasks. 
● In all commits must be included the “Jira key” (unique JIRA identifier of the task/bug - 
i.e.RAR-1, FACT-133, etc.)  at the beginning of the comment 
● Commit immediately when the task is completed - don’t’ wait till the end of the day. 
The number of commits per day should be equal to the number of tasks/bugs you have 
finished that day. 
● Resist the temptation to commit something that you «think» is completed. Test it 
thoroughly to make sure it really is completed and has no side effects.  
● Begin your message with a short summary of your changes (up to 50 characters as a 
guideline). Separate it from the following body by including a blank line. The body of your 
message should consist of detailed answers to the following questions: – What provoked the change? How does it differ from the previous implementation? 
Example:  
Add reports functionality 
 
Added functionality to fetch data from the device and build sensor readings reports 
  
● Use the imperative, present tense («change», not «changed» or «changes») to be 
consistent with generated messages from commands like git merge.  
 

Branching Rules: 

 
● There are two primary branches: Main and Develop. Also, there are usually Feature 
branches that contain work on the current feature. And Staging branches that contain all 
the features for release.  
- The main branch always reflects the most current production-ready state of the software;
- Develop branch reflects the latest development for the next release; 
- Feature branches are created from Develop branch and merge back 
into Develop branch, when the feature is ready;
- Staging branches are created when you decide which new features will 
be included in the release to prod. At that point in the Develop branch, you start a 
Staging branch. If you find some bugs in the Staging branch, it’s okay to fix these 
issues right in the Staging branch. No need to create another branch;
When the Staging is ready - you merge it to Master and tag it with version 
number(example - v1.2). All the work you merged into Develop, before 
the staging branch is available in production as a part of the newest release. You 
can safely merge any bug fixes from the Staging branch back to Develop, and 
then delete the Staging branch. 
 

README: 

● All the repositories must include a readme file (README.md) 
● The header title must include project name and descriptions - i.e Project_name - back-
end 
● Make project description short and closer to the point - Example: <project_name> is a 
<utility/tool/feature> that allows <insert_target_audience> to do <action/task_it_does> 
● Make your prerequisites clear;

the prerequisites consist of 3 categories: 

- Operating system (if platform-specific) 
- Framework infrastructure 
- Knowledge (if project usage requires any specific knowledge for the user) 

● Include a description on how to install with commands (if there is a need for it);
● Provide pre-build/build/after-build commands and ports that are open;
● Describe environment variables that are required; 
● List system-wide packages that are required (ImageMagick, cURL, etc);
● Demonstrate usage with examples or descriptions of project features usage; 
● Contributing - write a clear guideline on how to contribute to the project (if there is a need 
for that);
● Contributors - company account. (if there is a need for that);
● License 
● If there are any additional or specific pieces (like changelog, versions, building, etc.) that 
needs to be included, please contact TechLead or ProjectManager.  

    • Related Articles

    • Code of Ethics and rules of conduct

      Group 107 Ltd (the "Company") Code of ethics and rules of conduct General: The company advocates for an adequate organizational culture of its managers, employees, contractors, its various organs and its officers ("the employees" and/or "employees of ...

    • Procedure for handling complaints about deficiencies

      Group 107 Ltd Procedure for handling complaints about deficiencies 1. Introduction 1.1. Group 107 Ltd. and its subsidiaries (as it will be from time to time) (the "Company"), is committed to conducting its business activities at the highest level of ...