Subhodip Ghosh
1b4cb0382d
Reviewed-on: #40 |
||
|---|---|---|
| public | ||
| src | ||
| .gitignore | ||
| README.md | ||
| astro.config.mjs | ||
| bun.lock | ||
| cicd-deploy.yaml | ||
| edit.js | ||
| env_sample.txt | ||
| facebook.json | ||
| fix-php-tags-and-decode.cjs | ||
| github.json | ||
| google.json | ||
| netlify.toml | ||
| package-lock.json | ||
| package.json | ||
| postcss.config.mjs | ||
| tailwind.config.mjs | ||
| tsconfig.json | ||
| yarn.lock | ||
README.md
git flow guide / protocol
dev - any one is free to create / push to / any experiment on this branch
staging - it is the stage for all developer. all branchout and push over here.
*start point / fork point is staging, i.e. any fix/feature/improvement - you must start branching out from staging.
*better to name your branch with 'z-' , i.e. z-layout-footer-improvement (z-: identifier for temporary and safe to remove from the central repo -> then the file identifier -> then short info regarding the intent) *many developers prefer feat/feature_name, i faced issue managing those branch using cli (bsd even alpine) for the slash(/)
staging must have a automated test and deploy mechanism, so that developers can can always be on the same page regarding build/merge conflict issue
test - staging to test by tester
master - test to master by tester after full test
release - master to release with version tag
final packaging and release