Editing 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.