What you'll learn

By the end of this you'll know how to use GitHub Copilot completions and Copilot Chat as different tools for different moments, how to review Copilot suggestions before they land in your codebase, how to exclude sensitive files with .copilotignore, and how to set team norms so everyone on the project uses Copilot consistently.

If you've been tab-accepting suggestions without a real review habit, this is the guide that fixes that.

Who this is for

  • You've installed Copilot and you're using it, but you're accepting suggestions too fast and occasionally shipping code you didn't fully read
  • You're a developer or team lead who wants a consistent, safe Copilot workflow that everyone follows
  • You know completions work but you haven't tried Copilot Chat and you're not sure when to use it

You can skip this if you already have a review habit and a .copilotignore in place. Jump to Common mistakes if you're hitting inconsistent suggestions or you've had a Copilot completion introduce a bug.

What is GitHub Copilot?

GitHub Copilot is an AI coding assistant built into VS Code (and other editors) that generates suggestions in two ways: inline completions as you type, and a Copilot Chat panel for conversational code assistance.

Plain English: it watches what you're writing and suggests the next line or the next block. You press Tab to accept. Copilot Chat is more like a conversation — you ask questions, request refactors, or ask it to explain code.

Simple idea: completions are for flow-state coding where you want to write faster. Chat is for when you have a question or want to explore an approach before writing anything.

Prerequisites

  • VS Code with the GitHub Copilot extension installed (or Copilot bundled in your editor)
  • A GitHub account with a Copilot subscription (Individual, Business, or Enterprise)
  • Basic familiarity with VS Code — keyboard shortcuts, the command palette

Key terms

Completion — an inline suggestion Copilot shows as you type. Gray ghost text. Press Tab to accept, Escape to dismiss, Alt+] to cycle through alternatives.

Copilot Chat — the conversational panel (also accessible inline via Ctrl+I). Ask questions, request refactors, explain code. More flexible than completions for anything requiring context and back-and-forth.

.copilotignore — a file in your repo root (same syntax as .gitignore) that tells Copilot not to send matching files as context to the model. Use for files with secrets, credentials, or sensitive logic you don't want in AI context.

Inline chat — a smaller chat experience triggered in-editor (Ctrl+I) for targeted changes to a selection, without switching to the full chat panel.

Ghost text — the gray placeholder text Copilot shows before you accept. It's a suggestion, not inserted code. Tab accepts it, Escape dismisses it — new users sometimes don't realize they haven't committed anything yet, which is actually useful, because it means you can read it in full before deciding.

Setup from zero

Step 1 — Install and configure Copilot

Install the GitHub Copilot extension from the VS Code marketplace. Sign in with your GitHub account. Once connected, ghost text suggestions appear automatically as you type.

A few settings worth adjusting immediately in settings.json:

{
  "github.copilot.enable": {
    "*": true,
    "plaintext": false,
    "markdown": false,
    "scminput": false
  }
}

This disables completions in plain text and markdown files, where they're often more disruptive than helpful. Leave them on for code file types.

Step 2 — Create a .copilotignore file

At the root of your project, create a .copilotignore file. Same syntax as .gitignore. At minimum:

.env
.env.*
*.pem
config/secrets.*
**/credentials.*

This prevents Copilot from sending your environment files, certificates, and credential configs as context with each request. Copilot doesn't need your secrets to suggest code — and you don't want them in the request payload.

You can also add files with proprietary business logic you don't want leaving the codebase, or large auto-generated files that confuse the suggestions rather than improving them.

Step 3 — Open Copilot Chat

Click the Copilot Chat icon in the sidebar or press Ctrl+Alt+I. This opens the chat panel. Try asking it something about the file you're currently editing: "Explain what this file does and what its main dependencies are."

Get comfortable with this mode before you rely on it in production work. Completions and chat serve different purposes — knowing when to reach for one vs the other is the core workflow decision this tutorial is trying to give you.

The mental model

Completions are interruptions. They interrupt your typing to offer a suggestion. Whether to accept is a decision you're making dozens of times per hour. Most developers accept too much — the Tab key is close, the suggestion looks right, you're in flow. The review habit you build here determines whether Copilot speeds you up or introduces subtle inconsistencies at scale.

