Skip to main content

Version Control Workflow

Flux CRM uses Bitbucket for version control, ensuring a collaborative and organized development process. The system follows a branching strategy that supports multiple developers working simultaneously while keeping the codebase stable and scalable.

Branching Strategy​

The project follows a Gitflow-inspired branching model, which includes the following key branches:

  • master (or main): This branch always contains the latest stable version of the application. Only tested and reviewed code is merged into this branch, and it is used for production releases.

  • develop: This is the main working branch where ongoing development happens. Features, bug fixes, and improvements are first merged into develop. Once stable, it is merged into master.

  • Feature Branches: New features or enhancements are developed in separate feature branches. These branches are typically named using a convention like feature/feature-name and are branched off from develop.

    Example:

git checkout -b feature/add-user-role-management develop

  • Bugfix Branches: When bugs are identified, they are fixed in dedicated bugfix branches. These branches are named bugfix/bug-description and are also branched off from develop.

  • Hotfix Branches: Hotfixes are urgent fixes for critical issues in the production environment. These branches are created off master and merged back into both master and develop to keep the branches in sync.

    Example:

git checkout -b hotfix/fix-critical-bug master

Workflow​

  1. Cloning the Repository
    Developers clone the repository from Bitbucket to their local environment for development:
git clone https://[email protected]/elizza-fine-jewellery/flux-crm.git flux-crm
cd flux-crm
  1. Creating a Branch
    When starting a new task (feature, bug fix, or hotfix), a new branch is created from either develop (for features and bug fixes) or master (for hotfixes). This ensures isolation of work and keeps the main branches clean.
git checkout -b feature/feature-name
  1. Committing Changes
    Developers work on their local branch and commit changes frequently, following a clear commit message convention such as:
[Feature] Add user role management functionality
[Bugfix] Fix issue with contract validation
  1. Pushing Changes
    Once development is complete, changes are pushed to the remote feature or bugfix branch:
git push origin feature/feature-name

  1. Creating a Pull Request (PR)
    After pushing changes, the developer creates a pull request (PR) on Bitbucket to merge the feature or bugfix branch into develop. The PR should include a description of what was changed, why it was changed, and how it was tested.

  2. Code Review
    All pull requests go through a code review process. Other team members review the changes for quality, adherence to coding standards, and potential issues. Reviewers may leave comments or request changes before approving the PR.

  3. Merging
    Once the pull request is approved, the branch is merged into develop. If the feature is part of a release cycle, develop is eventually merged into master after testing.

    • Feature/bugfix branches are merged into develop.
    • Hotfix branches are merged into both master and develop to keep them in sync.

  4. Deleting Branches
    After the feature, bugfix, or hotfix has been merged and tested, the branch is deleted to keep the repository clean.

Deployment​

Deployments are typically triggered from the master branch. Once changes in develop are stable and ready for production, they are merged into master, and the application is deployed to the live environment.

Summary of Commands​

  • Clone the repository:
    git clone https://[email protected]/elizza-fine-jewellery/flux-crm.git flux-crm

  • Create a new branch for a feature or bugfix:
    git checkout -b feature/feature-name

  • Push changes to the remote branch:
    git push origin feature/feature-name

  • Create a pull request and undergo code review before merging.

Best Practices​

  • Frequent Commits: Commit changes often with clear, descriptive messages.
  • Small, Focused Pull Requests: Avoid large pull requests by breaking work into small, manageable tasks.
  • Code Reviews: Always request and provide feedback on pull requests to maintain code quality.
  • Keep Branches Updated: Regularly pull the latest changes from develop to keep your branch up-to-date with ongoing development.
  • Follow Naming Conventions: Consistent branch names help keep the repository organized.