"DevLog: An AI Git Workflow That Keeps Your Code Local"

Harsh Vardhan Pandey — Sun, 04 Oct 2026 08:29:40 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built DevLog, a local-first AI Git workflow for my developer friend who wanted AI assistance for everyday Git work without sending private source code and Git diffs to a cloud AI provider.

Developers commit frequently, but writing clear commit messages and pull-request descriptions can become repetitive and interrupt the development flow.

The obvious solution is to send the Git diff to an AI API.

But that raises a question:

Do I really need to send my source code to a cloud service just to generate a commit message?

DevLog takes a different approach.

It runs AI locally using Ollama and an open-weight model, reads the staged Git diff on the developer's machine, generates a commit message or PR description locally, lets the developer review the result, and then optionally publishes the changes to GitHub.

The AI generation itself does not require a cloud AI API.

The Core Idea

Git Repository
      │
      ▼
Staged Git Diff
      │
      ▼
DevLog
      │
      ▼
Local Ollama
      │
      ▼
Open-Weight LLM
      │
      ├──► Commit Message
      │
      └──► PR Description
      │
      ▼
Developer Reviews
      │
      ▼
Commit / Push / Create PR

The goal is simple:

AI assistance without giving up control of the code being analyzed.

Demo

🌐 Live Demo: https://devlog-fawn-omega.vercel.app/

The live deployment lets you explore the DevLog interface and understand the workflow.

The complete local AI workflow is designed to run on the developer's own machine with Ollama.

What DevLog Can Do

View repository status
Inspect staged Git diffs
Generate AI-powered commit messages
Generate AI-powered PR descriptions
Review and edit generated content
Commit staged changes
Push branches
Create GitHub pull requests
View repository activity and statistics
Run AI inference locally

Local AI Demo

For the actual AI inference, DevLog connects to Ollama running locally:

Developer Machine

Git Repository
      │
      ▼
   DevLog
      │
      ▼
   Ollama
      │
      ▼
 Local LLM

Once the model is downloaded, AI generation can work without an internet connection.

GitHub operations still require internet access when the developer explicitly chooses to push code or create a pull request.

Code

GitHub Repository: https://github.com/Harsh63870/Devlog

The repository contains:

React frontend
FastAPI backend
Ollama integration
Git operations
GitHub integration
Docker Compose setup
Local configuration
API endpoints
Deployment documentation

The project is released under the MIT License.

How I Built It

DevLog is split into a frontend, backend, local AI layer, Git integration, and optional GitHub integration.

Technology Stack

Frontend

React 19
TypeScript
Vite
Tailwind CSS
TanStack Query
Zustand
Three.js / React Three Fiber
Framer Motion

Backend

Python 3.12+
FastAPI
Pydantic
Uvicorn
Ollama SDK

Ollama
Open-weight local LLM
Mistral as the current model

Infrastructure

Docker
Docker Compose
Nginx
Kubernetes-ready deployment configuration

Developer Tools

Git
GitHub REST API
Conventional Commits

The AI Workflow

The workflow starts with a normal Git operation:

git add src/features/new-feature.ts

DevLog then reads the staged diff locally.

The backend passes the diff to the locally running Ollama model.

The model generates a commit message or PR description.

The developer reviews the output before anything is committed or published.

For example:

Git Diff
   │
   ▼
FastAPI
   │
   ▼
Ollama
   │
   ▼
Mistral
   │
   ▼
feat: add user authentication module

The generated output is only a suggestion. The developer remains in control and can edit it before committing.

Commit Generation

The developer can open the Commit workflow and ask DevLog to generate a conventional commit message based on the staged changes.

Example:

feat: add user authentication module

PR Generation

The same staged changes can be used to generate a pull-request title and description.

The developer can review the generated content and then choose whether to publish the branch and create the PR on GitHub.

Why Does Open Innovation Matter?

This is the central design decision behind DevLog.

I could have built the same product around a closed AI API.

That would have been straightforward.

But doing so would mean sending source code and Git diffs to an external AI inference service.

