Go to file
suvodip ghosh 7258809230 last add topic pages and content 2025-04-16 11:16:19 +00:00
public last add topic pages and content 2025-04-16 11:16:19 +00:00
src last add topic pages and content 2025-04-16 11:16:19 +00:00
.gitignore last add topic pages and content 2025-04-16 11:16:19 +00:00
README.md readme add git branch flow 2025-03-20 21:22:46 +05:30
astro.config.mjs last add topic pages and content 2025-04-16 11:16:19 +00:00
bun.lock init 2025-03-19 20:42:16 +05:30
cicd-deploy.yaml init 2025-03-19 20:42:16 +05:30
netlify.toml init 2025-03-19 20:42:16 +05:30
package-lock.json last add topic pages and content 2025-04-16 11:16:19 +00:00
package.json last add topic pages and content 2025-04-16 11:16:19 +00:00
postcss.config.mjs init 2025-03-19 20:42:16 +05:30
tailwind.config.mjs init 2025-03-19 20:42:16 +05:30
tsconfig.json init 2025-03-19 20:42:16 +05:30
yarn.lock last add topic pages and content 2025-04-16 11:16:19 +00:00

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