![]() |
||
---|---|---|
public | ||
src | ||
.gitignore | ||
README.md | ||
astro.config.mjs | ||
bun.lock | ||
cicd-deploy.yaml | ||
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