For developers working with private repositories, proprietary software, client code, or unreleased features, that can be an important privacy consideration.

DevLog instead uses an open-weight model running locally through Ollama.

🔒 Privacy

The staged Git diff used for AI generation stays on the developer's machine.

The application does not need to send the source code to OpenAI, Anthropic, or another cloud LLM provider to generate the commit message or PR description.

This reduces the amount of sensitive development data that needs to leave the developer's environment.

🌐 Offline AI

Once Ollama and the selected model are installed, AI generation can work without an internet connection.

Internet OFF

Git Diff
   ↓
DevLog
   ↓
Ollama
   ↓
Local Model
   ↓
Generated Commit

GitHub operations are different: pushing code and creating pull requests naturally require network access.

💰 No Per-Request AI API Cost

DevLog does not depend on a paid cloud LLM API for its AI generation.

The model runs on the user's own hardware.

That means there is no recurring per-request inference charge from an external AI provider.

The trade-off is that the user provides the CPU/GPU, memory, storage, and electricity required for local inference.

🔧 Model Freedom

The AI layer is not fundamentally tied to one proprietary provider.

Ollama allows users to run different supported local models.

This makes the AI layer replaceable:

             DevLog
                │
                ▼
             Ollama
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
    Mistral    Llama    Other

The application can evolve as local models improve without requiring the entire product to be redesigned around a single cloud provider.

🧩 More Control

Open-weight models give developers more control over where inference happens and which model powers their workflow.

For DevLog, this matters because the AI is working directly with developer data.

The model isn't simply a remote service hidden behind an API.

It can become part of the developer's own environment.

Building for a Friend

I wanted DevLog to solve a real developer workflow problem rather than become another generic AI chatbot.

I built it for Ritik Ahirwar, who wanted AI assistance for Git workflows but had concerns about sending private code and diffs to external AI services.

The problem is small, but it occurs repeatedly:

Write Code
   ↓
Make Changes
   ↓
Stage Changes
   ↓
Need Commit Message
   ↓
Need PR Description
   ↓
More Repetitive Work

DevLog turns that into:

Write Code
   ↓
Stage Changes
   ↓
DevLog
   ↓
Local AI Understands Diff
   ↓
Commit / PR Generated
   ↓
Review
   ↓
Publish

The goal isn't to replace the developer.

It's to remove repetitive Git-writing work while keeping the developer in control of the final result.

What I Wanted My Friend to Get

The project was designed around three simple requirements:

AI assistance
Keep source code local
Avoid unnecessary cloud AI costs

That combination is what led to the local-first architecture.

Friend Feedback

His feedback helped me understand which parts of the workflow were genuinely useful and which parts could be improved.

For example, you could describe:

What they tried
What part they found useful
What confused them
What they wanted changed
Whether they would actually use it in their workflow

I prefer documenting the real reaction rather than inventing a polished success story.

Security & Privacy

DevLog follows a local-first architecture for AI processing.

What Stays Local

Git diffs used for AI generation
Local repository information
AI inference
Ollama model
Local DevLog configuration
GitHub token storage

What Touches GitHub

GitHub is only involved when the developer explicitly performs publishing operations such as:

Push a branch
Create a pull request

The AI generation step does not require sending the Git diff to a cloud LLM.

GitHub Token

DevLog supports fine-grained GitHub personal access tokens.

The token is stored locally and should be restricted to the repositories and permissions actually required.

Developers should also avoid committing .env files or local configuration containing credentials.

Important Security Boundary

Running AI locally does not automatically make an application secure.

DevLog therefore treats the local machine as the primary trust boundary and avoids sending the source code used for AI generation to a third-party LLM API.

If Ollama itself is exposed over a network, that network configuration should also be secured appropriately.

Architecture

The complete architecture looks like this:

