Git Workflow & Policies

We use Git as our version control system and GitHub as our code hosting platform. Git is a distributed version control system that allows multiple developers to collaborate on a project efficiently. GitHub provides a centralized platform for hosting Git repositories, managing issues, and facilitating collaboration among team members.

Branching Strategy

• Main Branch: Always stable and deployable.
• QA Branch: Integration testing once features pass initial testing.
• Feature/Task Branches: Create a new branch for every feature, bug fix, or improvement.

Branch Naming Convention

• If not created through Huly, use descriptive names; optionally include issue numbers (e.g., feature123-name-authentication).

Commit & Push Guidelines

• Local Commits: Make frequent, small commits with clear, descriptive messages.
• Pushing Changes:
  • Always pull the latest changes from the base branch before pushing.
  • Push your branch to the remote repository frequently to avoid merge conflicts.
  • Build your code before pushing your changes to ensure compatibility.

Conventional Commits

Conventional Commits is a specification for writing commit messages in a consistent and structured format. It defines a set of rules for creating meaningful commit messages that convey the intent of the changes made in a commit. By following the Conventional Commits format, you can make your commit history more readable, searchable, and informative.

• feat: A new feature
• fix: A bug fix
• style: Code style changes
• refactor: Refactoring code
• test: Adding or updating tests
• docs: Documentation changes

Pull Requests (PR)

• Open a PR once the feature/bug fix is complete.
• Include a clear description of changes, referencing any relevant tasks or issues.

Merging

• Do not merge any branches.

Updating .gitignore

• Changes to .gitignore must be discussed in the team and documented.
• Individual developers should not override the company .gitignore without consensus.

Handling Environment Variables

• Environment Variables are located within each project's documentation page in Huly.
• Changes to Environment Variables' files must be discussed in the team and documented.
• Individual developers should not override a project's Environment Variables' file without consensus.