Development workflow · Knowledge Base

Before you start

You're going to be using git a lot so make sure that:

git is installed on your host.
You have a solid understanding of what git is and you've understood basic concepts (commits, remote/local repositories etc) and how to write good commit messages. If you're not certain, a visit to Github's resources won't hurt.
You are acquainted with the GitFlow workflow and Feature branches. Check this interactive tutorial on branching for some warm-up.

Starting your task

Initiating a task means that by now, a github/jira/whatever issue has been created on a project board and that it was assigned to you.

Set task to `In progress`

Issues start at a Todo state, indicating that no work has been done yet. Move the issue to the In progress state and indicate that you've started working on it.

Create a new branch

As our branching model dictates, there are two branches of significance:

master branch (or main as of quite recently): holds all production releases. This branch receives no commits directly and branches created from it, are permitted only for bug fixes.
development: the main development branch. All feature branches are created from it and all feature branches are merged into it.

Create a new branch from the main development branch (a.k.a. the develop branch) using the following format:

{source branch}_{feature's short name/task description or the issue number}

Example branch name using issue number:
"development_issue-134"

Example branch name with issue/task description:
"development_modify_home_screen"

Suggestion: Use lower case for branch names

During development

This is where coding starts. Make sure that you have developed a solid understanding of both the technical aspect of the task as well as its business impact (or value). Ask your team openly on the project's slack channel or ask a senior project member for guidance when issues arise. Prefer posting questions to public channels instead of PMs (Private messages) as it will spread information widely and allow others to take benefit from it.

Commiting your work

Once you are confident that the implementation is finished you can commit your work. Follow the commit checklist:

View your unstaged files one by one and:
- Remove trailing spaces and unnecessary newlines
- Get rid of commented out code
- Undo changes that are irrelevant
Stage changes and review your files. Study the diff one more time.
Write a good commit message:
- Avoid long lines (50-60 characters per line).
- Use imperative mood.
- Be descriptive of what you did an how. Provide context information.
- Provide relations to issue/task numbers (e.g. "#55 Fix typo").
Examples

Short commit message:
```
#155 Remove Customer.VatNumber property
```
Long commit message:
```
#155 Remove VatNumber property

- Update tests
- Drop index from Customer.VatNumber table
```
A diff will tell you what changed, but only the commit message can properly tell you why

Submit for review

Open a Pull Request and enable other team members to review and approve the implementation. Collective work leads to better results, so, feedback from the Team should be taken into account and may lead to code changes or re-writes.
Once the PR is approved, then merge your feature branch into development, and delete the feature branch from the remote.
Move the related issue to Done state.
Pour some more coffee and start from the beginning.