The document outlines the process of git branching and code review including different types of branches such as master, staging, developing, feature, and testing. It describes branch policies for creating and merging branches as well as a structured system for code review comments using specific prefixes like 'imo', 'must', 'nit', and 'q'. The overall process ensures code quality through collaboration and testing before deployment to production.

1. Git branching and code
review prefix
Prepared By- Kumaresh Chandra Baruri
Software Engineer

2. Outlines
Different types of branches.
Branch policies
Code review comment & prefix.

3. Different types of branches
1. master What is currently in production.
2. staging contains the code that is being tested before going to
production.
4. develop active development environment. Developer will
create pull request by targeting this branch.
5. feature currently being developed feature. Individual
developer will be working on this. From here, pull request will be created. After
completing the development, the branch will be deleted.
3. testing source codes ready for testing. Testable build will be
prepared from here.

4. master
staging
develop
Feature -01 Feature -02
merge
fast-fwd
rebase
Legend
Branch Policies
testing
1
2
3
4
a) After creating repo, the following branches
need to create sequentially – master staging
testing  develop.
b) In order to develop a new feature and/or bug
fixing, optimization, a new branch needs to
derive from develop called Feature-
01/Feature-02 etc.
c) After completing development, it needs to
rebase before submitting the branch to cloud.
d) Developer will create Pull Request (PR) to
develop.
e) Reviewers will review and back and forth
communication.
f) Code merged to develop.
g) In order to test, code will be fast forwarded to
testing.
h) When testing passed, codes are fast-forwarded
to staging and finally to master or production.
Release, hot fix
branches can be
managed by
demands.

5. Code review comment & prefix
1. IMO  In my opinion . If reviewer has a different opinion on a statement,
he/she will put this prefix. Like-
• [IMO] This statement will never be executed.
2. MUST  Must have to change the statement to maintain code quality
according to defined code convention.
• [MUST] Access modifier of the variable is private.
• [MUST] Variable name start with underscore(_).
3. NIT Nit pick. That is, a small change that may not be very important,
but is technically correct. Can be treated as a suggestion.
• [NIT] Rather than long data type, integer type will satisfy the
requirement.
4. Q  If there is any question on an statement, user can put this Q
comment.
• Like- [Q] Why the function is returning null even though return type
is string?