Chat is deliberate. You switch contexts, ask a question, evaluate the answer. It's slower than accepting a completion, so you naturally apply more scrutiny. Use chat when you're unsure of the approach before you commit to writing it.

The split: completions for execution when you already know what you're doing, chat for exploration when you don't.

Step-by-step

Reading completions critically

When Copilot shows a completion, before pressing Tab:

  1. Read the whole suggestion, not just the first line — ghost text often spans multiple lines
  2. Check the types: does the function signature match what the caller expects?
  3. Check imports: does the suggestion import a library you don't use or don't want?
  4. Check edge cases: does it handle null or undefined input? What happens if the array is empty?

This adds maybe two seconds per accepted completion. If the suggestion doesn't pass all four checks, press Escape and write it yourself, or press Alt+] to see an alternative suggestion.

Using Copilot Chat for targeted refactoring

Select the code you want to change. Press Ctrl+I for inline chat. Type:

Convert this to use async/await. Keep the error handling behavior identical.
Don't rename variables.

The constraint patterns from prompt engineering apply here — "keep the error handling identical" and "don't rename variables" are the guardrails that stop the refactor from introducing changes you didn't ask for.

Working examples

A chat-first workflow before writing code

Before you start a new function, open Copilot Chat and ask:

I want to write a function that debounces an API call in a React component.
What are the main approaches, and which one fits a Next.js App Router project
where the component is a Client Component?

Get the answer. Now write the function — completions will tend to align with the pattern you just discussed because Copilot uses your recent chat history as context. This two-step — explore in chat, execute with completions — tends to produce more consistent output than going straight to completions cold.

// After discussing debounce patterns in chat,
// completions will suggest the hook-based approach you landed on
function useDebounce<T>(value: T, delayMs: number): T {
  // Copilot suggests the rest, shaped by your chat context
}

Little tip: when a Copilot completion picks up on a nearby function and suggests the same pattern, that's usually a good sign. When the suggestion comes out of nowhere and uses a library you haven't imported anywhere in the file, that's your cue to pause and read the rest of it carefully.

Setting team norms in a shared comment

At the top of a complex or sensitive file, some teams add a short comment that steers Copilot's suggestions for that file:

// Team note: This module handles session tokens.
// Do not generate hardcoded token values. All tokens come from the auth service.
// Preferred error type: AuthError from ../errors.

Copilot reads file context — this comment nudges it toward the patterns your team uses and away from patterns you don't want. Particularly useful in files that new team members will edit alongside Copilot and may not know the constraints yet.

Little tip: add a Copilot section to your project's CONTRIBUTING.md — which file types to ignore, how to handle suggestions in sensitive modules, and whether the team reviews Copilot-assisted PRs differently. A one-paragraph section prevents the "I didn't know we didn't do it that way" conversation after the fact.

Patterns / when to use

Use completions for — boilerplate, repetitive patterns you've written before, standard library calls you already know, adding a similar function to a file that already has examples. The more context Copilot has from the surrounding code, the better the completion.

Use Copilot Chat for — understanding an unfamiliar API or library, planning an approach before writing, getting a code explanation, targeted refactors with specific constraints. Anything where you'd benefit from a back-and-forth before committing to the code.

Use inline chat for — a targeted change to a selected block without switching to the full panel. Ctrl+I, write the instruction, review the diff Copilot shows before accepting.

Don't accept completions for — auth logic, token handling, crypto implementations, database queries with user-supplied input. Generate in chat, read every line, then adapt to your actual requirements.

Common mistakes

Tab-accepting without reading the full suggestion — completions often span 5–10 lines. The first line looks right, the third introduces an import you don't want. Read the whole thing before pressing Tab. Ghost text isn't in your file until you accept it — that's the window.

Not having a .copilotignore — Copilot sends your open file context to the model with each completion request. If you have a .env file open in another tab and it's not ignored, it's in the context. Set up the ignore file on day one, not after the first incident.

Using completions when you should use chat — completions are fast but they don't explain themselves. If you're not sure whether an approach is right, ask in chat first. The completion for an approach you've already validated in chat is much safer to accept than a completion for an approach you haven't thought through.

No team agreement on Copilot use — one developer using Copilot heavily and another not at all creates inconsistent error handling, inconsistent code style, and a review process that's unclear about what counts as AI-generated. A short team agreement — even just a paragraph in CONTRIBUTING.md — prevents most of the friction.

