About App

Now you can find the app on the Google Play.

The Git Repository Naming Conventions

Comits

Summary

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

1. Separate subject from body with a blank line

If your commit has a body, then separate it from subject using blank line. For Example:

Derezz the master control program

MCP turned out to be evil and had become intent on world domination.
This commit throws Tron's disc into MCP (causing its deresolution)
and turns it back into a chess game.

But not every commit requires both a subject and a body. Sometimes a single line is fine, especially when the change is so simple that no further context is necessary. For example:

Fix typo in introduction to user guide

2. Limit the subject line to 50 characters

50 characters is not a hard limit, just a rule of thumb. Keeping subject lines at this length ensures that they are readable, and forces the author to think for a moment about the most concise way to explain what’s going on.

DO:

Add the new method to the class Cat

DON'T:

Add the new method to the class Cat and add the new fields to the Dog class 

3. Capitalize the subject line

DO:

Implement the new feature 

DON'T:

implement the new feature

4. Do not end the subject line with a period

DO:

Delete the deprecated code

DON'T

Delete the deprecated code.

5. Use the imperative mood in the subject line

Imperative mood just means "spoken or written as if giving a command or instruction"

DO:

Remove the bad code

DON'T:

Removed the bad code

DON'T:

Removing the bad code

To remove any confusion, here’s a simple rule to get it right every time.

A properly formed Git commit subject line should always be able to complete the following sentence:

• If applied, this commit will your subject line here

6. Wrap the body at 72 characters

Git never wraps text automatically. When you write the body of a commit message, you must mind its right margin, and wrap text manually.

The recommendation is to do this at 72 characters, so that Git has plenty of room to indent text while still keeping everything under 80 characters overall.

7. Use the body to explain what and why vs. how

This commit from Bitcoin Core is a great example of explaining what changed and why:

commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200

Simplify serialize.h's exception handling

Remove the 'state' and 'exceptmask' from serialize.h's stream implementations, as well as related methods.

As exceptmask always included 'failbit', and setstate was always called with bits = failbit, all it did was immediately raise an exception. Get rid of those variables, and replace the setstate with direct exception throwing (which also removes some dead code).

As a result, good() is never reached after a failure (there are only 2 calls, one of which is in tests), and can just be replaced by !eof().

fail(), clear(n) and exceptions() are just never called. Delete them.

Take a look at the full diff and just think how much time the author is saving fellow and future committers by taking the time to provide this context here and now. If he didn’t, it would probably be lost forever.

In most cases, you can leave out details about how a change has been made. Code is generally self-explanatory in this regard (and if the code is so complex that it needs to be explained in prose, that’s what source comments are for). Just focus on making clear the reasons why you made the change in the first place—the way things worked before the change (and what was wrong with that), the way they work now, and why you decided to solve it the way you did.

This rules are based on this article: https://chris.beams.io/posts/git-commit/

Branches

Summary

1. Use hyphen as separators of words
2. Create a new branch to implement a new feautre
3. Add prefix to the name of a new branch
4. Add Issue id

1. Use hyphen as separators of words

DO:

temporary-version

DON'T:

temporary_version

DON'T:

temporaryVersion

2. Create a new branch to implement a new feautre

Every time when you need to implement a new feature you must create a new branch. Ensure that the new branch is based on the master branch. Keep in mind that the best practice is when one branch solves one Issue.

3. Add prefix to the name of a new branch

Prefix	Meaning
bugfix	Fix Issue marked with label "bug"
feature	Implement a new feature
experimental	Make any experiments

4. Add Issue id

If you going to create a new branch to solve some Issue then add the id of that Issue.

DO:

bugfix/16-button-overflow

DON'T

bugfix/button-overflow

DO:

feature/23-irlas-list

DON'T:

feature/irlas-list

How To Support 2 Versions

At this moment we need to support two versions of the app. First one is the main version. Second one is the temporary version that explains user that main version will be soon available. And we have an aglorithm:

Action	Who does
Create new local branch based on master	Dev
Make some work	Dev
Create pull request to push changes to the master branch	Dev
Merge pull request	Senior
Make cherry-pick from the last master merge to the temporary-version	Senior
Make pull request from temporary-version to the master branch	Senior

This actions need to be applied when you resolve some Issue or implement any feature that need to be applied to both branches. When you need to apply some changes to specific branch you must do classic way.