Convention for Branches, Commmits and Pull Requests - bounswe/bounswe2020group1 GitHub Wiki

When to open a new branch?

When you are implementing a new feature
When you are bugfixing
When you are writing a test
When you are improving the documentation part of the already existing code
When you are refactoring an already existing code.

We do NOT push anything to develop branch without a pull request. The code in the develop branch should always be a working and peer-reviewed version of the code.

How to open a new branch?

We follow a name convention for branch names, to make it easier to keep track of changes.

We begin naming of branches with one keyword for representing the team.

backend-
frontend-
android-

We add another keyword according to the type of the job done within that branch.

feature/
bugfix/
test/
documentation/
refactor/

Afterwards, we add a descriptive words(at most three or four). Such as: signInPage, paymentVerification, forgotPassword

At the end, we will have a name in the following format:

          <team>-<type>/<description>

Examples:

I am implementing a new feature, let's say the sign in operation in the frontend. I will create a branch as follows:
```
        frontend-feature/signIn
```
We found a bug in the backend side of the payment system, which causes payments to fail with the code 403. Before solving the bug, we create a branch:
```
        backend-bugfix/paymentFailed403
```

When to commit?

It is mostly a style question and personal. However, best practice is commiting for each descriptive substep of the implementation. Because, when the pull request is created, Github creates an automatic changelog list according to the commit history.

How to commit?

Each commit should have a clear and concise message, describing the small step done.

We do NOT accept commmit messages like these:

Feature is implemented.
commit
minor changes
oopsie
wtf
more changes

Some good commit message examples:

updated test data generation
fixed parsing of --issue-url option.