suvodip ghosh 22fade091d s1
2025-06-12 06:42:01 +00:00
s1
2025-06-12 06:42:01 +00:00
s1
2025-06-12 06:42:01 +00:00
2025-04-16 11:16:19 +00:00
s22
2025-04-21 13:40:26 +00:00
2025-03-19 20:42:16 +05:30
2025-03-19 20:42:16 +05:30
2025-05-27 05:59:30 +00:00
2025-05-27 05:59:30 +00:00
2025-05-27 05:59:30 +00:00
2025-03-19 20:42:16 +05:30
s1
2025-06-12 06:42:01 +00:00
s1
2025-06-12 06:42:01 +00:00
2025-03-19 20:42:16 +05:30
2025-03-20 21:22:46 +05:30
2025-03-19 20:42:16 +05:30
2025-03-19 20:42:16 +05:30
s1
2025-06-12 06:42:01 +00:00

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

Description
No description provided
Readme 26 MiB
Languages
JavaScript 46.9%
Astro 26.6%
TypeScript 26.4%