Your Single-Commit GitHub Repo Is the Loudest Red Flag on Your Resume. Here Is How to Fix It in One Weekend.

A technical recruiter at a Bangalore product company opens your GitHub profile. They click on your pinned repository. They see a green contribution graph populated by a single dark-green square from last week. They scroll down to the commit history. They see one commit: "initial commit" by you, dated yesterday, containing 8,427 lines of code across 34 files. They close the tab. Total engagement time: 12 seconds. The recruiter did not read your README. They did not look at your code. They did not evaluate your architecture. They pattern-matched a single-commit repository against a category of candidates who consistently fail technical interviews, and they moved to the next resume in the queue. Your project might be excellent. The recruiter will never know because your commit history told them not to bother looking.

The Three Dimensions of a Professional Commit History

A Git history that passes recruiter scrutiny has three properties, each of which answers a specific question the recruiter is asking.

Dimension 1: Temporal span. The recruiter asks: "Was this project built over time or assembled at the last minute?" A commit history that spans at least three weeks answers this question affirmatively. The first commit (project scaffolding, initial setup) and the last commit (final polish, README update) should be at least 21 days apart. A history that spans three hours communicates last-minute assembly regardless of what the code looks like. If your project was actually built over three weeks but you only committed at the end, the temporal span is three hours. The recruiter cannot distinguish between "built over three weeks and committed at the end" and "copied yesterday." Both produce a single-commit history with a short temporal span.

Dimension 2: Commit granularity. The recruiter asks: "Does this candidate break work into logical units?" Professional commits are small, focused, and descriptive. A commit that says "feat: add JWT authentication middleware with refresh token rotation" and touches only files related to authentication communicates that the developer understands scope and atomicity. A commit that says "fix" and touches 24 files across the entire codebase communicates the opposite. The ideal commit size is one logical change: one feature, one bug fix, one refactor. Not one file (too granular). Not ten features (too broad). One logical unit of work.

Dimension 3: Commit message quality. The recruiter asks: "Can this candidate communicate technical decisions in writing?" Professional commit messages follow the conventional commits format: type(scope): description. The type is feat, fix, refactor, test, docs, or chore. The scope is the module or component affected. The description is a present-tense, imperative sentence under 72 characters. "feat(auth): add JWT refresh token rotation" is a professional commit message. "update" is a professional liability. The message quality communicates written communication skill, which is one of the most underrated predictors of engineering performance.

How to Retrofit a Commit History This Weekend

If your project is already built and sitting in a single-commit repository, you can retroactively create a professional commit history in one weekend. This is not dishonest if you are reconstructing commits that reflect how you actually built the project. It is dishonest if you are fabricating a contribution history for code you did not write. The distinction is whether each commit represents a real unit of work you performed.

Step 1: Create a new repository (do not overwrite your existing one). Initialize a new Git repo. Do not delete your old one — you want the option to compare.

Step 2: Reconstruct the project chronologically. Start with an empty directory. Make your first commit: the project scaffold (package.json, basic folder structure, README template). Then add one feature at a time, committing after each: set up Express with a hello-world route, add the database connection, create the first database migration, add the user model, add authentication, add the first API endpoint, add input validation, add error handling, add tests for the authentication flow, add the frontend scaffold, add the first React component, etc. Each logical step gets its own commit with a conventional commit message.

Step 3: Use branches for features. Do not commit everything to main. Create a feature branch for each major feature (feat/user-auth, feat/api-endpoints, feat/frontend-components). Commit on the branch. Merge to main with a merge commit (not squash, not rebase — you want the merge commits visible in the history because they show that you understand branching workflows).

Step 4: Spread the commits across time. Git allows you to set the author date and committer date for each commit. Use this to spread your commits across the actual time period you worked on the project. This is not a lie if these dates reflect when you actually did the work. Set the date for each commit to the day you actually wrote that code. The result is a commit history that spans the real development period of your project.