Brown & Brown Financ Group

Version control is the quiet superpower behind every reliable full-stack project. With a clean Git workflow, you collaborate smoothly, ship faster, and avoid “it worked on my machine” surprises. This guide gives you a simple setup, everyday commands, and a lightweight branching strategy you can use on your next React + Node app. Want mentor feedback while you practice? Join project-driven full stack classes in Mumbai or a hands-on full stack developer course in Mumbai.

Why Git matters for full-stack

• Safety net: Revert mistakes without losing work.

• Teamwork: Merge changes without emailing ZIP files.

• Credibility: Clean commit history and PRs impress reviewers and hiring managers.

One-time setup (do this once per machine)

1. Install Git (Windows/Mac/Linux).

2. Set your identity:

   git config --global user.name "Your Name" git config --global user.email "you@example.com"

3. Create an SSH key and add it to GitHub (faster, more secure pushes).

   
   

Project structure (simple full-stack)

/app /client # React (Vite/Next) /server # Node/Express /infra # docker-compose, scripts README.md

Add a root .gitignore that covers node_modules, build folders (dist, .next), env files (.env), and logs.

Lightweight branching strategy (Beginner-friendly)

• main → always deployable.

• dev → integration branch for features.

• feature/* → one branch per task (e.g., feature/login-form).

Flow:

1. Branch from dev:

   git checkout dev git pull git checkout -b feature/login-form

2. Commit small, focused changes.

3. Push and open a Pull Request (PR) into dev.

4. After review and tests pass, merge to dev.

5. When a release is ready, PR from dev → main, tag it, deploy.

Mentors in full stack training in Mumbai can review your PRs and help you keep history clean.

Everyday commands you’ll actually use

# start a repo git init git remote add origin git@github.com:you/app.git # status and staging git status git add . # or add files selectively git commit -m "feat: add login form with validation" # sync and branch git pull --rebase # update current branch cleanly git checkout -b feature/login-form git push -u origin feature/login-form # review & merge (on GitHub via PR) # after merge, clean up: git checkout dev git pull git branch -d feature/login-form git push origin --delete feature/login-form

Tip: Prefer git pull --rebase to keep a linear history that’s easy to read.

Good commit messages (copy these prefixes)

• feat: new user-visible feature

• fix: bug fix

• docs: README or comments

• refactor: code restructure (no behavior change)

• test: add/modify tests

• chore: tooling, config, deps

Example:feat(auth): add JWT login with refresh token rotation

Handling client + server changes safely

1. Commit front end and back end separately when possible:

   • feat(client): add login form state & API calls

   • feat(server): add /login route with validation

2. Keep shared contracts (types, response shapes) documented in README.md or /docs/api.md.

3. If you change an API, update the client in the same PR or add a migration note.

Feature flags & envs (prevent breaking prod)

• Use .env files (.env.development, .env.production).

• Commit .env.example (no secrets) so others can run the app.

• Guard unfinished features behind flags:

  const enableNewDashboard = process.env.VITE_NEW_DASHBOARD === 'true';

Simple PR checklist (keeps reviewers happy)

•  Clear title & short description of the change

•  Screenshots or a short Loom/GIF for UI changes

•  Tests updated/added (at least one)

•  README or API docs updated if behavior changed

•  Self-reviewed diff (remove console logs, unused code)

Structured reviews like this are standard in a mentor-guided full stack course in Mumbai.

Resolve conflicts without panic (3 steps)

1. Pull latest dev with rebase on your feature branch:git pull --rebase origin dev

2. Open files marked with conflict markers <<<<<<<, =======, >>>>>>> and choose the correct lines.

3. Mark resolved, continue rebase:

   git add . git rebase --continue

If stuck, git rebase --abort to return to the previous state and try again carefully.

Tags & releases (make deployments traceable)

When dev is stable and merged into main:

git checkout main git pull git tag -a v1.2.0 -m "Auth + Tasks pagination" git push origin v1.2.0

Link the tag to your production deploy for easy rollbacks.

Minimal CI you should enable (GitHub Actions)

• client: install, build, run tests

• server: install, lint, run tests

• Cache dependencies to speed up runs. Show the CI badge in README.

README must-haves (so anyone can run it)

• What the app does (1–2 lines)

• Tech stack (React, Node/Express, Postgres/Mongo)

• Setup commands for client/server

• .env.example and instructions

• API routes (brief) and a live demo link

Final takeaways

• Branch small, commit often, write clear messages.

• Keep main always deployable; integrate via dev.

• Use PRs, CI, and a good README to look professional.

Want real-world practice with code reviews, PR etiquette, and end-to-end project sprints? Enroll in mentor-led full stack course in Mumbai or a practical and get guided from first commit to production deploy.