GitHub Copilot 고급 사용자 정의
GitHub Copilot은 모든 것에 적용되는 모놀리식 시스템이 아닙니다. 대신 세 가지 레벨을 제공합니다. 의 맞춤화 어시스턴트의 행동을 조정할 수 있게 해줍니다. 개인, 프로젝트 및 조직의 요구에 맞는 AI. 이해 및 구성 정확하게 이러한 수준은 보다 정확한 제안을 얻고, 소음을 줄이고 팀 생산성을 극대화합니다.
이 문서에서는 구성에서 사용자 정의의 각 수준을 살펴보겠습니다. 직원부터 저장소 지침까지, 조직 정책까지. 우리도 탐구해보겠습니다 와의 통합 모델 컨텍스트 프로토콜(MCP) 및 전략 콘텐츠 제외 민감한 코드를 보호하기 위해.
전체 시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 기초와 사고방식 | 설정과 사고방식 |
| 2 | 개념 및 요구사항 | 아이디어에서 MVP까지 |
| 3 | 백엔드/프런트엔드 아키텍처 | API 및 데이터베이스 |
| 4 | 코드의 구조 | 조직 및 명칭 |
| 5 | 신속한 엔지니어링 | MCP 프롬프트 및 에이전트 |
| 6 | 테스트와 품질' | 단위, 통합, E2E |
| 7 | 선적 서류 비치 | 읽어보기, API 문서, ADR |
| 8 | 배포 및 DevOps | 도커, CI/CD |
| 9 | 진화 | 확장성 및 유지 관리 |
| 10 | 코딩 에이전트 | GitHub 자율 에이전트 |
| 11 | 코드 검토 | 자동 검토 |
| 12 | 부조종사 편집 | 다중 파일 편집 |
| 13 | GitHub 스파크 | 코드가 필요 없는 마이크로 앱 |
| 14 | 부조종사 공간 | 공유 컨텍스트 |
| 15 | AI 모델 | 다중 모델 및 선택 |
| 16 | 현재 위치 → 커스터마이징 | 지침 및 설정 |
| 17 | 기업 및 비즈니스 | 계획, 분석, 정책 |
| 18 | 확장 프로그램 및 마켓플레이스 | 확장 및 통합 |
| 19 | 안전과 책임 있는 사용 | 보안 및 규정 준수 |
세 가지 수준의 사용자 정의
GitHub Copilot은 각각 범위가 있는 세 가지 수준의 사용자 지정 문을 지원합니다. 우선순위도 다릅니다. 여러 레벨이 동시에 활성화되면 지침이 표시됩니다. 정확한 우선순위에 따라 결합됩니다.
명령어 계층
| 수준 | 범위 | 우선 사항' | 관리인 | 유효성' |
|---|---|---|---|---|
| 개인 지침 | 모든 개인적인 대화 | 높음(재정의) | 단일 사용자 | 모든 층 |
| 저장소 지침 | 단일 저장소 | 평균 | 프로젝트 팀 | 모든 층 |
| 조직 지침 | 전체 조직 | 낮음(기본) | 조직 소유자 | 기업 |
조합의 작동 방식
Copilot은 요청을 받으면 사용 가능한 모든 레이어에서 지침을 수집합니다. 단일 컨텍스트로 결합합니다. 충돌이 있는 경우 우선 순위가 높은 명령이 적용됩니다. 승리하다. 예를 들어 조직의 지침에 영어로 응답해야 하는 경우 그러나 개인 지침에는 이탈리아어로 지정되어 있으며 Copilot은 이탈리아어로 응답합니다.
맞춤 지침이 대화의 맥락으로 자동 추가됩니다. 부조종사 채팅으로. 인라인 코드 완성 제안에는 적용되지 않습니다. 하지만 채팅, 상담원 모드, 리뷰의 응답에는 영향을 미칩니다.
개인 지침
개인 지침이 적용됩니다. 모든 대화 당신이 가지고 있는 것 GitHub 웹사이트(github.com)의 Copilot 채팅. 이는 사용자 정의하는 가장 직접적인 방법입니다. 개인 취향에 따른 부조종사 행동.
구성할 수 있는 항목
개인 지침은 모든 항목에 적용되는 기본 설정을 정의하는 데 이상적입니다. 당신이 작업하고 있는 프로젝트. 사용자 정의의 주요 범주는 다음과 같습니다.
개인화 카테고리
| 범주 | Esempio | 효과 |
|---|---|---|
| Lingua | 항상 이탈리아어로 답장하세요. | 모든 답변은 이탈리아어로 제공됩니다. |
| 응답 스타일 | 간결하게 작성하세요(최대 200자). | 짧고 직접적인 답변 |
| 체재 | 항상 언어와 함께 코드 블록을 사용하십시오. | 올바른 형식의 코드 |
| 기술 | 저는 수석 Java 개발자입니다. | 고급 수준 답변 |
| 기술적 선호 | 나는 함수형 프로그래밍을 선호한다 | 기능적인 스타일 팁 |
| 업무 상황 | 저는 Spring Boot 마이크로서비스 작업을 하고 있습니다. | 상황에 맞는 제안 |
개인 지침을 설정하는 방법
GitHub에서 개인 지침을 설정하려면:
- 올라가다 github.com 그리고 로그인
- 오른쪽 상단의 프로필 사진을 클릭하세요
- 선택하다 설정
- 사이드바에서 부조종사
- '개인 안내' 섹션에서 다음을 클릭하세요. 편집하다
- 텍스트 영역에 지침을 작성하세요.
- 딸깍 하는 소리 구하다
효과적인 개인 지침의 예
개인 지침 - 풀스택 개발자
# Profilo Sviluppatore
Sono un senior full-stack developer con 8 anni di esperienza.
Stack principale: Java (Spring Boot), TypeScript (Angular), PostgreSQL.
Lavoro su architetture a microservizi in ambiente cloud (AWS).
# Preferenze Lingua
Rispondi sempre in italiano.
Usa terminologia tecnica in inglese quando appropriato
(es. "dependency injection", "middleware", "endpoint").
# Stile di Risposta
- Sii conciso e vai dritto al punto
- Fornisci sempre esempi di codice quando possibile
- Includi commenti nel codice solo per logica complessa
- Specifica le versioni quando suggerisci dipendenze
- Segnala potenziali problemi di performance o sicurezza
# Convenzioni di Codice
- Java: Google Java Style Guide
- TypeScript: ESLint con configurazione strict
- SQL: uppercase per keywords, lowercase per nomi tabelle
- Naming: camelCase per variabili, PascalCase per classi
- Test: pattern Given-When-Then per test names
# Anti-Pattern da Evitare
- Non suggerire mai codice senza gestione errori
- Non usare "any" in TypeScript
- Non suggerire query SQL con SELECT *
- Non ignorare la validazione degli input개인 지침의 한계
개인 지침이 적용됩니다. 홀로 github.com 대화에 (브라우저의 부조종사 채팅). IDE(VS Code, JetBrains). IDE에서 동작을 사용자 정의하려면 저장소 지침을 사용하십시오. 또는 편집자별 설정.
게다가 개인 지침에는 이와 같이 명시적인 글자 수 제한이 없습니다. 하지만 문맥에 과부하가 걸리지 않도록 간결하게 유지하는 것이 좋습니다. 모델의.
저장소 지침
리포지토리 문은 팀을 위한 가장 강력한 수준의 사용자 정의입니다. 개발의. 저장소 내의 파일을 통해 정의되고 적용됩니다. 해당 프로젝트에 참여하는 모든 팀 구성원에게 자동으로 전달됩니다.
메인 파일: .github/copilot-instructions.md
저장소 지침의 기본 파일은 다음과 같습니다. .github/copilot-instructions.md.
이 파일은 사용자가 상호 작용할 때마다 Copilot에서 자동으로 읽습니다.
저장소. 콘텐츠는 모든 Copilot 대화에 컨텍스트로 추가됩니다.
프로젝트와 관련된 채팅입니다.
.github/copilot-instructions.md - 각도 프로젝트
# Copilot Instructions per TaskFlow Frontend
## Stack Tecnologico
- Framework: Angular 21 con standalone components
- Linguaggio: TypeScript 5.9 strict mode
- Styling: SCSS con BEM methodology
- State Management: Angular Signals
- HTTP: Angular HttpClient con interceptors
- Routing: Angular Router con lazy loading
- Testing: Jasmine + Karma per unit, Cypress per E2E
## Convenzioni di Codice
### Componenti
- Usa SEMPRE standalone components (no NgModules)
- Change detection: OnPush per tutti i componenti
- Usa signals() per stato reattivo, non BehaviorSubject
- Template: file separato (.html) per componenti > 20 righe
- Stili: file separato (.scss) sempre
### Naming Conventions
- Componenti: PascalCase con suffisso Component (es. UserProfileComponent)
- Servizi: PascalCase con suffisso Service (es. AuthService)
- Interfacce: PascalCase con prefisso I (es. IUserProfile)
- File: kebab-case (es. user-profile.component.ts)
- Costanti: UPPER_SNAKE_CASE (es. MAX_RETRY_COUNT)
### Pattern Obbligatori
- Ogni servizio HTTP deve avere error handling centralizzato
- Usare pipe async o toSignal() nel template, mai subscribe manuale
- Route guards come functional guards (non class-based)
- Form: reactive forms con FormBuilder, mai template-driven
- Validazione: custom validators in file separato
### Struttura Directory
```
src/app/
features/ # Feature modules (lazy loaded)
shared/ # Componenti, pipe, direttive condivise
core/ # Servizi singleton, interceptors, guards
models/ # Interfacce e tipi
environments/ # Configurazioni ambiente
```
### Testing
- Ogni componente DEVE avere unit test
- Coverage minima: 80% per servizi, 70% per componenti
- Mock pattern: usa jasmine.createSpyObj per dipendenze
- Naming test: "should [expected behavior] when [condition]"
### Performance
- Lazy load tutte le feature routes
- Usa trackBy per *ngFor (o @for con track)
- Immagini: usa NgOptimizedImage
- Bundle size alert: > 500KB per chunk e' un warning
### Accessibilita'
- Ogni elemento interattivo deve avere aria-label
- Contrasto colori: WCAG AA (4.5:1 minimo)
- Tab navigation deve funzionare per tutti i form
- Screen reader: testare con NVDA o VoiceOver경로별 지침
일반 파일 외에도 Copilot은 특정 경로에 대한 특정 지침을 지원합니다. 저장소의. 이 지침은 다음과 같은 파일에서 작업할 때만 로드됩니다. 지정된 패턴과 일치합니다.
경로별 파일은 디렉터리에 배치되어야 합니다.
.github/instructions/ 확장 기능 포함 .instructions.md.
각 파일에는 적용할 경로를 지정하는 YAML 헤더가 포함되어 있습니다.
.github/instructions/testing.instructions.md
---
applyTo: "**/*.spec.ts"
---
# Istruzioni per File di Test
## Struttura Test
- Usa describe() per raggruppare test per metodo/funzionalità'
- Usa beforeEach() per setup comune
- Pattern AAA: Arrange, Act, Assert in ogni test
## Naming Convention
- describe: nome della classe/funzione sotto test
- it/test: "should [cosa fa] when [condizione]"
## Mock Pattern
```typescript
const mockService = jasmine.createSpyObj('ServiceName', ['method1', 'method2']);
mockService.method1.and.returnValue(of(expectedResult));
```
## Coverage Requirements
- Branch coverage: >= 80%
- Line coverage: >= 85%
- Ogni path condizionale deve avere almeno un test
## Anti-Pattern da Evitare
- Non testare dettagli implementativi
- Non fare mock di tutto (testa integrazione dove possibile)
- Non usare setTimeout() nei test (usa fakeAsync/tick)
- Non ignorare test flaky: fixali o rimuovili
.github/instructions/api-services.instructions.md
---
applyTo: "src/app/core/services/**/*.ts"
---
# Istruzioni per Servizi API
## Pattern Obbligatorio
Ogni servizio API deve seguire questo pattern:
```typescript
@Injectable({ providedIn: 'root' })
export class EntityService {
private readonly apiUrl = `${environment.apiUrl}/entities`;
constructor(private http: HttpClient) {}
getAll(): Observable<Entity[]> {
return this.http.get<Entity[]>(this.apiUrl).pipe(
catchError(this.handleError)
);
}
private handleError(error: HttpErrorResponse): Observable<never> {
// Centralizzato nell'interceptor, qui solo log specifico
console.error(`EntityService error: ${error.message}`);
return throwError(() => error);
}
}
```
## Regole
- Tutti i metodi HTTP devono restituire Observable<T>
- Error handling tramite interceptor globale + log locale
- URL base da environment, mai hardcoded
- Metodi CRUD standard: getAll, getById, create, update, delete
- Usare HttpParams per query parameters
- Cache con shareReplay(1) dove appropriato
.github/instructions/comComponents.instructions.md
---
applyTo: "src/app/features/**/*.component.ts"
---
# Istruzioni per Componenti Feature
## Template Componente Standard
```typescript
@Component({
standalone: true,
selector: 'app-feature-name',
templateUrl: './feature-name.component.html',
styleUrls: ['./feature-name.component.scss'],
changeDetection: ChangeDetectionStrategy.OnPush,
imports: [CommonModule, ReactiveFormsModule]
})
export class FeatureNameComponent {
// Signals per stato locale
readonly items = signal<Item[]>([]);
readonly loading = signal(false);
readonly error = signal<string | null>(null);
// Computed per derivazioni
readonly itemCount = computed(() => this.items().length);
// Inject dependencies
private readonly service = inject(FeatureService);
private readonly destroyRef = inject(DestroyRef);
}
```
## Regole
- OnPush change detection OBBLIGATORIO
- Signals per tutto lo stato locale
- inject() function, non constructor injection
- DestroyRef per cleanup sottoscrizioni
- Template max 50 righe, altrimenti splitta in sub-componentiSpring Boot를 위한 저장소 지침의 전체 예
.github/copilot-instructions.md - 스프링 부트 프로젝트
# Copilot Instructions per TaskFlow Backend
## Stack
- Java 21 con Spring Boot 3.3
- Build: Gradle Kotlin DSL
- Database: PostgreSQL 16 con Flyway migrations
- Cache: Redis 7
- Auth: Spring Security + JWT
- API: REST con OpenAPI 3.1 documentation
- Testing: JUnit 5 + Mockito + Testcontainers
## Architettura
Hexagonal Architecture (Ports and Adapters):
```
src/main/java/com/taskflow/
domain/ # Entità', value objects, eccezioni di dominio
application/ # Use cases, DTO, port interfaces
infrastructure/ # Adapter: DB, HTTP, messaging
config/ # Spring configuration
```
## Convenzioni Java
- Record per DTO immutabili
- Sealed interface per gerarchia tipi controllata
- Optional solo come return type, mai come parametro
- Stream API per operazioni su collection
- Naming: verbo + sostantivo per metodi (es. createOrder, findUserById)
## API Design
- Endpoint: /api/v1/{resource} (plurale)
- Response: wrapper con data, metadata, errors
- Pagination: page, size, sort query params
- Error format: RFC 7807 Problem Details
- Versioning: URL-based (/api/v1/, /api/v2/)
## Database
- Migrations: Flyway con naming V{version}__{description}.sql
- Naming tabelle: snake_case, plurale (es. user_profiles)
- Ogni tabella: id (UUID), created_at, updated_at
- Indici: su tutte le foreign key e campi di ricerca frequente
- NO cascade delete: gestire esplicitamente
## Security
- Input validation su TUTTI gli endpoint
- SQL injection: solo PreparedStatement/JPA
- Rate limiting: 100 req/min per user
- CORS: whitelist esplicita
- Secrets: mai in codice, sempre da environment리포지토리 지침에 대한 모범 사례
- 버전 관리: 리포지토리 지침은 리포지토리에 있는 파일이므로 Git으로 버전이 지정됩니다. 모든 변경 사항은 추적 가능합니다.
- 검토: 명령 변경을 코드 변경처럼 처리하십시오. PR 및 코드 검토를 수행하십시오.
- 간결: 지침이 너무 길면 맥락이 희석될 수 있습니다. 명확하고 구체적인 규칙에 중점을 둡니다.
- 특성': 일반적인 지침은 피하세요. 프레임워크, 버전, 패턴 및 규칙을 구체적으로 설명하세요.
- 업데이트: 팀 규칙이나 프로젝트 종속성이 변경되면 지침을 업데이트하세요.
조직 지침
구성 지침은 구독에만 사용할 수 있습니다. GitHub Copilot Enterprise e 사업. 그들은 허용합니다 조직의 소유자는 모든 구성원에게 적용되는 기본 설정을 정의합니다. 그리고 조직의 모든 저장소에.
구성
조직 지침을 설정하려면 다음을 수행합니다.
- GitHub에서 조직의 페이지로 이동합니다.
- 올라가다 설정 → Copilot → 사용자 정의 지침
- 토글을 통해 기능을 활성화하세요.
- 전용 텍스트 영역에 지침을 작성하세요.
- 변경사항 저장
조직 지침의 특징
| 특성 | 세부 사항 |
|---|---|
| 글자 수 제한 | 최대 4,000자 |
| 버전 관리 | 버전 관리 없음(Git 없음) |
| 시계' | 조직 소유자만 보거나 편집할 수 있습니다. |
| 애플리케이션 | 모든 조직 구성원에 대해 자동 |
| 보수 | 저장소 및 개인 지침에 의해 재정의될 수 있습니다. |
| 유효성' | 기업 및 비즈니스 전용 |
예 - 조직 지침
# Acme Corp - GitHub Copilot Instructions
## Lingua
Rispondi sempre in italiano per il team italiano,
in inglese per tutti gli altri.
## Standard di Sicurezza
- Non suggerire mai codice che espone secrets o credenziali
- Includi sempre input validation negli endpoint
- Usa prepared statements per tutte le query database
- Implementa rate limiting su ogni API pubblica
- Log sensibili: mai loggare PII, token o password
## Convenzioni Codice Aziendali
- Tutti i servizi devono avere interfaccia + implementazione
- Naming: prefisso "Acme" per package base (com.acme.*)
- Documentazione JavaDoc obbligatoria per metodi pubblici
- Commit message: Conventional Commits format
- Branch naming: feature/, bugfix/, hotfix/ + JIRA ticket
## Compliance
- Codice deve essere compatibile GDPR
- Dati utente: sempre criptati a riposo
- Log retention: max 90 giorni
- Audit trail obbligatorio per operazioni CRUD su dati sensibili
## Librerie Approvate
- HTTP Client: OkHttp o Spring WebClient (no Apache HC legacy)
- JSON: Jackson (no Gson)
- Logging: SLF4J + Logback
- Testing: JUnit 5 + AssertJ + Mockito중요 제한: 4,000자
조직 지침의 4,000자 제한은 제한적으로 보일 수 있습니다. 특히 계약이 많은 대규모 조직의 경우. 추천하는 전략은 조직 지침에 규칙만 포함하려면 보편적이고 비판적이다 (보안, 규정 준수, 명명 기반), 프로젝트별 규칙 위임 저장소 지침.
MCP(모델 컨텍스트 프로토콜) 통합
Il 모델 컨텍스트 프로토콜(MCP) 이는 다음을 수행할 수 있는 개방형 표준입니다. Copilot을 외부 도구 및 데이터 소스에 연결합니다. MCP를 통해 Copilot은 다음을 수행할 수 있습니다. 데이터베이스, API, 문서 시스템 등에 액세스하여 확장 그의 능력이 크게 향상되었습니다.
GitHub MCP 레지스트리
GitHub는 MCP 레지스트리 MCP 서버의 카탈로그 역할을 하는 큐레이팅됨 검증되고 안전합니다. 이 레지스트리를 사용하면 서버를 빠르게 검색하고 통합할 수 있습니다. 각 연결을 수동으로 구성할 필요 없이 MCP를 사용할 수 있습니다.
MCP 서버 유형
| 유형 | 수송 | 그것이 변하는 곳 | 사용 사례 | 구성 |
|---|---|---|---|---|
| 원격(HTTP/SSE) | 서버에서 보낸 이벤트가 있는 HTTP | 원격 서버 | 클라우드 API, SaaS, 공유 서비스 | URL + 인증 |
| 로컬(stdio) | 표준 I/O(stdin/stdout) | 로컬 머신 | 로컬 데이터베이스, 파일 시스템, CLI 도구 | 명령 + 인수 |
IDE의 MCP 구성
VS Code에서 MCP 서버를 설정하려면 파일을 생성하거나 편집하세요. .vscode/mcp.json
프로젝트 루트에서. 이 파일은 어떤 MCP 서버를 사용할 수 있는지 정의합니다.
개발 중 부조종사.
.vscode/mcp.json - MCP 구성
{
"servers": {
"github": {
"type": "remote",
"url": "https://api.githubcopilot.com/mcp/github",
"description": "GitHub API access for issues, PRs, repos"
},
"postgres-local": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/taskflow"
],
"description": "Local PostgreSQL database access"
},
"filesystem": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"--root",
"${workspaceFolder}"
],
"description": "File system access for project files"
},
"documentation": {
"type": "remote",
"url": "https://docs-mcp.example.com/v1",
"headers": {
"Authorization": "Bearer ${env:DOCS_API_KEY}"
},
"description": "Internal documentation search"
},
"sentry": {
"type": "remote",
"url": "https://mcp.sentry.io/sse",
"headers": {
"Authorization": "Bearer ${env:SENTRY_AUTH_TOKEN}"
},
"description": "Sentry error tracking integration"
}
}
}MCP 및 코딩 에이전트
MCP 통합은 다음과 결합될 때 특히 강력합니다. 코딩 에이전트 부조종사에 의해. 에이전트는 MCP 도구를 사용하여 정보를 수집하고 쿼리를 실행할 수 있습니다. 자동화된 개발 프로세스 중에 외부 시스템과 상호 작용합니다.
코딩 에이전트를 사용한 MCP 사용 사례
| 대본 | MCP 서버 | 에이전트 작업 |
|---|---|---|
| 문제의 버그 수정 | GitHub + 센트리 | 문제를 읽고, Sentry에서 스택 추적을 검색하고, 코드를 분석하고 수정 사항을 제안합니다. |
| 새로운 기능 | GitHub + 데이터베이스 | 이슈의 요구사항 읽기, DB 스키마 분석, 코드 생성 및 테스트 |
| 선적 서류 비치 | 파일 시스템 + API 문서 | 소스 코드 분석, API 문서 자동 업데이트 |
| 데이터 마이그레이션 | PostgreSQL + 레디스 | 현재 구조 분석, 마이그레이션 스크립트 생성, 무결성 확인 |
| 성능 튜닝 | 프로메테우스 + 데이터베이스 | 지표 수집, 느린 쿼리 식별, 최적화 제안 |
MCP에 대한 엔터프라이즈 정책
기업 및 비즈니스 조직의 경우 정책 "Copilot의 MCP 서버" 조직의 관리자가 명시적으로 활성화해야 합니다. 기본적으로 이 정책은 장애가 있는.
활성화되면 소유자는 액세스할 수 있는 MCP 서버를 제어할 수 있습니다. 조직 구성원에게 승인된 데이터 소스만 사용되도록 보장합니다.
콘텐츠 제외
콘텐츠 제외를 사용하면 처리에서 특정 파일 및 디렉터리를 제외할 수 있습니다. 부조종사에 의해. 이는 민감한 독점 코드를 보호하는 데 필수적입니다. 또는 비밀이나 민감한 구성이 포함된 파일.
콘텐츠 제외 수준
제외 수준 비교
| 수준 | 구성자: | 범위 | 유효성' |
|---|---|---|---|
| 저장소 | 관리 저장소 | 특정 저장소의 파일 | 기업 및 비즈니스 |
| 조직 | 조직 소유자 | 모든 조직 저장소의 파일 | 기업 및 비즈니스 |
| 기업 | 기업 관리자 | 모든 기업 조직의 파일 | 기업 |
제외되는 내용
파일이 제외 대상으로 표시되면 Copilot은 여러 상황에서 해당 파일을 무시합니다.
콘텐츠 제외의 영향
| 기능성' | 제외 효과 |
|---|---|
| 인라인 완성 | 제외된 파일에 대해서는 제안이 생성되지 않습니다. |
| 부조종사 채팅 | 응답에서 컨텍스트로 사용되지 않는 제외된 파일 |
| 코드 검토 | 제외된 파일에 대한 검토 댓글이 없습니다. |
| 부조종사 편집 | 에이전트가 수정할 수 없는 제외된 파일 |
| 코딩 에이전트 | 에이전트는 제외된 파일을 읽거나 수정할 수 없습니다. |
콘텐츠 제외 구성
설정 → Copilot → 콘텐츠 제외
# Formato: un pattern per riga
# Supporta glob patterns
# Escludere file di configurazione sensibili
*.env
*.env.*
config/secrets/**
# Escludere codice legacy non modificabile
legacy/**
vendor/**
# Escludere file generati automaticamente
generated/**
dist/**
node_modules/**
# Escludere file con dati sensibili
**/credentials*
**/private-keys/**
**/*.pem
**/*.key
# Escludere directory specifiche
src/app/proprietary/**
src/internal/billing/**
# Escludere file di test con dati sensibili
test/fixtures/sensitive-data/**콘텐츠 제외의 한계
- 심볼릭 링크: 심볼릭 링크를 통해 연결할 수 있는 파일은 자동으로 제외되지 않습니다. 제외는 파일의 실제 경로를 기반으로 합니다.
- 원격 파일 시스템: 원격 파일 시스템(예: SSH, SFTP)의 파일에는 제외가 작동하지 않습니다.
- 번식: 제외 규칙에 대한 변경 사항이 모든 사용자에게 적용되는 데 최대 30분이 걸릴 수 있습니다.
- 하위 모듈: Git 하위 모듈의 파일에는 하위 모듈 저장소에 대한 별도의 제외 규칙이 필요합니다.
팀을 위한 개인화 전략
세 가지 수준의 개인화를 효과적으로 결합하려면 명확한 전략이 필요합니다. 다양한 규모의 팀에 권장되는 접근 방식은 다음과 같습니다.
소규모 팀(개발자 2~5명)
해야 할 일
- 저장소 지침에 중점을 둡니다.
- 저장소용 copilot-instructions.md 파일
- Istruzioni path-specific per aree critiche
- Personal instructions per preferenze individuali
- Review periodica delle istruzioni (mensile)
Cosa Evitare
- Organization instructions (overkill per piccoli team)
- Istruzioni troppo dettagliate (diminishing returns)
- Duplicazione tra personal e repo instructions
- Regole che non vengono applicate nella pratica
- Aggiornamenti troppo frequenti
Team Medi (5-20 sviluppatori)
Cosa Fare
- Repository instructions dettagliate per ogni progetto
- Path-specific instructions per test, API, modelli
- Organization instructions per standard trasversali
- Content exclusion per codice sensibile
- Review trimestrale con il team
- Template di istruzioni per nuovi repository
Cosa Evitare
- Istruzioni conflittuali tra livelli
- Lasciare istruzioni obsolete
- Ignorare il feedback degli sviluppatori
- Regole troppo rigide che frustrano il team
- Mancanza di ownership sulle istruzioni
Grandi Organizzazioni (20+ sviluppatori)
Cosa Fare
- Organization instructions per policy aziendali
- Template repository instructions per ogni tipo di progetto
- Content exclusion enterprise-wide
- MCP servers centralizzati e approvati
- Processo formale per modifiche alle istruzioni
- Metriche sull'efficacia delle istruzioni
- Onboarding guide per nuovi sviluppatori
Cosa Evitare
- Istruzioni organizzative troppo restrittive
- Bypassare il sistema con personal instructions
- Mancanza di governance sugli MCP servers
- Non monitorare l'adozione delle istruzioni
- Ignorare le esigenze di team specializzati
- Trattenere il valore delle istruzioni: condividile
Esempio Pratico: Setup Completo per un Progetto
Vediamo come configurare la personalizzazione completa per un progetto reale, combinando tutti i livelli.
Struttura File di Personalizzazione
my-project/
.github/
copilot-instructions.md # Istruzioni generali del progetto
instructions/
testing.instructions.md # Regole per file di test
api-controllers.instructions.md # Regole per controller API
database.instructions.md # Regole per query e migrations
components.instructions.md # Regole per componenti UI
.vscode/
mcp.json # Server MCP del progetto
settings.json # Impostazioni VS Code
# A livello organizzazione (UI GitHub):
# - Organization Instructions (4000 char max)
# - Content Exclusion patterns
# - MCP server policy
# A livello personale (Settings GitHub):
# - Personal Instructions
# - Preferenze lingua e stileWorkflow di Manutenzione delle Istruzioni
Processo di Aggiornamento
| Frequenza | Azione | Responsabile | Trigger |
|---|---|---|---|
| Ad hoc | Aggiornare personal instructions | 단일 개발자 | 환경설정 변경 |
| 스프린트용 | 저장소 지침 검토 | 기술 책임자 | 새로운 규칙이 채택되었습니다. |
| 월간 간행물 | 경로별 지침 업데이트 | Team | 개발자 피드백 |
| 계간지 | 조직 지침 검토 | 조직 소유자 + 리드 | 회사 정책 변경 |
| 계간지 | 감사 콘텐츠 제외 | 보안팀 | 보안 검토 |
| 반년마다 | MCP 서버 검토 완료 | 플랫폼팀 | 새로운 도구 사용 가능 |
일반적인 문제 해결
사용자 정의 문제 해결
| 문제 | 가능한 원인 | 해결책 |
|---|---|---|
| Repo 지침이 적용되지 않았습니다. | 파일이 올바른 경로에 있지 않습니다. | 파일이 있는지 확인하십시오. .github/copilot-instructions.md |
| 경로별 지침이 무시됨 | 잘못된 YAML 패턴 | YAML 앞부분에서 applyTo 형식을 확인하세요. |
| 조직 지침이 표시되지 않음 | 기능이 활성화되지 않았습니다. | 설정 → Copilot → 사용자 정의 지침에서 토글을 활성화합니다. |
| MCP 서버가 연결되지 않았습니다 | 정책이 비활성화되었습니다. | 조직 관리자에게 "Copilot의 MCP 서버"를 활성화하도록 요청하세요. |
| 콘텐츠 제외가 작동하지 않습니다. | 전파 진행 중 | 전파가 완료되는 데 최대 30분이 소요됩니다. |
| 지침 간의 충돌 | 모순되는 지시 | 계층 구조를 확인하세요: 개인 > 저장소 > 조직 |
| 지침이 너무 장황함 | 포화된 맥락 | 필수 규칙으로 줄이고 자세한 내용은 경로별 사용 |
개인화 체크리스트
Copilot 사용자 정의 설정 체크리스트
| 영역 | 행동 | 완전한 |
|---|---|---|
| 개인의 | 응답에 대한 기본 언어 정의 | ☐ |
| 경험치 및 스택 지정 | ☐ | |
| 선호하는 응답 스타일 구성 | ☐ | |
| 저장소 | .github/copilot-instructions.md 생성 | ☐ |
| 스택, 규칙 및 패턴 정의 | ☐ | |
| 테스트를 위한 경로별 지침 추가 | ☐ | |
| API에 대한 경로별 지침 추가 | ☐ | |
| 조직 | 조직 지침에 보안 표준 정의 | ☐ |
| 민감한 데이터에 대한 콘텐츠 제외 구성 | ☐ | |
| MCP 서버 정책 활성화 및 구성 | ☐ | |
| MCP | 프로젝트에서 .vscode/mcp.json 구성 | ☐ |
| MCP 서버에 대한 연결 테스트 | ☐ | |
| 팀이 사용할 수 있는 MCP 서버를 문서화합니다. | ☐ | |
| 유지 | 주기적인 검토 프로세스 확립 | ☐ |
| 새 저장소를 위한 템플릿 만들기 | ☐ |
결론
GitHub Copilot 사용자 정의는 빠르게 성과를 거두는 투자입니다. 생산성과 코드 품질. 잘 구성된 지침으로 Copilot을 변화시키다 일반적인 추천자부터 스택, 규칙을 아는 보조자까지 그리고 당신의 팀이 규칙을 정합니다.
성공의 열쇠는 접근 방식이다 증분: 저장소부터 시작하세요 기본 지침을 확인하고 경로별 지침을 추가하여 해당 영역을 식별하세요. 구체적인 지침을 활용하고 팀이 성장함에 따라 조직 지침을 확장하세요. MCP 통합 및 콘텐츠 제외로 그림이 완성되어 Copilot이 강력하고 안전합니다.
다음 기사에서는 옵션을 살펴보겠습니다. 기업 및 비즈니스 부조종사에 의해, 조직의 가격 책정, 분석, 정책 관리 및 ROI에 대한 통찰력을 제공합니다.
시리즈 진행
| # | Articolo | 상태 |
|---|---|---|
| 1 | 기초와 사고방식 | ✅ |
| 2 | 개념 및 요구사항 | ✅ |
| 3 | 백엔드/프런트엔드 아키텍처 | ✅ |
| 4 | 코드의 구조 | ✅ |
| 5 | 신속한 엔지니어링 | ✅ |
| 6 | 테스트와 품질' | ✅ |
| 7 | 선적 서류 비치 | ✅ |
| 8 | 배포 및 DevOps | ✅ |
| 9 | 진화 | ✅ |
| 10 | 코딩 에이전트 | ✅ |
| 11 | 코드 검토 | ✅ |
| 12 | 부조종사 편집 | ✅ |
| 13 | GitHub 스파크 | ✅ |
| 14 | 부조종사 공간 | ✅ |
| 15 | AI 모델 | ✅ |
| 16 | 고급 사용자 정의 | 📍 |
| 17 | 기업 및 비즈니스 | ◻ |
| 18 | 확장 프로그램 및 마켓플레이스 | ◻ |
| 19 | 안전과 책임 있는 사용 | ◻ |