GitGo — One-Command Solution Publisher for VS Code
Stop wasting time documenting solutions. Publish in one command.
GitGo is a VS Code extension that publishes solved coding problems to GitHub using a single command by automating folder creation, README generation, screenshot handling, and Git operations.
Write Code → Run Publish Solution → Done.
Problem
Developers who regularly solve coding problems and maintain GitHub repositories must manually:
- Create problem folders
- Decide naming conventions
- Copy and rename solution files
- Write README files
- Add screenshots
- Run git commands
- Create branches and pull requests
Because this workflow is long and repetitive:
- Repositories become inconsistent
- Folder structures become messy
- Developers stop documenting
- Solutions remain unpublished
Root Cause
Publishing a solution is treated as many independent steps instead of a single atomic operation.
Solution
GitGo converts solution publishing into one atomic pipeline executed by a single command.
Everything required to publish a solution is handled automatically.
No terminal usage.
No manual file handling.
No README writing.
No git commands.
Installation
- Open VS Code
- Go to Extensions (
Ctrl + Shift + X)
- Search GitGo
- Click Install
Usage
- Open a solution file
- Press
Ctrl + Shift + P
- Run GitGo: Publish Solution
- Follow prompts
Your solution is published automatically.
Commands
GitGo exposes the following VS Code commands:
Access commands using:
Ctrl + Shift + P → Type GitGo
Quick Start
- Open your solution file in VS Code
- Press
Ctrl + Shift + P
- Run GitGo: Publish Solution
- Select problem type (LeetCode / Normal)
- If LeetCode:
- Enter difficulty
- Enter execution time
- Choose parent folder
- Enter problem folder name
GitGo will automatically:
- Create the folder
- Copy and rename solution file
- Generate README
- Attach screenshots
- Commit changes
- Push to GitHub or create a Pull Request
First-Time Setup
On first run, GitGo will ask for:
- Repository path
- Author name
- GitHub profile link
- Default push mode
These values are saved and reused automatically.
Requirements
- Git installed
- Git configured with GitHub
- Existing GitHub repository
Target Users
- DSA / LeetCode practitioners
- Interview preparation students
- Developers maintaining solution repositories
Core Design Principle
One Command = One Complete Publish Pipeline
Either everything succeeds or nothing is written.
Architecture
GitGo uses a modular service-based architecture:
- Language detection
- Filename standardization
- Problem type handling
- Metadata prompts
- Folder creation
- File copying
- README generation
- Screenshot handling
- Repository setup
- Default branch detection
- Git automation
- PR description generation
Each module has a single responsibility.
Tech Stack
- TypeScript
- VS Code Extension API
- Node.js
- esbuild
- Git CLI
- Node core modules
Folder Structure Generated
Each published problem produces:
- One solution file
- One README
- One test case screenshot
- One submission screenshot
Structure is consistent across all problems.
Standardized Filenames
Regardless of original filename, solutions are renamed to a consistent format to guarantee uniformity across the repository.
README Generation
LeetCode Problems
Generated README contains:
- Problem name
- Programming language
- Difficulty
- Execution time
- Code explanation
- Concepts used
- Screenshots
- File information
- Author
Normal Problems
Generated README contains:
- Problem name
- Short description
- Files
- Screenshot
- Author
Git Automation
GitGo supports two publishing modes:
Normal Push
Solution is committed and pushed directly to the default branch.
Pull Request Mode
GitGo creates a new branch, commits the solution, pushes it, and generates a pull request.
Default Branch Detection
GitGo automatically detects the repository’s default branch, even if it is not named main or master.
Settings
User configurable:
- Author name
- GitHub URL
- LinkedIn URL
- Default push mode
- Default problem type
- Repository path
Memory Features
GitGo remembers:
- Repository path
- Author details
- Last used parent folder
No repeated setup.
Error Handling
- All operations executed through safe wrappers
- Friendly error messages
- Automatic rollback on failure
- No partial publishes
Security
- No credentials stored
- Uses existing git authentication
Architecture
GitGo follows a layered, pipeline-driven architecture centered around a single atomic publishing workflow.
The system is orchestrated by a Publish Pipeline Orchestrator, which coordinates metadata collection, file preparation, README generation, screenshot handling, and Git operations in a deterministic and transactional sequence.
Unified System Architecture
Architectural Overview
1. Entry Layer
- VS Code Extension Host
GitGo: Publish Solution command- Command registration and activation
2. Application Layer
- Publish Pipeline Orchestrator
- Controls complete execution flow
- Ensures ordered stage execution
- Handles success/failure resolution
- Enforces atomic transaction model
3. Context Building Layer
Builds a single PublishContext object used across all stages.
Includes:
- Problem Type Selector
- Difficulty Prompt
- Execution Time Prompt
- Parent Folder Selector
- Push Mode Selector
- Author Prompt
Output:
PublishContext
- Problem metadata
- Author details
- Push mode
- Repository path
- Language
- File paths
4. Pipeline Stages
Stage 1 — Directory Preparation
- FolderCreator
- FileSystemAdapter
Stage 2 — Solution Preparation
- LanguageDetector
- SolutionFileNameResolver
- FileCopier
Stage 3 — README Generation
- TemplateLoader
- ReadmeGenerator
- LeetCodeTemplate / NormalTemplate
Stage 4 — Screenshot Handling
- ScreenshotHandler
- File normalization and validation
Stage 5 — Git Transaction
- DefaultBranchDetector
- GitService
- PRGenerator
- Git CLI execution
- Push to GitHub
5. Infrastructure Layer
- File system abstraction
- Git automation layer
- VS Code API adapter
- Settings repository (memory persistence)
6. Atomic Execution Model
GitGo enforces:
One Command = One Complete Publish Pipeline
- All stages must succeed
- On failure → automatic rollback
- No partial repository state
- Clear error reporting
Design Principles
- Deterministic pipeline execution
- Strong separation of concerns
- Modular stage-based design
- Infrastructure abstraction
- Zero partial side effects
- Idempotent Git operations
- Persistent configuration memory
Project Status
- Core pipeline complete
- Settings UI complete
- Memory features implemented
- Error guarding implemented
- Ready for Marketplace packaging
Authors
License
MIT License
