Branching Strategy

Chosen strategy - Git flow

We have main and dev branches. All feature branches must be merged into dev branch!!! Only the release should merge into the main branch!!!

Working process:

Step 1

• Option 1

  • 👯 Clone front-end or back-end repo to your local machine using git clone

• Option 2

  • Create new feature branch from develop branch using: git checkout -b issue_4_feature_name

Step 2

• 💅🏼 Add new files and make commits to your feature branch using: git add ., git commit -m "commit message"

Step 3

• 🐇 Push your feature branch to remote origin using: git push issue_4_feature_name

Step 4

• If remote develop is ahead of your local branch download new commits using: git pull

Step 5

• 🔃 Create a new pull request and asign at least 2 people to check your changes in order to merge it

Useful links about branch:

Git workflow

Commit styling

Pattern: <type>[(scope)][!]: <description>

• Type — Of the many types of commits, the main types are feat and fix. But there are also build, chore, docs and others.

1. feat (Feature) — Use when new functionality gets added to the application.
2. fix (Fix) — Use when changes made by a commit fix errors in already existing parts of the application without changing its functionality.
3. build (Build) — Use to make changes to the build system or external dependencies that are required for the application to work.
4. chore (Chores) — Use when changes are not related to the operation of the application.
5. ci (Continuous Integrations) — Use when changing the continuous integration configuration.
6. docs (Documentation) — Use when changing the documentation, such as typo fixes, adding languages, etc.
7. refactor (Refactoring) — Use when there are changes in the structure of the code that don't affect the functionality.
8. revert (Reverts) — Use for a commit that reverts the previous changes that have been made by mistake or with some violations.
9. style (Style) — Use for changes in the style of the code, without changing its structure (adding/deleting whitespace/newlines, etc.).
10. test (Testing) — Use when changing the testing system like adding new tests or changing old ones.

• Scope (optional) — Scope describes the part of code or documentation that is affected by the changes made by this commit. For example: api, parser, etc. Indicated in parentheses. You can identify multiple scopes that can be separated by ,, / and .

• Exclamation mark (optional) — The exclamation mark is used to emphasize the importance of the commit.

• Description — This part includes a short description of the changes made. The description length is usually one brief sentence.

Examples

fix: /users api endpoint error fix feat(api): add /documents endpoint

Branch names

<type>(feature/fix)-Task №-short task name