Skip to content

Git Conventions

Jump to bottom
Altynbek Orumbayev edited this page May 14, 2019 · 9 revisions

687474703a2f2f6936332e74696e797069632e636f6d2f333031336c67342e706e67

linkedpipes-logo


Git Branching Conventions

• Never commit changes directly to master and develop branches.

How to make commits ?

  1. To make any code changes, branch out from the develop branch and give the branch an appropriate name based on the feature change.

  2. After development on this branch is complete, create a pull request from that branch back into ‘develop’. Once at least one peer has reviewed and accepted the pull request, merge it.

  3. After merging, delete the feature branch if no longer needed, or ask Team Lead to delete it.

Working with other team members within a branch

• In the case of a feature change that requires code changes from more than one team member, team members can collaborate on the same feature branch, either by making commits on the same feature branch directly, or by individually branching out of the feature branch and then merging back to it once the individual part is done. Team members should communicate and coordinate with each other in case of this type of change.

• Do not create pull requests targeting the master branch, unless from the develop branch and only upon confirmation from Team Lead. The master branch needs to remain stable and these pull requests should be kept to a minimum and only done if tests on develop did not raise any issues.

• Ultimate goal is to have a pull request towards master created before every meeting with the supervisors, and this branch will be used to demonstrate updates during the meeting. Pull requests towards master need to be approved by Team Lead. In case if she is unable to do so, another peer can approve the pull request.

Git naming conventions

Commits messages

There are 4 main categories within LPApps projects defined as follows :

  1. [Backend],
  2. [Frontend],
  3. [Deployment],
  4. [General].

Each of those categories include following subcategories :

  1. [Refactor] - specifies changes done toward refactoring code,
  2. [Bug Fix] - specifies changes for fixing certain bugs,
  3. [Feature] - specifies changes that introduce new feature,
  4. [Other] - specifies everything else that is not covered by first 3 subcategories.

• Each of the subcategories can have an additional prefix [Travis]. In case you will want to trigger travis build for your specific commit include that prefix after a subcategory into your commit message to trigger a build. Otherwise, by default - Travis will be only called during pull requests on feature branches. To be more specific those tags are described as follows:

  1. [Travis] - start build and unit testing stages,
  2. [Travis-Integration] - start integration tests stage,
  3. [Travis-Deploy] - build and deploy latest code to DockerHub.

• Each commit message should start by specifying the main category to which this commit is related followed by any subcategory that includes more detailed explanation of the commit.

• Each category and subcategory should be wrapped into square bracket symbols. Consequent commit message should always start with an uppercase letter. If there is more than one sentence in a commit message, consequent sentences needs to be separated by ; char and also start with an uppercase letter.

• Maximum length of commit message summary is 72 chars. If the text is bigger than 72 chars, consider splitting and moving it into git commit message details.

Sample commit messages

[Backend][Refactor] Restructured unit tests; Improved code  
[Frontend][Feature] Implemented new shiny button
[Deployment][Other] Updated .travis.yml; Removed old Dockerfile
[Frontend][Bug Fix][Travis] Fixed a Webpack bug; Minor updates
Clone this wiki locally