How to Use GitHub Effectively as a Developer

Optimizing Your GitHub Profile

Your GitHub profile is the first place a hiring manager or potential client goes after seeing your resume. Make it count. Add a professional photo, a one-line bio that includes your current stack and goals ("Full-stack developer | React, Node.js, TypeScript"), a link to your portfolio website, and your location. Pin your 6 best repositories at the top — these should be your most impressive, most polished, most documented projects.

Create a GitHub profile README: a special repository named username/username whose README.md appears at the top of your profile. Use it to tell your story as a developer, list your tech stack, and link to your portfolio and writing.

What Makes a Good Repository

Every public repository you have is a potential first impression. A good repo has: a clear, descriptive name (not "project-1" or "test"), a comprehensive README with what the project does, what tech it uses, screenshots or a demo link, and how to run it locally. It should have meaningful commit history (not "initial commit" followed by "final version"), a proper .gitignore file, and environment variables handled via .env files (never committed).

# Example README structure
# Project Name

One sentence describing what this does.

## Live Demo
[View deployed app](https://your-app.netlify.app)

## Screenshot
![App screenshot](./screenshot.png)

## Tech Stack
- React, TypeScript, Tailwind CSS
- Node.js, Express, PostgreSQL
- Deployed on Vercel + Render

## Features
- User authentication with JWT
- Real-time updates with WebSockets
- ...

## Running Locally
\`\`\`bash
git clone ...
npm install
cp .env.example .env  # fill in your values
npm run dev
\`\`\`

Pull Requests and Code Review

Even when working alone, using pull requests is worth the habit — it forces you to review your own changes before merging and documents why specific changes were made. In a team context, PRs are the primary mechanism for code review, knowledge sharing, and maintaining code quality.

A good PR: has a clear title in the format "feat: add user authentication", a description explaining what changed and why, a link to any related issue, and screenshots or a test plan for UI changes. Keep PRs small — under 400 lines of changed code is ideal. Large PRs are harder to review, more likely to conflict, and more likely to be rubber-stamped without careful review.

GitHub Actions: Basic CI/CD

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm ci
      - run: npm test
      - run: npm run lint

This workflow automatically runs your tests and linter on every push and PR. If tests fail, GitHub blocks the merge. This is Continuous Integration — ensuring code quality is verified automatically, not just trusted.