Go to file
suvodip ghosh 1c6e06bd6d s1 2025-06-18 08:44:08 +00:00
public fix markdown editor css and change mobile bottom nav menu 2025-06-16 15:42:05 +00:00
src s1 2025-06-18 08:44:08 +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 s22 2025-04-21 13:40:26 +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
facebook.json updated siliconpin 2025-05-27 05:59:30 +00:00
github.json updated siliconpin 2025-05-27 05:59:30 +00:00
google.json updated siliconpin 2025-05-27 05:59:30 +00:00
netlify.toml init 2025-03-19 20:42:16 +05:30
package-lock.json s1 2025-06-12 06:42:01 +00:00
package.json s1 2025-06-12 06:42:01 +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 s1 2025-06-12 06:42:01 +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