# Coding as a Team

## Feature Development Flow

#### 1. When you start working on a story:

* "Start" the story in Pivotal Tracker
* Create a feature branch \[feature/name-of-feature]&#x20;

#### 2. Once you are done developing the feature:

* Create a pull request in GitHub&#x20;
* "Finish" the story in Pivotal Tracker&#x20;
* Ensure the review app is properly configured and working&#x20;
* Do a functional test on the review app&#x20;
* Ask for a code review (in GitHub) & a functional review in Pivotal Tracker

#### 3. Once the feature has been reviewed and corrected:

* Merge master in the feature branch&#x20;
* Squash merge the feature branch in master&#x20;
* "Deliver" the feature in Pivotal Tracker&#x20;

#### 4. Once the code is on master:

* If the build and deploy to staging goes fine:&#x20;
  * Promote to production&#x20;
  * "Accept" the story in Pivotal Tracker&#x20;
* If the build and deploy to staging goes bad:&#x20;
  * Revert the commit&#x20;
  * “Reject” in Pivotal Tracker&#x20;

{% hint style="info" %}
Same rules apply when your target branch is a release branch, just replace *master* by  your *release branch* in the steps above.
{% endhint %}

{% hint style="warning" %}
Notice that, to ensure easy collaboration within the team, we also try our best to use [git](https://prospect-io.gitbook.io/developer-playbook/our-tools/github-and-tower) according to the best practises. Especially, we do **prefer merge over rebase**, and [**never force push** when working in collaboration. ](https://prospect-io.gitbook.io/developer-playbook/our-tools/github-and-tower#destructive-commands-rebase-squash)
{% endhint %}

## Code Reviews

We do systematic code reviews - each feature or fix, as small as it can be, needs to be reviewed by another team member before going to staging then production.

A **code review is first and foremost a discussion** about how to make the code better.

In order to make this fast, **issues available for review should be given priority over new issues** to work on. We want to get them out as soon as possible.

As a rule of thumb, look at the review column when you arrive in the morning or after lunch and pick up what you can before going back to your own work.

As the committer, try to make the work of your reviewer easier:

* Include a **screenshot** of the feature
* Put any information required to test/reproduce
* Do **yourself a review** before asking others:
  * Run linters or check CodeClimate report
  * Ask yourself what you would comment on that code

Our general approach is the *boyscout rule:* leave the code in a better state that you found it.
