Git + GitHub Practice: PR, Issue, CI/CD Complete Guide

Git is a version control tool. GitHub is a collaboration platform built on top of Git. Learning Git is just the first step — true team collaboration also requires GitHub PR, Issue, and CI/CD.

Pull Request: The Heart of Code Review

You finished a feature on your branch. How do you get it merged into main? By creating a Pull Request.

A PR is essentially a "merge request." You push your branch and tell the repository maintainer: I made these changes, please review and merge into main if everything looks good.

The PR page shows which files changed and the exact diff. Colleagues can leave comments, point out issues, and suggest changes. You can respond, modify code, and push again — the PR updates automatically.

A typical PR workflow: create a feature branch from main, develop, push the branch, open a PR on GitHub, colleagues review and suggest changes, you revise and push again, merge after approval.

PR titles and descriptions should be clear. The title summarizes what was done; the description lists specific changes, test results, and anything reviewers should note. A good PR description doubles review efficiency. Include screenshots for UI changes, note any breaking changes, and reference related issues.

Essential GitHub Features Beyond PRs

GitHub offers several features that enhance collaboration:

GitHub Discussions: A forum-like feature for Q&A, feature requests, and general conversation. Unlike Issues (which are task-oriented), Discussions are for open-ended conversation. Use them for design proposals, community questions, and announcements.

GitHub Projects: A project management tool integrated directly into GitHub. Create kanban boards, track issues and PRs, and manage sprints without leaving the platform. The automation features can automatically move cards based on PR status and review progress.

GitHub Wiki: A documentation system built into every repository. Use it for detailed project documentation, architecture decisions, and onboarding guides. Wikis have their own Git repository, so you can edit them with the same workflow as code.

GitHub Pages: Free static website hosting directly from your repository. Great for project documentation, personal portfolios, or project landing pages.

Issue: Task Tracking

Issue is GitHub task management system. An Issue can be a bug report, a feature request, or a discussion topic.

When creating an Issue, write a clear title and description. For bug reports, include reproduction steps, expected behavior, and actual behavior. For feature requests, describe the requirement background and acceptance criteria.

Issues can be labeled (bug, feature, help wanted), assigned to people, and linked to PRs. GitHub provides default labels, but customizing labels to match your workflow is highly recommended.

A common workflow: user or tester reports a bug → create Issue → developer claims the Issue → creates a branch → fixes the bug → PR references "Fixes #123" → Issue auto-closes when PR merges.

Issue Templates

GitHub supports issue templates that standardize the information required for bug reports and feature requests. Create templates in the .github/ISSUE_TEMPLATE/ directory. This ensures that every bug report includes reproduction steps, and every feature request includes clear requirements.

GitHub Actions: Automated CI/CD

Running tests, building, and deploying manually on every commit is exhausting. GitHub Actions automates all of this.

Create a .github/workflows/ directory and add a YAML file:

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

This configuration means: on every push or PR, automatically spin up Ubuntu, install Node.js 20, install dependencies, and run tests.

If tests fail, the PR shows a red X and blocks merging. This is the "CI must pass to merge" protection.

More Advanced Actions

Beyond basic CI, you can automate:

• Deployment: Deploy to AWS, Vercel, Netlify, or GitHub Pages on every push to main
• Code quality: Run linters and formatters automatically
• Release management: Auto-generate changelogs and create GitHub releases
• Notifications: Send Slack or Discord notifications for builds and deploys

GitHub's marketplace has thousands of pre-built actions for common tasks, from sending emails to building Docker images.

Branch Protection Configuration

In GitHub repository Settings → Branches, you can add protection rules to main.

Common rules include:

1. Require pull request reviews before merging: Someone must approve before merging. You can also require specific reviewers for certain directories.
2. Require status checks to pass before merging: CI tests must pass.
3. Require branches to be up to date before merging: prevents merge conflicts.
4. Include administrators: even admins must follow the rules.
5. Require signed commits: Ensures commit authenticity.
6. Require linear history: Prevents merge commits on protected branches.

