Sign in Subscribe
Engineering👨‍💻

git workflow

Srujan

• 3 min read

This is more or less equivalent to famous git branching model described in:
http://nvie.com/posts/a-successful-git-branching-model/

Let's make the ground rules.

  1. master has latest stable code. It's in production container.
  2. develop is integration branch, where all the code contributed gets merged. It's developer's main branch and everyone should be updated with it.
  3. release If continuous integration is not yet there, testing is majorly done by QA at a certain cycle. They shall take the branch from develop to release and test on it before making it to master.
  4. feature/<feature_name> will have feature currently being developed. There can be several feature branches depending upon how many devs are working on each.
  5. bugfix/<name> deploys in release, current or next.
  6. hotfix/<name> deploy it to current master. This is directly affecting customers.

Flow of Developer's git life

Let's work on project called "Batman".
A set of developers had to work on building "batarangs".
There must be a simple document of what 'batarangs' is, and why are we building it. 'What' should be easy-to-understand by any layman. 'Why' should be simple.

This doc should be in wiki (or company's documentation location) of the project, and shared with peers.

Take out a feature branch from parent develop. Name it feature/batarangs. Start developing on this feature branch.

Using trello (or any such), divide your feature into small tasks, to conquer them independently. Everything you conquered shall be reviewed by peers.

  • Document review -- Changes in requirements, if any. Sample inputs, outputs, mocks would be helpful.
  • Architecture review -- involves db schema, infrastructure, top level programming structure, etc.
  • Cost review -- estimating cost of the project, including resources cost after final architecture.
  • Code review -- For each small task completed, get the code reviewed.

After development, deploy it to a feature container. Test that feature independently there.

Once feature testing is done, raise a Pull request (PR) on develop branch. Once merged into develop, it is assumed that the feature is ready to go into production, signed off by developer.

QA git life

On each new PR to develop, a sequence of tests should run by QA followed by manual testing of independent feature. The PR is automatically closed in case of any failures and bugs.

In case of any bugs discovered after merging to develop, checkout new branch bugfix/<bug description> from develop. Fix the bug, raise a new PR.

Once the feature is good to go, make a new branch release from latest develop branch.

Release branch gets deployed on pre-prod environment, where the continuous integration tests are ran. No manual testing should be required here, unless test coverage is weak.

Merge release to existing master if pre-prod gives all positive and tag release with latest version/subversion. Delete release branch.

This release tagged, shall be deployed to production.

If there is any critical issue in production, take out a branch from latest master, hotfix/<hotfix_desc>. PR to master, test on pre-prod, merge if successful.
Update the develop branch with latest master.

Release tags naming convention

Major releases - ex. 0.1.0, 0.2.0, etc.
Minor releases/Hot fixes - ex. 0.1.4 for release 0.1

Using origin and upstream

In case of multiple people working on same feature, fork the repo.
Use it for active development.
For co-ordination with others, use upstream's feature branch.
Origin branches need not be updated with upstream's develop branch as the upstream-feature is always updated with upstream develop.
This might not be necessary if there is only one developer doing the changes in branch.

Note:

  1. In all merges, make sure you use --no-ff so that revert is possible.
  2. Make sure commit messages are lesser in number and cleaner. Using origin and upstream is helpful if multiple developers are working on same feature.
  3. Few bug-fixes in master may not be very critical. Such fixes can go in next release instead of minor version. Classifying bug-fix and hot-fix correctly is crucial.