---
# System prepended metadata

title: Atlas Contributing

---

# 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***
