---
# System prepended metadata

title: VistaRooms Git Workflow

---

# VistaRooms Git Workflow
This document aims to walk a VistaRooms developer through the ideal Git/version control practices to follow while developing.
The document covers two main flows - 
- Feature development
- Bug fixing

## Feature development
This flow covers the process to be followed when a new Jira ticket for a new feature/improvement is assigned to a developer.
The ticket will be created by the project/product manager and assigned during the sprint.
Once the ticket has been assigned, the developer should follow the process below. We'll take the [convenience fee ticket](https://vistarooms.atlassian.net/browse/VRW-2113?atlOrigin=eyJpIjoiODc0OWQ1YjgwNDcwNDNjZmFkZDI0OGMxZjlmMjMyZDQiLCJwIjoiaiJ9) as an example.

1. **Create a development branch**
Create a branch off the `dev` branch called `convenience-fee`. Your development branch name should be related to the
feature you're working on.
    ```bash=
    git checkout dev
    git pull
    git checkout -b convenience-fee
    ```
    
2. **Make your changes**
Do all your development related to the convenience fee feature on this branch only. Ensure you're committing your code frequently after small/logical changes. 
    ```bash=
    git add <FILE-1> <FILE-2>
    git commit -m
    ```
    
    Write out a detailed commit message that talks about what changed and why.
    
    Avoid using `git add .` and staging all your files for a commit. You should add files selectively and write a commit message specifically for the changes in those files.
    
3. **Push your branch to remote**
Once you're done testing your work locally, merge any latest changes from the master branch and push your local branch to the remote.
    ```bash=
    # pull latest changes into your dev branch from master
    git checkout dev
    git pull
    git checkout convenience-fee
    git merge dev
    
    # push your development branch to the remote
    git push origin convenience-fee
    ```
5. **Merge into `dev`**
After testing your code locally, you can prepare your code to be merged into the `dev` branch.
For any code merged into `dev`,`staging` or `production` branches, we go through the proper code review process as outlined below.



    a. Go to the repository in the BitBucket GUI![](https://i.imgur.com/KgAWOhh.png)
    
    b. Click on `Create pull request`
    ![](https://i.imgur.com/AdqFlDu.png)
    
    c. Select the source and destination branches. The source branch on the left is the development branch that you want to merge with dev. The destination will be `dev`.
    ![](https://i.imgur.com/53YXeML.png)
    
    d. Ensure you give a proper description according to the template provided. Also give details of the JIRA task this update resolves.
    
    e. Add at least 2 reviewers for your code - QA and another developer.
    
    f. Ensure the `Delete branch` box is checked
    
    g. Click `Create pull request`
    
    h. Wait for the reviewers to review and approve. 
    
    Once your code gets merged, your development branch will automatically be deleted. You can now safely deploy the `staging` branch with your latest changes.
    
    
6. **Merge into `staging`**
    Once your code's been tested properly on dev and gets approval from the QA and managers, you can deploy your code to staging after merging your code from `dev` to `staging`. You should _only_ merge code into `staging` from `dev` and `hotfix` branches (see Hotfix flow below).

    Follow the same process as above. The only difference will be your source branch will be `dev` and your target will be `staging`. You will add the same reviewers as your earlier pull request. In the Jira tickets, you can add any additional bugs that showed up after deploying to `dev`.
    
7. **Merge into `production`**
Once your code is tested on `staging` and receives QA and manager approval, merge it into the production branch. Follow the same process as #5, except your source will be `staging` and the target will be `production`. You should _only_ merge code into `production` from `staging` and `hotfix` branches


## Bug fixing
The only exception to the development version control flow is when you need to fix a bug in `production` or `staging` branches.

1. If the bug is in production, create a branch off `production` with the prefix `hotfix`
    ```bash=
    git checkout production
    git pull origin production
    git checkout -b hotfix-convenience-fee-issue
    ```

2. Fix the issue and commit with a useful commit message on how the bug was fixed
    ```bash=
    # Make changes to files
    git add <FILE>
    git commit -m
    ```
    
    Write out a detailed commit message describing how you fixed the bug and tested it
    
3. Follow the steps 4, 5 and 6 from the Feature development workflow. The fixes should be first merged into the `dev` branc and tested on the dev setup. Then merged into the `staging` branch to be tested on the staging setup. Finally, once QA and managers confirm the bug has been fixed on staging, we can merge code into `production` and deploy.


## Resources

### Git cheat sheet
[PDF](https://www.atlassian.com/dam/jcr:e7e22f25-bba2-4ef1-a197-53f46b6df4a5/SWTM-2088_Atlassian-Git-Cheatsheet.pdf)


### Writing good commit messages
[Link](https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/)

### Creating good pull requests
[Link](https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests)