# Atlas Contributing ## Speedio Best Practices Here we have all of our best pracites to ensure code consistency and code quality. Every item here must be followed on every project, old or new. *A few of our projects has its own Readme and you must follow this best practices plus the ones mentioned on the project's Readme file.* ___ ### Versioning releases Our releases follows Convetional Commits structure, which consists in **major** changes for **BREAKING CHANGE**, **minor** changes for new features and **patchs** for bugfixes, see below: - **Release Branch** The release branch must be created with ```release-<MAJOR>.<MINOR>.<PATCH>``` ___ ### Conventional Commits We use Conventional Commits to ensure consistency and clarity on our commit messages, we'll cover a few examples below and at the end the entire documentation will be accessable through official site. - **Feature** ```feat: <Describe what's new and the files and/or methods you've changed>``` - **Bug** ```fix: <Describe the problem, the solutionn and the files and/or methods you've changed>``` - **Chore** ```chore: <Describe what you changed and the files/or methods you've changed>``` - **BREAKING CHANGE** *BREAKING CHANGE must be included on any type of commit message and it indicates a **major** change in the code.* You can access the entire documentation through [official website](https://www.conventionalcommits.org/en/v1.0.0-beta.3/). ___ ### GitFlow GitFlow is a branching model for Git and we use it to ensure our branch consistency and avoid wrong merges and/or commits on our main branches. Below we have simple installation guide, our main branches and what kind of action each branch accepts and main GitFlow commands. **Installation** GitFlow is very simple to install, you can check [how to install on your OS here](https://github.com/nvie/gitflow/wiki/Installation). **Our main branches** - **Master** Accepts only merges from staging and hotfix branches. - **Staging** Accepts only merges from feature, hotfix and support branches. **GitFlow Commands** - **Initiate GitFlow** To start to use GitFlow just run `git flow init` *When you're asked **How to name your supporting branch prefixes?** you'll need to rename **develop** to **staging** and you're good to go.* - **Feature** *Every feature branch will be automatically created from latest staging version.* - Create a new feature branch: ```git flow feature start <name>``` - Once you've finished your changed and it's ready to go to staging, do: ```git flow feature finish <name>``` The command above will automatically merge your branch into staging. - **Bugfix** *Every bugfix branch will be automatically created from staging and must only contain bug corrections.* - Create a new bugfix branch: ```git flow bugfix start <name>``` - Once you've finished your corrections and it's ready for staging, do: ```git flow bugfix finish <name>``` The command above will automatically merge your branch into staging. - **Support** *Every support branch will be automatically created from staging and must only contain list corrections, refactorations and test corrections.* - Create a new support branch: ```git flow support start <name>``` - Once you've finished your changes and it's ready for staging, do: ```git flow support finish <name>``` The command above will automatically merge your branch into staging. - **Hotfix** *Every hotfix branch will be automatically created from **MASTER** and must only contain urgent corrections for **production** problems.* - Create a new hotfix branch: ```git flow hotfix start <name>``` - Once you've finish your **urgent corrections** and **tested it twice**, do: ```git flow hotfix finish <name>``` **The command above will merge your hotfix branch into MASTER** - **Release** *Every release branch will be automatically created from **staging** to be merged on **master**.* - Create a new release branch: ```git flow release start <name>``` - Create a new release tag with: `git tag -a <name> -m "Release version <version>"` - Once you've tested every change that was on staging and you're sure it's all working as it should, do: ```git flow release finish <name>``` *The command above will merge **staging** on **master**.* ___ ### Pull Requests Pull request(PR) is a method of submitting contributions to an project, it allows other developers to review and test your code, preventing bugs and/or misfunctional code before those changes are merged to staging. ***Pull requests must be small and cover a single bugfix, feature, support or hotfix. Small PRs are easier to test and to ensure code quality*** *We're currenty using GitLab to store our repositories, and it calls Pull Request as Merge Request* **Creating a new Pull Request/Merge Request** - Go to Merge Request tab and click on `New Merge Request` - Select your source branch, that is, the branch with your changes - Select the target branch, that is, the branch which your changes should be merged to - Click on `Compare branches and continue` - Add a small text describing why you're making that Merge Request and what changed - Assign to a developer to test your changes - Check the box `Delete source branch when merge request is accepted.` so we don't end up with endless branches that are no longer used - Click on `Submit Merge Request` and your request is done. Once the assigned developer finished testing, he/she will approve and merge your request. ***Remember, feature, bugfix, support branches must go to STAGING and hotfix must go to MASTER***