Part 0.5 — Git, GitHub, and Version Control for Teams

You can be a brilliant coder, but if your work isn’t versioned, it’s one rm -rf away from vanishing.
Version control isn’t optional — it’s the spine of collaborative software engineering.
In this post, we’ll build habits around Git and GitHub that scale from solo projects to full-stack teams.

1. Why Version Control Matters

Git tracks every change in your codebase.
It lets you:

• Revert safely when something breaks

• Collaborate across teams

• Review, merge, and deploy code confidently

• Sync with CI/CD pipelines (GitHub Actions, Render, Vercel)

Think of Git as the history + safety net of your code — every line backed by context and accountability.

2. Initialize Your Repository

Once your environment (from Part 0.1) is ready:

# Inside your full-stack root directory
git init
git add .
git commit -m "Initial project setup"

Then create a remote GitHub repository (via web or CLI):

gh repo create fullstack-app --public
git remote add origin https://github.com/<username>/fullstack-app.git
git push -u origin main

That’s your baseline: every commit now lives both locally and in the cloud.

3. Professional Branching Model

A clean branching strategy keeps chaos out of your project.
Here’s a production-proven setup:

Example:

git checkout -b feature/setup-prisma

After finishing, merge back into develop through a Pull Request (PR).

4. Commit Messages that Matter

Treat commits like documentation.
Bad: update stuff
Good:

feat(users): add CreateUser DTO and validation
fix(api): correct CORS header for POST requests
chore(docs): update README with setup steps

Use conventional commits:

<type>(scope): description

Types: feat, fix, chore, docs, test, refactor.

This style keeps your history searchable, automatable, and CI-friendly.

5. Collaborating Through Pull Requests

A Pull Request (PR) is a structured way to propose changes and trigger automated checks.

1. Push your feature branch:

   git push origin feature/setup-prisma

2. Open a PR on GitHub.

3. Request a review — teammates can comment inline.

4. Merge only after passing tests (CI).

5. Delete the branch after merge.

CI tools like GitHub Actions can auto-run Jest or Playwright tests on each PR — we’ll implement that in Part 11.

6. Handling Merge Conflicts

Conflicts happen when two branches edit the same line.
Git highlights them clearly:

<<<<<<< HEAD
const PORT = 3000;
=======
const PORT = process.env.PORT || 4000;
>>>>>>> feature/env-support

Manually choose the correct version, then:

git add .
git commit -m "resolve merge conflict"

Conflict resolution is an everyday skill — embrace it, don’t fear it.

7. Tags and Releases

When you reach a milestone (e.g., a stable backend release), tag it:

git tag -a v1.0.0 -m "Backend ready for deployment"
git push origin v1.0.0

Tags mark immutable history points — ideal for CI/CD pipelines and rollback safety.

8. Using .gitignore and Environment Files

Never commit secrets.
Add .env to your .gitignore:

# .gitignore
node_modules
.env
dist
coverage

If your team needs to share example configurations, commit .env.example with placeholder values.

9. Integrating GitHub Actions (Preview)

Later in Part 11, we’ll write CI/CD pipelines like:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
        with:
          version: 9
      - run: pnpm install
      - run: pnpm test

This ensures every push runs automated tests before merging — production-grade quality control.

10. Practical Git Habits

• Commit early, commit often.

• Never rebase public branches (rewrite only your local history).

• Use git stash to temporarily save uncommitted changes.

• Keep PRs small (≤ 300 lines).

• Delete merged branches to avoid clutter.

11. Summary

Version control isn’t about Git commands — it’s about discipline and communication.
When your team can navigate history, collaborate asynchronously, and integrate CI/CD seamlessly, you’ve achieved professional flow.

Next, in Part 0.6, we’ll set up your project’s structure and mindset — preparing you to dive confidently into React and NestJS development.