Open-source project
krishn404/Git-Friend avatar
krishn404/Git-Friend

Git-Friend bundles a README generator, a Git chatbot and a Gitmoji picker

GitFriend is an AI-powered GitHub companion built with React, TypeScript, and Firebase. It helps users resolve Git/GitHub issues through smart AI chat, generates dynamic and professional README files, and adds commit emojis to enhance commit history.

600 stars35 forksTypeScriptMIT

At a glance

What is it?
Git-Friend is a React and TypeScript web application with three features: an AI chat that answers Git and GitHub questions, a README generator with customisable templates, and a browser for Gitmoji commit prefixes. It runs on Next.js with Groq for inference, Firebase for authentication, Convex for persistence, and its GitHub OAuth callback is pinned to a single domain, which is the detail that matters if you plan to self-host it.
Who is it for?
Git-Friend suits an individual contributor or a small team who wants a quick README draft, a place to ask a Git question, and a lookup of commit emoji without leaving the browser, and running it locally for that is a few commands and one file of keys. It is the wrong choice if your repository content cannot be sent to a third party inference service, if you need a multi-user product, or if you intend to self-host it under your own domain without touching the OAuth callback.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 44 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Three small tools sharing one login

Git-Friend is an AI-powered GitHub companion built with React, TypeScript and Firebase. The README describes it as a tool for developers, project managers and beginners, and the feature list is short enough to state plainly.

The AI chat for GitHub help answers questions about Git commands, project setup and general Git and GitHub concepts. The README generator produces customized README files for your repositories with a few clicks, with customizable templates. The Gitmoji support adds expressive emojis to commit messages following the Gitmoji convention, and the flow is to browse emojis by commit type, click one to copy the code, and use it in the commit message.

The current feature list adds the parts that make it an application rather than a set of pages. Google authentication is how you log in, and the login flow is to click Login with Google, complete the Google authentication flow, and land on the dashboard.

The user flows for the other two features are equally explicit. The README generator takes project details such as name, description and tech stack, lets you choose which sections to include, generates the README, lets you preview and adjust it, and then either downloads the file or copies it to the clipboard. Nothing is pushed to your repository for you at this point, which is the subject of a roadmap item further down.

GitHub access is on the roadmap, not in the app

The gap between the feature list and the roadmap is the most useful thing in the README for anyone planning to use this.

Today the app signs you in with a Google account. The AI chat, the README generator and the Gitmoji browser all work from there. But GitHub OAuth integration is listed as an unchecked roadmap item: connecting directly to your GitHub account to access repositories and more. The current feature list has GitHub access as a checkbox to tick, not a box to tick.

So the README generator produces text you copy out, and the app does not read or write your repositories. The roadmap also contains one-click README updates, pushing generated READMEs directly to your repositories without leaving the app, plus enhanced README customization with badges, images and custom sections, custom prompt templates for saving and reusing prompts, a GitHub activity dashboard, and a badge and star history display.

That ordering tells you something about the project's stage. The generator and the chat are the shipped product, and everything that touches your account is the next phase.

For an evaluator, that means the honest description of Git-Friend today is a browser app with three utilities behind a Google login, not an integration with GitHub.

Next.js, Radix, Tailwind, Convex, Firebase and Groq

The tech stack section lists TypeScript, CSS and JavaScript as the languages, React, Next.js, Octokit, Radix UI, Firebase and TailwindCSS as the frameworks and libraries, Node, npm and TypeScript as the development tools, and Groq for AI integration. The package.json confirms and extends it.

The application is a Next.js app. The scripts are the standard ones, next dev, next build, next start and next lint, and the project also carries a vercel.json, along with a Vercel OSS Program badge in the README, so the deployment target is not a secret. The interface is built from Radix UI primitives with TailwindCSS for styling, and components.json at the root is the shadcn-style configuration file. There is a convex/ directory, so Convex is the backend, and the dependency list includes convex along with @upstash/redis and @vercel/analytics.

The GitHub side uses Octokit, and the plugin entries are specific: @octokit/rest with the retry and throttling plugins, which is what you want for anything that talks to the GitHub API from a browser.

One inconsistency is worth noticing for anyone setting the project up. The package.json declares packageManager [email protected], and there is a pnpm-lock.yaml alongside a package-lock.json, while the installation instructions in the README use npm. Either works for a dependency install, but the lockfile you use decides what you actually get, and the README also warns that if you hit dependency errors during installation you should try npm install --legacy-peer-deps, which is a symptom of peer version ranges in a dependency set that spans two package managers' worth of tooling.

Nine environment variables and a pinned callback URL

The environment setup is the part of this project with the most hard requirements, and the .env.example file documents them precisely.

Eight variables describe the Firebase application, the public ones prefixed NEXT_PUBLIC_FIREBASE_API_KEY, NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN, NEXT_PUBLIC_FIREBASE_PROJECT_ID, NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET, NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID and NEXT_PUBLIC_FIREBASE_APP_ID, plus the private FIREBASE_PRIVATE_KEY and FIREBASE_CLIENT_EMAIL. The README lists the same set with example values for the local .env.local file, and adds GITHUB_ACCESS_TOKEN, GROQ_API_KEY, UPSTASH_REDIS_REST_TOKEN and UPSTASH_REDIS_REST_URL.

The NEXT_PUBLIC_ prefix means those values are compiled into the client bundle and visible to anyone who loads the page. That is how Firebase web configuration normally works, and Firebase client keys are not secrets in the usual sense, but it is worth being clear that the private key and client email must never carry the prefix.

