Repository Policy

---

Version 0.3

Version	Date	Description	Responsable
0.1	26/03/2017	Document creation	João Paulo
0.2	27/03/2017	New Branches Policy	João Paulo
0.3	27/03/2017	Defining the UC breaks	João Paulo

1. Branches Policy

• The repository will be divided into two main branches and n branches for issues (use cases) in development.
• The Master Branch is protected, therefore it can`t receive direct commits. It contains the stable version of the project.
• The development branch will be protected as well and is where the work of the entire team will be unified. If the branch is stable and generates a functional build a pull request for the master branch must be performed in every sprint.
• The other branches should be created for the development of an issue x and must have the same name of the issue in question following the pattern: C1UC1_name_of_use_case_backend or C1UC1_name_of_use_case_frontend Upon completion (stable and properly tested code) of the functionality the pull request to development should be done.
• At the beginning of each day, before developing any functionality the developer must update the branch in which he will work with the branch development, to ensure that his branch is with all the work done with the previous day and avoid greater problems using the pull --rebase.
• At the end of the sprint, the developers must submit a pull request from his branch, with tests, to branch development.
• Issues should be closed as soon as the code is accepted and integrated.
• The issues branches should be deleted after 1 week of your integration.

2. Commits Policy

• All commits must be in English and capitalized at the beginning.
• All commits should be atomic, in other words, contemplate as little code as possible, a method for example.
• Every commit must be related to an issue(use case).
• All commits must follow the following pattern:

git commit -s - This will open the commit edit window

In the commit edit window, follow this pattern:

Name of the developed task

Commit description

Related to issue #n

Signed-off-by: Name of the commiter <email@email.com>

Signed-off-by: Name of second commiter <email@email.com> - This is for the paired commits

3. Issues policy

• Issues are the representation of features from use cases. They must be signed for a member of the team (if the pairing is foreseen in XP, the issue must be signed for the pair).
• Each partner or developer will be responsible for creating and maintaining your issue until it is resolved, integrated, or passed on to someone else to resolve.
• The issue should have a label to indicate its status and after completion and integration should be closed.
• The issue should be allocated in one of the 2 epics (Software Design or Programming Techniques) and, if applies, in other epic that represents a larger Use Case.
• The issue will be allocated to milestones that are phases or sprints. In this way the tracking will be carried out more accurately.

4. Zenhub

The zenhub tool assists in tracking requirements within github. In it we will have a kanban with cards that will be the issues / stories and epics (disciplines) for the cards to be organized.

In it we will assign people to stories, points to the features, sprints and epics of each issue.

Each card should be dragged into the project's own kanban columns