Git

We use git to help us manage changes to our source code over time. Follow along to get some insights about our workflow.

If you are new to git, please read the following blogs to get started:

Setting up a new project

Setting up a remote repository

We use Bitbucket for web-based version control repository hosting service, so if not already done

  1. Create a new project in Bitbucket.
  2. Create a new repository in the newly created project.
  3. Create a new branch named develop.

  4. Navigate to Settings -> Workflow -> Branch permissions.

    (i) Create branch permission for branch develop and master.

    (ii)Uncheck the Allow rewriting branch history and Allow deleting this branch checkbox for both the branches.

    (iii) Onboard your team.

master stable branch and should only be used for client and production releases.

develop should always be the latest stable branch where all development PR's would be sent to.

Creating a PR template

PR template helps us to remind of some things which are essential for the project's sanity to be maintained. While working with the team we all must follow some basic rules and provide useful information to the reviewer.

If you are an admin of the repository

  1. Go to Settings.

  2. Under the PULL REQUESTS heading, click Default description and paste the following content.

     ## Description

 ### Why was this change necessary?

 [text here]

 ### How does it address the problem?

 [text here]

 ### Are there any side effects?

 [text here]

 ### Do you want any specific feedback?

 [text here]

 ### Do you have resources that will help the reviewer?

 [MP-](https://messengerpro.atlassian.net/browse/MP-)

 ### Zeplin screen design links?

 [link here]

  3. Change the Jira tickets prefix according to your Jira project and click save.

  4. If you have already created your project locally then modify it's .gitignore file according to you and connect your local project to remote repository else clone the project to your local machine.

Connecting your web repository to the project management tool.

We use Jira as our project management tool.

Please contact your project manager to set up workflows which will help in automating issue/ticket tracking process.

Jira Linking

Generally, all of your tasks are mentioned in the project management tool. This helps in keeping a record of the productive time you spend working for the company.

Branch Naming

Git branches are effectively a pointer to a snapshot of your changes. When you want to add a new feature or fix a bug—no matter how big or how small—you spawn a new branch to encapsulate your changes. If you have not created a new branch till yet go ahead and create one.

Type the following command to create a new branch

git checkout -b {$new_branch _name}

Most of the time branched should be created by your issue/ticket number in Jira.

{$your_jira_project_prefix} {$dash} {$issue_number}

Here are a few examples of how the branch should be named.

Ideally, you should work with one ticket at a time, raise its PR to develop and pick another one but if the issue is too small or it takes little time and effort to fix, you can pick multiple tickets at a time. Below are some sample branch names.

Working with a single ticket at a time

 ALT-223
 QQ-54
 INFLCR-223

Working with multiple tickets at a time

 ALT-223-ALT-224-ALT-305
 QQ-54-QQ-125-QQ-87
 INFLCR-223-INFLCR-25

However, if you happen to work on an issue which is not on Jira yet, convey this to your project manager to put that on Jira and in the meanwhile, you can create a branch like

If before raising your PR the ticket is created, rename your branch using

git branch -m {$new-name}

Commit message format

We follow a strict specific commit format so that every commit message is well-formatted and self-explanatory. It helps the reviewer or teammate to quickly understand the intention of the commit and provide feedback accordingly.

Below are some sample commit message, their structure, and explanation of them.

feat(ALT-653): Add continue button in the login screen to navigate to next page

fix(INL-345): Fix Splash screen animation bug

chores(*) : Add progaurd rules, base project set up

This commit message is divided into 4 sections:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
Type Description
feat() This essentially represents that your commit will add a feature.
fix() This represents that your commit will fix a bug.
chores() This represents that your commit is doing some project structure related work.
docs() Documentation only changes.
test() Add missing tests.
refactor() A code change that neither fixes a bug or adds a feature.
perf() A code change that improves performance.

  1. Type: These represent the type of feature or fix your commit will do.

  2. Scope: This could be anything defining the place of change a commit. Usually, it can be the ticket number you are working on. If there is no ticket assigned you can replace it with an asterisk *.

  3. Subject: This is a short yet meaningful description of your commit. Below are few points to keep in mind for a descriptive commit message.

    • Capitalize the first letter.
    • Limit the subject line to 50 characters.
    • Do not end the subject line with a period(.).
    • Use the imperative mood in the subject line. For example: Fix Splash animation bug not Fixes Splash animation bug nor Fixed Splash animation bug.

  4. Body: Body in a commit message is used to describe changes in your commit in a more descriptive way. Although it is not always compulsory to write body in every commit message but it is a good practice to write it to explain your changes.

Here is how you can write a commit message body.

  1. Write git commit command without any flags.
  2. It will open your pre-configured editor.
  3. If the editor is vim then enter insert mode by pressing i or insert key.
  4. Enter your precise commit message in the first line.
  5. Leave a blank line.
  6. Enter the description body of your changes.
  7. Press Esc and then press :wq to save and quit the editor.

Raising a PR

Few important things to remember while raising your PR to be merged so that we all can benefit from it and it's important to follow some standard conventions while creating pull requests:

Before creating a pull request

We follow the concept of rebase to maintain a linear project history of git tree and clean branching model, so it is important to squash your commits and rebase with develop branch.

Do not hesitate to push your work regularly to the cloud, but after completing your task combine your commits into minimum meaningful commits.

Note: Do not try to squash the commits of develop, master or whichever branch on which multiple people are working on. Their commit history and integrity should be maintained.

Here are a few steps you can follow to achieve the same.

  1. Commit all your work.
  2. Count the number of commits you want to squash using git log --oneline.
  3. Start an interactive rebase session by typing git rebase -i HEAD~{$number_of_commits_to_squash} in terminal.
  4. In the window pick or squash the commits using p or s after entering insert mode.
  5. If the conflicts occur resolve them using git mergetool.
  6. After resolving the conflicts add them using git add . and continue rebasing them using git rebase --continue.

Read the above-described process in detail here.

Pro-tip: You can also achieve the above same process using git reset HEAD~{$number_of_commits_to_squash}. It avoids conflicts by simply un-committing your work and then you can simply combine your work in a single commit. git pull --rebase origin develop

Rebase your branch from develop

  1. Checkout to develop branch.
  2. Update your local branch using git pull origin develop.
  3. Checkout to your branch and run git rebase develop.
  4. Resolve your conflicts if any using the above-described process.
  5. Force push your changes using git push -f origin {$branch_name}

Follow and maintain below points in your PR for it to be reviewed

  1. Your PR should be small and specific to a unit or granular task.
  2. If you have implemented anything new, please mention the relevant links to it.
  3. The code contained within will meet the best practices set by the team wherever possible.
  4. Write your test cases vigorously.
  5. Fill the description form, add all your working teammates as reviewers so that every person is aware of changes in the code base and hit the Create PR button.

Reviewing a PR

Having proper communication on the internet for the benefit of the project is one of the most important aspects of the project. Following practices collected from Github's blog and other sources should be followed.

Responding to feedback on Pull Requests

Best Practices