Once these are enabled, nobody can push directly to main. Everyone must go through PR, pass review, and pass CI.

.gitignore and LICENSE

These two files are project essentials.

.gitignore tells Git which file types to skip: node_modules/ (dependencies, too large), .env (secrets), dist/ (build output), *.log (log files).

LICENSE declares what license your code uses. MIT is the most permissive. GPL requires derivative works to also be open source. Apache 2.0 provides additional patent protection. Without a LICENSE, all rights are reserved by default — others cannot legally use your code. Choose a license early to avoid confusion later. Resources like choosealicense.com can help you pick the right license for your project.

README.md

README is your project face. It is the first thing people see when they open your repository.

A good README includes: one-line project description, key features, installation steps, usage examples, contribution guidelines, and license information.

At minimum, include the project description and installation steps. Projects without a README are hard to understand and hard to trust.

Additional badges for CI status, code coverage, and package version add credibility and provide quick status updates to visitors.

GitHub CLI

GitHub provides a command-line tool that lets you manage PRs, Issues, and Actions without opening a browser.

Key commands:

gh pr create                  # create a PR from the command line
gh pr list                    # list open PRs
gh issue create               # create an issue
gh workflow list               # list GitHub Actions workflows
gh repo create                # create a new repository

The GitHub CLI is particularly useful for automation scripts and for developers who prefer working in the terminal.

Wrapping Up

Git + GitHub is the foundation of modern development. Git manages code versions, GitHub manages collaboration, and Actions manages automation. Together they form a complete development workflow.

Go to GitHub right now, create a test repository, and walk through the PR flow, configure Actions, and set up branch protection. One hands-on round is worth ten tutorials.

Start simple: create a repository, push some code, open a PR, and set up a basic CI workflow. Once you're comfortable with the basics, gradually add more sophisticated workflows, branch protection rules, and automation.

If you are working on a team, here is a practical tip that will save you hours of frustration: agree on your Git workflow as a team before you start coding. Decide together on your branching strategy, commit message format, PR review process, and when to squash versus merge. Write these decisions down in your repository's CONTRIBUTING.md file. A team that shares a consistent workflow avoids the chaos of everyone doing things differently, and it makes onboarding new team members dramatically faster. The specific workflow you choose matters less than the fact that everyone follows the same one. Beyond the basics covered in this article, one area that is increasingly important in 2026 is GitHub Copilot and similar AI coding assistants that integrate directly with your repository workflow. While Copilot itself doesn't change how Git works, understanding how AI-generated code fits into your review process — whether you need special guidelines for reviewing machine-generated contributions, or how to handle questions of authorship and originality — is becoming an essential skill for development teams of any size. Consider adding explicit guidance about AI code generation tools to your CONTRIBUTING.md alongside your other workflow agreements. A deeper topic worth exploring on your own is Git hooks, which are scripts that run automatically at specific points in the Git workflow — before a commit, before a push, or after a merge. Git hooks can enforce coding standards, run linting checks, prevent commits to protected branches, and automate a wide variety of routine quality assurance tasks. Setting up a pre-commit hook that runs your linter and formatter locally catches issues before they ever reach your CI pipeline, saving both time and compute resources while giving developers faster feedback on their code.

The true power of the Git plus GitHub combination lies not in version control alone but in the automated workflows and collaborative processes that surround that control.

Git hooks are one of the most powerful yet underutilized features for teams working on shared repositories. A pre-commit hook can lint code, run unit tests, or scan for accidentally committed secrets before a commit is even recorded. A pre-push hook can run the full test suite, preventing broken code from reaching the remote. Tools like Husky and pre-commit make hook management painless by storing hook configurations in the repository itself, so every team member gets the same checks without manual setup. Beyond quality gates, hooks can enforce commit message conventions automatically rather than relying on developer discipline. Teams that adopt hooks consistently report fewer integration issues and cleaner pull request histories. The upfront configuration time pays for itself within the first week of use in any active development project.