Guide for a new Repository
- 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 .
- Add readme with endpoints and support doc whenever possible.At the minimum each repo should atleast mention the core responsibilities of the repo.
- Enable Branch protection to avert inadvertent pushes.
- Readme updates in case of special needs like building the proj.
- 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 .
Related articles
https://help.github.com/en/github/administering-a-repository/about-protected-branches
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-status-checks
Joshy's Blog 