Skip to content

Commit 598faea

Browse files
committed
add instructions for copilot
1 parent 2cd59d5 commit 598faea

File tree

1 file changed

+40
-0
lines changed

1 file changed

+40
-0
lines changed

.github/copilot-instructions.md

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
# gh-combine GitHub Copilot Guidelines
2+
3+
This is a Go based repository that provide a gh cli extension to combine multiple pull requests into one for a given repository(or multiple repos at once). It is designed to be used with the GitHub CLI and is intended to be a simple and easy to use tool for developers who want to combine multiple pull requests into one.
4+
5+
Here is the the very basic usage of the `gh-combine` extension:
6+
7+
```bash
8+
gh combine owner/repo
9+
```
10+
11+
## Code Standards
12+
13+
### Required Before Each Commit
14+
15+
- Run `make fmt` before committing any changes to ensure proper code formatting
16+
- This will run gofmt on all Go files to maintain consistent style
17+
18+
### Development Flow
19+
20+
- Test: `go test -v -cover ./...`
21+
- Lint: `go fmt ./... && go mod tidy && golangci-lint run --fix`
22+
- Build: `go build -v ./cmd/gh-combine`
23+
24+
## Repository Structure
25+
26+
- `cmd/gh-combine`: Main cli entry points and executables
27+
- `internal/`: Logic related to the core functionality of the extension
28+
- `script/`: Scripts for building, testing, and releasing the extension
29+
- `.github/`: GitHub Actions workflows for CI/CD
30+
- `vendor/`: Vendor directory for Go modules (committed to the repository for reproducibility)
31+
32+
## Key Guidelines
33+
34+
1. Follow Go best practices and idiomatic patterns
35+
2. Maintain existing code structure and organization
36+
3. Use dependency injection patterns where appropriate
37+
4. Write unit tests for new functionality. Use table-driven unit tests when possible.
38+
5. Document public APIs and complex logic. Suggest changes to the `docs/` folder when appropriate
39+
6. When responding to code refactoring suggestions, function suggestions, or other code changes, please keep your responses as concise as possible. We are capable engineers and can understand the code changes without excessive explanation. If you feel that a more detailed explanation is necessary, you can provide it, but keep it concise.
40+
7. If only a small change within a function is needed, please provide just the snippet and ensure there are comments above and below the snippet saying `// start` and `// end`. This will help us understand the context of the change without needing to see the entire function. Before the start, and end comments, please provide a few lines of the context of the function so we know where the change should be made.

0 commit comments

Comments
 (0)