100 days of Git and GitHub: the recap, explained simply

We've reached day 100. Over the past 100 days of Git and GitHub, we've learned that version control isn't just about storing code—it's about shipping with confidence, collaborating without friction, and being able to undo mistakes without panic. This recap distills the lessons that matter most, the ones you'll actually use tomorrow.

Small commits, small PRs — Easier reviews, easier reverts

The single most powerful habit we've built is discipline around commit size. A commit that changes one thing, or a pull request that solves one problem, is dramatically easier to review, understand, and—if something goes wrong—revert.

When we say "small," we mean commits that pass these tests: Does this change do one logical thing? Can someone unfamiliar with the context understand what changed and why in under two minutes? Can the diff be reviewed in a single browser window?

Consider a real-world scenario. Your team ships a feature to add email notifications to a user profile. A bad approach combines it into one giant commit:

git log --oneline
a3f9d2e Add email notifications to profile, refactor auth middleware, update database schema, fix three unrelated bugs

A good approach breaks it into focused commits:

git log --oneline
5e2c1a4 Add email notification UI component
d1b8c7f Create email_notifications database table
c9a3f5e Add email service integration tests
b4e7d2c Update profile controller to send notifications

Why does this matter in production? If your QA team finds the notification feature breaks in staging, you can roll back commit 5e2c1a4 without touching the database changes. If the email service integration has a bug, you can revert c9a3f5e and redeploy in minutes while your team fixes the issue. Smaller commits also mean faster code reviews—reviewers actually read your code instead of skimming 800 lines of changes.

The same principle applies to pull requests. A PR that adds one feature, or fixes one bug, or refactors one module gets reviewed faster and merged faster. We've learned through 100 days that velocity and quality move together when commits and PRs are small.

Know your undo tools — reset, revert, restore and reflog

By day 50 or so, we stopped treating Git as this mysterious system where one wrong command could destroy our work. The truth is simpler: almost nothing is permanently deleted in Git if you know the right tools.

Let's say you've committed work to your feature branch and then realize you committed it to main by mistake:

git log --oneline
a3f9d2e Whoops, committed to main
b1c7e4f Previous main commit
c9a3f5e Feature work that should be on a branch

reset rewrites history on your current branch. It moves the branch pointer backwards and optionally discards or preserves your working changes:

git reset --soft HEAD~1
# Moves main back one commit, keeps your changes staged
git checkout -b feature/my-work
git commit -m "Feature work, properly on a branch"
git push origin feature/my-work

revert is safer for shared branches like main. It creates a new commit that undoes a previous commit without rewriting history:

git revert a3f9d2e
# Creates a new commit that reverses a3f9d2e
git push origin main

restore is your friend when you've modified a file locally and want to discard those changes:

git restore src/components/Button.tsx
# src/components/Button.tsx is now back to its state in HEAD

reflog shows the history of where your HEAD pointer has been. It's the safety net when you think you've lost work:

git reflog
a3f9d2e HEAD@{0}: reset: moving to HEAD~1
b1c7e4f HEAD@{1}: commit: Previous state
c9a3f5e HEAD@{2}: checkout: switching branches

git reset --hard HEAD@{1}
# You're back to where you were before the reset

After 100 days, we know: these tools are not escape hatches for careless work. They're the foundation of confidence. Know them, and Git feels less like a trap and more like a safety system.

Automate the workflow — Actions, protection rules and release tooling

Manual processes don't scale. By day 75, we'd learned that the teams shipping fastest weren't the ones with the most discipline—they were the ones with automation handling the boring decisions.

GitHub Actions runs tests on every pull request, blocks merging if tests fail, and deploys on push to main. This is not optional overhead. It's the foundation:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm install
      - run: npm run lint
      - run: npm test
      - run: npm run build

Branch protection rules enforce that code can only merge after checks pass and after review:

Release automation tags versions, builds artifacts, and publishes them—no manual steps, no human error:

name: Release
on:
  push:
    tags:
      - 'v*'
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm run build
      - uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref_name }}
          release_name: Release ${{ github.ref_name }}

We've learned: every manual decision that can be encoded should be. It's not about removing responsibility—it's about removing friction so your team focuses on decisions that actually matter.

Collaborate well — Clear descriptions, kind reviews and open-source habits

Git is a tool, but collaboration is a human skill. After 100 days, we know this is where the real velocity lives.

A clear PR description tells reviewers what problem you're solving and why. It saves questions in the review thread and unblocks merge decisions:

What: Caches user profile data in Redis for 5 minutes to reduce database load during peak traffic.

Why: Production metrics show 30% of database queries are redundant profile lookups on the same user within that window.

How: Added CacheService wrapper around profile queries. Cache key includes user ID and invalidates on profile update.

Testing: Added cache hit/miss metrics and verified they match expected distribution in staging. Tested cache invalidation with profile updates.

Kind reviews build trust. After 100 days, we know that saying "this approach won't scale" feels different than "have we considered caching here? The profile lookups might hit the database hard under load." Same feedback. Different tone. Different outcome.

Open-source habits—clear commit messages, focused PRs, responsive to feedback—aren't just nice-to-have. They're the language your team speaks. When someone joins from an open-source background, they already know how to collaborate.

We've also learned: be generous with approvals. If the code works, tests pass, and the approach is reasonable, approve it. Don't let perfect be the enemy of good. Reserve detailed feedback for architecture decisions and security concerns. Trust your team.

Common mistakes

Committing directly to main. It happens. Set up local hooks or branch protection to prevent it.

Writing vague commit messages. "Fix stuff" tells the next person (often you, in 6 months) nothing. Spend 30 seconds writing a message that explains the why. Your team will thank you.

Rewriting history on shared branches. git push --force on main is a footgun. Use it only on your own branches. Use revert for shared history.

Merging without tests passing. Yes, sometimes the CI is flaky. Restart it, don't bypass it. The rare false positive is worth the protection against real bugs.

Ignoring code review feedback. If someone asks why you're doing something a certain way, they're not trying to make your day harder. They're trying to understand or suggest a better path. Engage with that feedback, even if you disagree.

Key takeaways

• Small commits and small PRs are the foundation. They enable faster reviews, easier reverts, and clearer history.
• Learn reset, revert, restore, and reflog. These tools turn Git from a source of anxiety into a safety system.
• Automate everything: tests run on every PR, merges are blocked until tests pass, releases happen without manual steps.
• Collaboration is a skill. Write clear descriptions, leave kind reviews, and be generous with approvals for solid code.
• Git's power isn't in the tool itself—it's in the discipline and habits we build around it. The last 100 days have been about those habits.