Adopting Gitflow for Scalable Development: Migrating from SVN to Gitlab

Background : The team originally used SVN for source control, but rapid growth (10‑20 developers and multiple parallel versions) made merges before releases cumbersome, prompting a switch to Git.

Business Layer Separation : Initially isolated business modules by physical directories, but fast‑moving requirements caused cross‑module changes and conflicts.

Gitflow Adoption : Chose the Gitflow工作流 to assign clear roles to branches (master, develop, feature, release, hotfix) and streamline releases. The workflow adds structure without new commands.

Tooling : Used SourceTree (which includes built‑in Gitflow support) to lower learning overhead. Created branches via the Gitflow button, e.g., feature , release1.2, hotfix1.1.1, with automatic merges and tagging.

Gitlab Integration : Migrated repository hosting to the company's Gitlab instance, configuring project and user permissions (guest, reporter, developer, master) and wiki access accordingly.

Migration Process : Shared Gitflow concepts with teammates, froze SVN, and moved all code to Git. Conducted internal presentations to align business lines on the new workflow.

Issues Encountered and Solutions :

Permission problems : Restricted master rights and protected important branches.

Merge conflicts : Regularly merged develop into feature branches to surface conflicts early.

Push/merge workflow : Protected the develop branch and disallowed direct pushes.

Dependency coordination : Created a shared feature for common interfaces before dependent features.

Packaging challenges : Added multiple Jenkins jobs to handle numerous feature branches.

SVN resource handling : Moved remaining assets into Git or fetched them via command line before packaging.

The migration completed successfully, establishing a more maintainable and scalable development process.