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

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

AI

• 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:

1. AI assistance
2. Keep source code local
3. 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.