flowchart TD
    A[Developer] --> B[DevLog React UI]

    B --> C[FastAPI Backend]

    C --> D[Local Git Repository]
    D --> E[Staged Git Diff]

    E --> C

    C --> F[Ollama]
    F --> G[Local Open-Weight LLM]

    G --> H[Generated Commit Message]
    G --> I[Generated PR Description]

    H --> B
    I --> B

    B --> J{Developer Review}

    J -->|Commit| K[Local Git Commit]

    J -->|Push / Create PR| L[GitHub API]

    K --> M[Local Repository]
    L --> N[GitHub Repository]

    G -. AI inference stays local .-> O[No Cloud LLM]

Architecture Principles

Local-first AI

The AI inference path is:

Git Diff
   ↓
FastAPI
   ↓
Ollama
   ↓
Local Model

There is no requirement for a cloud LLM API in this path.

Optional Cloud Interaction

The external network boundary is primarily for GitHub publishing:

Local DevLog
     │
     ├── Local AI → No cloud LLM
     │
     └── GitHub API → Only when publishing

No Vendor Lock-in

The application communicates with the local Ollama runtime rather than depending on a proprietary AI API as its core inference layer.

Self-hostable

DevLog can be run directly on a development machine or through Docker Compose.

The repository also contains Kubernetes deployment guidance for users who want to experiment with containerized deployments.

Offline Workflow

One of the things I specifically wanted to demonstrate was that AI-powered developer tooling doesn't necessarily have to mean cloud-dependent developer tooling.

After installing Ollama and downloading the model:

Internet
   OFF
    │
    ▼
┌───────────────────────┐
│      DevLog           │
│                       │
│  Git → FastAPI        │
│          ↓            │
│       Ollama          │
│          ↓            │
│      Local LLM        │
└───────────────────────┘
    │
    ▼
Commit / PR content

The AI generation portion can continue to work locally.

The developer can review and commit locally.

Only actions involving GitHub require network connectivity.

Developer Experience

I wanted the workflow to feel like a developer tool rather than a separate AI chatbot.

The intended flow is:

1. Modify code
       ↓
2. git add
       ↓
3. Open DevLog
       ↓
4. Inspect diff
       ↓
5. Generate commit
       ↓
6. Review / edit
       ↓
7. Commit
       ↓
8. Generate PR
       ↓
9. Push & create PR

This keeps the AI close to the existing Git workflow.

What I Learned

The most interesting part of building DevLog was realizing that local AI changes more than just where the model runs.

With a cloud AI API, the architecture naturally becomes:

Application
     ↓
Cloud API
     ↓
AI Provider
     ↓
Response

With local AI, the architecture becomes:

Application
     ↓
User's Machine
     ↓
Local Model
     ↓
Response

That changes:

Privacy boundaries
Deployment
Cost structure
Offline capabilities
Model selection
Data ownership
Infrastructure requirements

It also made me think more carefully about the difference between:

"AI-powered"

and

"AI that is actually part of the user's environment."

What's Next?

There are several areas I want to explore:

Better model switching from the UI
Support for more Ollama models
Prompt customization
Commit history analysis
Markdown development-log export
Multiple repository support
Better automated test coverage
More efficient inference for lower-end machines
More granular privacy controls
Better handling of very large Git diffs

The long-term idea is to turn DevLog into a local AI layer for everyday Git workflows.

My Agent Session

Optional

If you use DevRelay for this project, you can embed the session here so the judges can see the development process.

I used DevRelay to document the development process behind DevLog, including the implementation, debugging, and iteration of the local AI workflow.

Prize Categories

Open Source / Open Innovation
Hacktoberfest Weekend Challenge: Build for a Friend

Final Thoughts

DevLog started from a small developer workflow problem.

Writing commit messages and PR descriptions is repetitive.

The obvious answer was to connect the application to a cloud AI API.

Instead, I asked a different question:

Why send the code anywhere at all?

Using an open-weight model locally through Ollama made it possible to keep the AI workflow close to the developer's machine.

That gives DevLog a different set of priorities:

Your code.
Your machine.
Your model.
Your decision about what gets published.

For this project, that's why open innovation mattered.

DEV Community: Harsh Vardhan Pandey