The line in .env.example that matters most for self-hosting is the comment at the top. The GitHub OAuth callback is intentionally fixed to https://gitfriend.xyz/api/auth/github/callback in lib/github-oauth.ts, and NEXT_PUBLIC_APP_URL is the canonical public origin. That is a deliberate design choice for a hosted product, and it means a fork running on localhost or on your own domain will not complete the GitHub OAuth flow without editing that file.

The Groq model can be overridden through GROQ_CHAT_MODEL and GROQ_SUGGESTIONS_MODEL, with the defaults in the routes being llama-3.1-8b-instant. Convex persistence is optional, enabled by setting NEXT_PUBLIC_CONVEX_URL, and the Firebase project id has to be repeated in the Convex deployment settings so it can validate Firebase ID tokens.

Running it locally in four commands

The prerequisites are Node.js version 16 or later, npm version 8 or later, a Google account for authentication, and the API keys. The installation sequence is short.

Clone the repository and move into it:

bash
git clone https://github.com/krishn404/Git-Friend.git
cd Git-Friend

Then install the dependencies:

bash
npm install

If the install fails on dependency errors, the README points at the same install command with the --legacy-peer-deps flag, which skips the peer version checks.

Next, create a .env.local file at the root of the project and fill in the Firebase configuration and the other keys, and then start the development server:

bash
npm run dev

The app is then reachable at http://localhost:3000.

The steps in the README are numbered as a checklist, with the environment variables as step 4 and the dev server as step 5, and the ordering matters: without the Firebase keys the sign in button will not complete, and without a Groq key the chat has no model behind it. Both failures show up as an empty or broken page rather than as a clear configuration error, so filling in .env.local before the first run saves time.

Who the README says it is for

The use cases section names four audiences, and each one implies a different bar for the tool.

For open source contributors, Git-Friend is a way to quickly generate professional READMEs for projects, making them more accessible to potential contributors. For team leads, it is a way to maintain consistency across a team's repositories using standardized README templates and commit message practices with Gitmoji. For GitHub beginners, the AI chat is the way to get assistance with Git commands and best practices. For documentation teams, it is a way to streamline creating and updating documentation with AI-powered generation and formatting.

The team lead case is the most demanding of the four, and it is the one where the roadmap gaps bite. Consistency across a team requires that the generated output actually lands in the repository, which is the one-click README update that is still a checkbox, and it requires a shared template set, which is the custom prompt templates item. Until those land, consistency depends on someone copying the output into each repository by hand.

The beginner case is the one the app is best suited to today, since a chat that answers a Git question and a page that lists gitmoji codes are both self-contained, and neither touches an account.

Licence, hosting and the maintenance picture

The licence is MIT, which means the code can be used, modified and redistributed with attribution and no other obligation, and the repository carries a LICENSE file at the root. For a project whose value is mostly in its interface and its wiring rather than in a hard problem, a permissive licence makes forking a realistic path.

The project is deployed on Vercel, indicated by the Vercel OSS Program badge and the vercel.json file, and the canonical production origin is gitfriend.xyz. The npm package is marked private with version 0.1.0, which tells you the version field is not tracking anything meaningful and that there is no published package to install.

There are no GitHub releases, and the last push was on 2026-09-09 with the repository not archived. The README carries a status badge marked active and a badge inviting pull requests, so the maintainer is signalling that contributions are welcome, and the CONTRIBUTING section is present in the README, though the file it points at is not part of this listing.

One more thing worth noting for anyone running their own instance. The README notes that the app is a hosted product with Google authentication and an AI service in the middle, and the environment configuration shows a Groq API key and an Upstash Redis REST token, which means the app is designed around third-party services with your keys in them. That is a reasonable trade for a hosted tool and a much larger decision if you intend to run it for a team, and it is the reason to read the configuration before you deploy it rather than after.

Editorial conclusion

Git-Friend suits an individual contributor or a small team who wants a quick README draft, a place to ask a Git question, and a lookup of commit emoji without leaving the browser, and running it locally for that is a few commands and one file of keys. It is the wrong choice if your repository content cannot be sent to a third party inference service, if you need a multi-user product, or if you intend to self-host it under your own domain without touching the OAuth callback. Verify first that the callback URL in lib/github-oauth.ts matches the origin you plan to serve from, because the environment file documents it as intentionally fixed, and check which Groq model the chat routes default to before you rely on an answer for anything that matters.

Frequently asked questions

How do I run Git-Friend on my own machine?

Clone the repository with git clone, move into the directory, run npm install, create a .env.local file at the root with the Firebase, GitHub, Groq and Upstash keys, then start the development server with npm run dev. The app is served at http://localhost:3000.

Can Git-Friend push generated READMEs to my GitHub repository?

Not yet. The current flow generates the README, lets you preview it and then download it or copy it to the clipboard. Pushing generated READMEs directly to your repositories is an unchecked item on the project roadmap, along with GitHub OAuth integration.

Which AI model does the Git-Friend chat use?

The routes default to llama-3.1-8b-instant from Groq, and the model can be overridden with the GROQ_CHAT_MODEL and GROQ_SUGGESTIONS_MODEL environment variables, described as optional low-latency overrides.

Why does the GitHub OAuth callback not work on my local machine?

The .env.example file documents the GitHub OAuth callback as intentionally fixed to the production callback URL in lib/github-oauth.ts, with NEXT_PUBLIC_APP_URL pointing at the canonical public origin. Running the app elsewhere means changing that callback in the code.

Official sources

  1. Issues
  2. krishn404/Git-Friend on GitHub
  3. License: MIT
  4. Project website
  5. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/krishn404-git-friend.svg)](https://hysenlabs.com/projects/krishn404-git-friend)

Was this useful?