Go to file
Suvodip 9cbe98eff5 marge get-started-new-code 2025-03-31 16:51:02 +05:30
public 404 2025-03-27 20:36:20 +05:30
src marge get-started-new-code 2025-03-31 16:51:02 +05:30
.gitignore add domains flder and functionality 2025-03-25 20:34:34 +05:30
README.md readme add git branch flow 2025-03-20 21:22:46 +05:30
astro.config.mjs init 2025-03-19 20:42:16 +05:30
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 work on invoice generation 2025-03-31 13:55:35 +05:30
package.json last work on invoice generation 2025-03-31 13:55:35 +05:30
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 work on invoice generation 2025-03-31 13:55:35 +05:30

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