terminal keyboard, software code, coding screen

Photo by Lukas Blazek on Pexels

We’ve all been there: you stare blankly at a pull request description field, type “fixes stuff,” and hit submit, essentially playing digital Russian roulette with your reviewer’s sanity. If you want to stop getting passive-aggressive Slack messages and actually ship code without crying, you need an elite Git and GitHub workflow that keeps your terminal clean, your CI green, and your reviewers happy.

Welcome to Old Lane 17, where we prefer straightforward solutions over enterprise-grade over-engineering. Today, we’re cutting through the bloat and setting up a lean, mean, GitHub-centric development machine.

1. The GitHub CLI (gh): Never Leave the Terminal Again

Why are you context-switching between your terminal and a browser window just to open a pull request? Every time you open Chrome, a kitten loses its whiskers. Let’s use the GitHub CLI to keep our hands on the keyboard where they belong.

First, make sure you have it installed and authenticated:

bash
# Install via Homebrew (macOS/Linux)
brew install gh

# Authenticate with your GitHub account
gh auth login

Now, instead of navigating a clunky web UI to create a PR, write your branch code, push it, and fire off this command:

bash
gh pr create --title "feat: add caffeine-driven error handling" --body "Closes #42. This fixes the null pointer exception by consuming more espresso."

Boom. Done. You’re back to coding before your coffee gets cold.

2. The Anatomy of an Elite Pull Request

A great PR isn’t a novel; it’s a postcard that tells the reviewer what changed, why it changed, and how to test it. Drop this template into your repository as .github/pull_request_template.md so you never have to think about it again:

markdown
## What does this do?
Briefly explain the feature or bug fix. Don't make me read 40 files to guess your intentions.

## Gotchas & Edge Cases
- [ ] Did you handle null/empty states?
- [ ] Are there any weird race conditions?

## How to Test
1. Run `pytest`
2. Hit the `/api/v1/coffee` endpoint and verify a 200 OK.

3. The Classic Gotcha: The “Works on My Machine” Trap

The Scenario: You push your code, the PR looks pristine, but the moment your CI pipeline runs, it bursts into flames with a cryptic red cross. Why? Because you ran Python 3.12 locally, but your server is running 3.8, or you forgot to run your linter.

The Fix: Set up a lightweight GitHub Action to do the crying for you before a human has to review your code.

Create .github/workflows/ci.yml in your repository:

yaml
name: CI

on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Set up Python
      uses: actions/setup-python@v5
      with:
        python-version: '3.11'
        
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pytest flake8
        
    - name: Run linter and tests
      run: |
        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        pytest

4. Branch Protection: Saving You From Yourself

Late-night coding is a pathway to many abilities some consider to be unnatural… like force-pushing to main at 2 AM.

Don’t trust yourself. Go to your repository settings on GitHub, navigate to Branches, add a protection rule for main, and check these boxes:

  • Require a pull request before merging
  • Require status checks to pass before merging (select your CI action here!)
  • Do not allow bypassing the above settings (yes, even for admins—take off the cape, you’re not infallible).

By combining the speed of the GitHub CLI, a structured PR culture, and a ruthless CI pipeline, you’ll spend less time arguing about code style and more time writing features that actually work. Stay clean out there.

Published by the Old Lane Developer Desk.

Disclaimer: This article was generated and formatted with the assistance of Artificial Intelligence.