Talk:06 Version Control and Source Code Management

1. Purpose

This procedure defines the processes for version control and source code management to ensure the integrity, availability, and confidentiality of source code and related artifacts.

2. Scope

This procedure applies to all source code, configuration files, build scripts, and documentation related to software products developed, maintained, or managed by Hein+Fricke.

3. Responsibilities

• Development Team: Responsible for following version control practices.
• IT Team: Responsible for access control and repository backups.
• Project Managers: Ensure adherence to this procedure within projects.

4. Definitions

• VCS (Version Control System): A system that records changes to files (e.g., Git).
• Repository: A storage location for software source code.
• Branch: An independent line of development within the repository.
• Commit: A recorded change in the version history.
• Pull Request/Merge Request: A mechanism for integrating code changes.

5. Procedure

5.1 Repository Management

• All code must be stored in an approved version control system (e.g., GitHub, Gitea).
• Gitea is the internal git repository system for H+F.
• Repositories must be registered and approved by the IT team.

5.2 Access Control

• Access to repositories is role-based and must be authorized by the relevant project manager.
• Use of personal accounts is prohibited. Only company-assigned credentials are allowed.
• Access must be revoked immediately upon employee termination or role change.

5.3 Branching Strategy

A standard branching strategy must be followed, e.g.:

• main or master or production: Production-ready code.
• develop: Active development.
• feature/*: Feature-specific branches.
• bugfix/*: Bugfix branches.
• release/*: Release preparation.
• hotfix/*: Critical bug fixes.

5.4 Commit Guidelines

• Commit messages must be meaningful and refer issue/task numbers where applicable.
• Code must not contain hard coded secrets, passwords, or sensitive data.
• All commits must be traceable to an individual user.

5.5 Code Review & Merge

• All merges to main or develop branches must go through a pull/merge request with at least one peer review.
• Code reviewers must verify security and compliance aspects.

5.6 Tagging & Release Management

• Releases must be tagged with delivery id (e.g., DID-NNNN).
• Release notes must accompany each version and stored in the delivery record.
• Code released to production must be signed off by QA and the project manager.

5.7 Backup & Retention

• All repositories must be backed up daily and stored securely.
• Backups must be tested at least quarterly.

5.8 Incident Response for Code Breach

• Any unauthorized access or code tampering must be reported as a security incident.
• The standard incident response procedure must be followed immediately.
• A post-incident review must be conducted, and corrective actions documented.​

6. Compliance & Audit

• Periodic internal audits shall verify compliance with this procedure.
• Non-conformities will result in corrective actions and may lead to disciplinary action.