Troubleshooting

Suggestions are consistently off for a specific file type — disable Copilot for that file type in settings. The github.copilot.enable object supports per-language overrides. If Markdown completions are breaking your documentation flow, turn them off with "markdown": false.

Copilot is suggesting patterns from a different framework — open files from the framework you're targeting before you start working. Copilot's suggestions are heavily shaped by what's in your currently open tabs. Close tabs from other projects; open a few representative files from your current codebase.

A completion introduced a bug that made it to production — add a checklist item to your PR template: "Does this PR include Copilot-assisted code? If so, has the AI-generated logic been explicitly tested?" One checkbox in your template makes the question visible every time without requiring a separate process.

Team members aren't aware the .copilotignore file exists — Copilot settings aren't surfaced prominently in the VS Code UI. Most developers won't know about ignore files unless someone tells them explicitly. Add it to onboarding docs and CONTRIBUTING.md.

Checklist

  • [ ] GitHub Copilot extension installed and signed in
  • [ ] Copilot disabled for plaintext and markdown in settings.json
  • [ ] .copilotignore created at project root, covering .env, certificates, and credential files
  • [ ] Copilot Chat panel explored — ask at least one question about a file you're working on
  • [ ] Completion review habit established: types, imports, edge cases checked before Tab
  • [ ] Inline chat (Ctrl+I) tried for at least one targeted refactor
  • [ ] Team norms documented in CONTRIBUTING.md
  • [ ] PR review process updated to flag Copilot-assisted code that needs explicit testing

Practice task

Open a project you're actively working on. Create a .copilotignore if you don't have one — start with .env and any certificate or credential files. Spend 30 minutes working normally with Copilot completions, but before each Tab press, read the full suggestion and consciously decide whether it passes the four checks (types, imports, edge cases, correctness). Count how many you reject that you would have previously accepted. Then open Copilot Chat and ask it to explain a function you wrote more than a month ago. Compare its explanation to what you remember about why you wrote it the way you did.

FAQ

Is GitHub Copilot and Copilot Chat the same product?
Same subscription, two interaction modes. Inline completions and chat are both part of GitHub Copilot — you don't need separate accounts or licenses. The chat feature is available as a panel in VS Code and also inline via Ctrl+I.

Can Copilot see my private repository code?
Copilot sends code context (current file and nearby open files) to GitHub's AI infrastructure with each request. The .copilotignore file controls what gets included. Review GitHub's privacy policy for your specific plan — Individual, Business, and Enterprise have different data handling terms and retention policies.

How is Copilot different from Cursor?
Copilot is an extension that adds AI capabilities to your existing editor. Cursor is a VS Code fork with AI built in at the editor level — codebase-aware chat, per-project rules files, and multi-file editing modes that Copilot doesn't replicate. Both are genuinely useful; they serve different workflows. The Cursor guide on Baseline covers where each fits in more detail.

Should Copilot-generated code get a different PR review?
Many teams don't distinguish in their checklist — which means AI-generated logic that wasn't explicitly tested can slip through without anyone realizing it. A single checkbox in your PR template ("AI-assisted code reviewed and explicitly tested?") makes the question visible without requiring a separate review lane.

What to learn next

  • Prompt engineering for code — the constraint patterns and verify loop that make Copilot Chat requests consistently more useful
  • Cursor AI complete guide — the editor-level alternative with per-project rules files, multi-file editing, and deeper codebase context
  • ChatGPT for coding — when to step outside the IDE for structured debugging and detailed code review conversations
  • [Prompt engineering for code](/ai/tutorials/prompt-engineering-for-code)
  • [Cursor AI complete guide](/ai/tutorials/cursor-ai-complete-guide)
  • [How to use ChatGPT for coding](/ai/tutorials/chatgpt-for-coding)

Takeaways

Copilot completions and Copilot Chat are different tools for different moments. Completions speed up execution when you already know what to write; chat is for exploration and targeted refactors when you don't. The review habit — reading completions before accepting, using chat before committing to an unfamiliar approach — is what separates fast-and-safe from fast-and-fragile. And the .copilotignore file is infrastructure, not optional.

If you remember only one thing: read the whole completion before pressing Tab. The first line usually looks right. The third line is where the import you didn't want shows up.