Git repository and branching standards

Guide for a new Repository

  1. Tag your Git repos along with application name or common theme which is relevant for that repo.Eg you might have several repos related to a proj called MyCart, tagging all the repos with MyCart will help discover them faster .
  2. Add readme with endpoints and support doc whenever possible.At the minimum each repo should atleast mention the core responsibilities of the repo.
  3. Enable Branch protection to avert inadvertent pushes.
  4. Readme updates in case of special needs like building the proj.
  5. Adding last Build run statuses using urls to you pipeline.

There is no limit on how far we would want to refine our git standards, but i have only concentrated on the min here which are the first 5 points above.

Code Check-in Guidelines

  • Before starting any work, take the updated code from git
  • Cut a branch name prefixed with feature Eg “feature-” from dev
    • this can be tagged to create a build name prefixed with “b” in drone (Example: b54-123e1222)
    • test your changes locally 
  • Once testing is done, create a Pull Request from your feature-* branch to dev
    • On merge, this should create a build name prefixed with “dev” in drone(Example: dev64-ff4e1233)
    • deploy these “dev*” builds in dev environment
    • test your changes in dev environment.
  • The last merge happens from dev to master via another Pull Request
    • this can create a build name prefixed with “p” in drone(Example: p34-22e6e882)
    • deploy these “p*” builds in prod environment
    • test your changes in prod env
  • Once the changes are deployed to prod, delete the “feature-*” branch

** In some scenarios if you keep a stage branch you will want to merge your changes from dev→ stage before you move to master. This will facilitate a prod like environment for UAT .