A recruiter screening applicants for a summer internship, a professor shortlisting students for a college research programme, and a judge walking the floor at Smart India Hackathon all share one constraint: they have almost no time. A recruiter looking at a stack of a hundred resumes typically spends well under a minute deciding whether a candidate is worth a second look. If your resume line says "Built a machine learning project to predict cricket match outcomes" and includes a link, that link is the only place where the claim gets checked. Click it, and one of two things happens. Either there is a repository with a clear README, a working demo, and a commit history that shows the project actually being built over time — or there is a folder called project with one file named final_final_v2.py and no explanation of what it does. The first repository proves the resume line. The second one quietly disproves it, no matter how good the code inside actually is.
This chapter is about closing that gap: turning the code you already write for CBSE AI projects, hackathons, and personal experiments into a portfolio that survives a 30-second read and rewards a five-minute one. GitHub is the tool we will use, because it is free, it is what almost every Indian tech recruiter and college admissions reader already expects to see, and — as you will learn — it keeps an honest, ordered record of your work automatically, without you having to write a diary.
What a Portfolio Actually Has to Prove
A common mistake is treating a portfolio as a gallery — a list of finished, polished things, like a school art exhibition. That is the wrong mental model. A portfolio for a 15-to-17-year-old is not being judged against professional software; nobody expects you to have shipped a production app. It is being read as evidence for three specific, narrower claims:
- You can finish things. Not every project needs to be complete, but at least one or two should have a clear "this works, here is how to run it" state, rather than every repository being an abandoned 20% draft.
- You can explain your own work. A reviewer wants to see that you understand what your code does and why you made the choices you made — not just that you can produce code, which is increasingly easy to generate.
- You improve when you get feedback or hit a wall. This is the one most students miss entirely, because it is invisible unless you deliberately make it visible. It is exactly what commit history is good at showing, which is why the next section spends real time on it.
Notice that none of these three claims is "you have many projects." A profile with three repositories that each prove all three claims is a stronger portfolio than a profile with thirty repositories that prove none of them — a point worth returning to below, because it is the single most common misjudgement students make.
The README: Your Project's First 30 Seconds
When someone opens your repository on GitHub, the file that renders automatically below the code listing is README.md. It is the single highest-leverage file in your entire portfolio, because it is the only thing guaranteed to be read before a decision gets made about whether to look further. A README that answers four questions, in order, does the job:
- What does this do? One or two sentences, in plain language, before any jargon. "Predicts whether the batting team will win a T20 innings, given the current run rate and wickets in hand" beats "An ML-based classification pipeline leveraging feature-engineered cricket telemetry."
- How do I see it work? A link to a live demo if one exists (GitHub Pages hosts static sites for free directly from a repository), or, failing that, a screenshot or a short GIF. A reviewer who has to clone your code and install dependencies just to see what it looks like will usually not bother.
- How is it built? The languages, libraries, and one or two design decisions worth knowing — not a full explanation of every line.
- What is its actual state? Working end to end? A prototype for one feature? Explicitly say so. An honest "Status: core prediction logic works; the web interface is unfinished" is more credible, not less, than silence.
# T20 Win Predictor
Predicts whether the batting team wins a T20 innings, from the
current run rate difference and wickets in hand.
**Live demo:** https://yourname.github.io/t20-win-predictor
**Status:** Core model works and is tested on 100 held-out matches
(78% accuracy). Web interface is a basic form, not yet mobile-friendly.
## How it works
A small logistic-style scoring function combines run-rate difference
and wickets in hand into a single score; positive means the batting
side is favoured. See `classify.py`.
## Run it locally
git clone https://github.com/yourname/t20-win-predictor
cd t20-win-predictor
python classify.py
Notice what this README does not do: it does not claim the project is more finished than it is, and it does not bury the one number that matters (78% accuracy, on a stated test size) in paragraph three. State your best result near the top, with the size of the test set it was measured on — "78% accuracy" and "78% accuracy on 100 held-out matches" are different claims, and reviewers who work with data will notice which one you wrote.
Commits as a Work Log, Not Just Save Points
Every time you run git commit, Git creates a permanent snapshot of your project at that instant, labelled with a message you write, a timestamp, and your name. Each commit also stores a reference to the commit that came directly before it — its parent. Follow those parent links backward from your latest commit and you get a chain running all the way to the very first commit in the repository; when a branch is merged, a commit can have two parents instead of one, which turns the chain into a branching structure called a directed acyclic graph (DAG) — "directed" because each link points one way (child to parent), "acyclic" because following those links can never loop back to a commit you already passed.
Git identifies each commit by a SHA-1 hash — a fixed-length fingerprint computed from the commit's content, author, timestamp, and its parent's hash. Because the parent's hash is baked into the child's hash, changing anything in an old commit changes that commit's hash, which changes every hash built on top of it. This is why a commit history, once pushed and seen by others, is effectively tamper-evident: you cannot quietly edit the past without the change being detectable. The hash space itself (2160 possible values) is so large that two unrelated commits ever landing on the same hash by accident is not something you need to worry about in practice.
What this machinery buys your portfolio is simple: GitHub can reconstruct, in exact order and with real timestamps, the sequence of decisions you made while building something — not just the finished result. That ordered trail is the only place your third claim from earlier ("you improve when you hit a wall") can actually show up. A finished script proves you can produce code. A history of five commits where accuracy visibly climbs, or where a bug gets identified and then fixed, proves you can work.
One detail worth getting exactly right, because it trips people up: git log --oneline lists commits newest first, top to bottom — the most recent commit is the top line, and your very first commit (the one you probably called "first commit" before you knew any better) sits at the very bottom. GitHub's repository page and its "commits" view use this same newest-first order by default, which means anyone browsing your repo sees your most recent, presumably more careful work before anything else. That is good news — you do not need to go back and rewrite an embarrassing early message. But it is not an excuse to stop writing real messages either: a curious reviewer who clicks into the full commit history and scrolls to the bottom will still find that first message sitting there, permanently, exactly as you wrote it.
Worked Example: Making Improvement Visible
Here is the difference between claiming improvement and showing it, traced through actual code. Suppose your CBSE AI project predicts the winner of a T20 innings from ball-by-ball state. Your first commit implements the simplest possible rule and measures it honestly on a held-out set of 100 matches:
# classify.py — commit 1: baseline
# run_rate_diffs, actuals: two lists of length 100, already loaded
# from the test set — one entry per held-out match.
def predict(run_rate_diff):
return "India" if run_rate_diff > 0 else "Opponent"
correct = sum(
predict(rr) == actual
for rr, actual in zip(run_rate_diffs, actuals)
)
accuracy = correct / len(actuals)
print(f"Accuracy: {accuracy:.0%}")
Trace it: run_rate_diffs and actuals are two parallel lists of length 100, one entry per test match. zip pairs them up; the generator expression compares predict(rr) against the true label for each pair and yields True/False; sum over booleans counts the Trues, since Python treats True as 1. If 65 of the 100 predictions match, correct = 65, so accuracy = 65 / 100 = 0.65, and the format spec :.0% multiplies by 100, rounds to zero decimals, and appends a percent sign — printing exactly Accuracy: 65%. Commit message: "Baseline model: 65% accuracy on 100 held-out matches".
On the feature/tune-model branch, you add a second feature (wickets in hand) and weight the two signals instead of using run rate alone:
# classify.py — commit 2: tuned
# same 100-match test set; wickets_in_hand is a third list,
# added alongside run_rate_diffs and actuals from commit 1.
def predict(run_rate_diff, wickets_in_hand):
score = run_rate_diff * 1.4 + wickets_in_hand * 0.3
return "India" if score > 0 else "Opponent"
correct = sum(
predict(rr, wk) == actual
for rr, wk, actual in zip(run_rate_diffs, wickets_in_hand, actuals)
)
accuracy = correct / len(actuals)
print(f"Accuracy: {accuracy:.0%}")
Same trace, now over three parallel lists: if 78 of 100 predictions now match, accuracy = 0.78, printing Accuracy: 78%. Commit message: "Tune hyperparameters + add wickets-in-hand feature: 78% accuracy (+13 pts)". Anyone who reads these two commit messages in sequence — without opening a single file — has just watched your model improve by 13 percentage points and knows exactly which change caused it. That is the "improve when you hit a wall" claim, demonstrated rather than asserted, and it costs you nothing beyond writing an honest one-line message each time you commit.
One Repository, Three Different Readers
The same repository gets read differently depending on who opens it, and knowing the differences changes what you should put where.
A recruiter (for an internship or entry-level role) skims your pinned repositories on your profile page, spends most of their attention on the README's first two lines and whether a live demo link actually works, and checks your commit graph mainly for a heartbeat — repositories with commits spread over weeks look like sustained work; a single commit dated today looks like it was assembled the night before applying.
A college admissions or scholarship reader (increasingly common for CS- and AI-focused programmes and for institutes running project-based shortlisting) cares less about polish and more about your reasoning: they are more likely to actually open your commit history and read messages in order, because the narrative of how you approached a problem is closer to what an admissions essay is trying to establish. A repository with a visible wrong turn followed by a fix, both explained honestly, reads well to this audience precisely because it shows a thinking process — the opposite of what a recruiter skimming for 20 seconds has time to notice.
A hackathon judge — at Smart India Hackathon or a similar event, where judging happens live and fast — wants three things in order: does the demo run right now without you apologising for a missing dependency, does the README state which problem statement or track you targeted, and (if it's a team project) does the commit history show contributions from more than one team member, since judges are specifically watching for one person having done all the work while teammates' names sit unused on the submission.
The practical takeaway is not to build three different repositories. It is to make sure your one README front-loads the live demo and the one-line summary (for the recruiter), keeps your commit messages honest about setbacks rather than squashed into one tidy "final" commit (for the admissions reader), and, for team projects, keeps everyone committing under their own GitHub account rather than one person pasting in everyone else's code (for the judge).
Handling Private, Incomplete, or Abandoned Projects Honestly
Not everything belongs on public display, and pretending otherwise causes two different problems.
The first is an academic integrity problem specific to school assessments. If a CBSE AI practical or a school project is still being graded, or if classmates are still working on the same brief, making your solution public on GitHub while the deadline is still open makes it trivially copyable. Git's repository visibility setting handles this directly: keep the repository private while the assignment is live, and switch it to public only after grading closes, once you actually want it in your portfolio. GitHub's own history feature preserves your commit timestamps through that switch, so you lose nothing by waiting.
The second problem is presentation, for projects that are genuinely unfinished or that you abandoned. Do not delete them and do not silently leave them looking finished when they are not — both destroy information a reviewer could have used. Instead, say so in the README: a one-line "Status: paused — the data-cleaning step works, the model training step does not yet converge" is more useful, and more credible, than either deleting the evidence or letting a reviewer discover the gap themselves by trying to run broken code. An honest incomplete project, clearly labelled, does more for your portfolio than a finished tutorial clone with no original thought in it.
Common Presentation Mistakes
Beyond a missing or thin README, a handful of specific mistakes recur often enough to name directly:
- Committed secrets. API keys, passwords, or access tokens pasted directly into code and pushed to a public repository are visible to anyone, forever, even if you delete them in a later commit — the old commit still contains them. Keep secrets in a separate file listed in
.gitignoreso Git never tracks it. - A dead demo link. A README pointing to a GitHub Pages URL that 404s costs more credibility than having no live demo at all, because it signals the README itself is unmaintained.
- History erased by force-pushing.
git push --forcecan overwrite a repository's history on the remote, replacing a real sequence of commits with a rewritten, tidied-up version. This deletes exactly the evidence-of-process that made your repository worth reading in the first place — use it only on private branches before anyone else has seen the history, never to "clean up" a portfolio piece after the fact. - One giant "final" commit. Writing an entire project locally and pushing it as a single commit produces a repository with no visible process at all — indistinguishable, to a reviewer, from a project you downloaded from somewhere else five minutes ago. Commit as you go, even in small, imperfect steps.
Common Misconception: "More Repositories Means a Stronger Profile"
It is tempting to believe that a GitHub profile with thirty repositories looks more impressive than one with four. In practice, reviewers spend seconds per repository, not minutes, and a profile dominated by forked tutorial repositories with zero original commits — the kind created automatically when you click "Fork" on someone else's course project and never change a line — signals the opposite of what you intended: it suggests you have not built much of your own. A GitHub profile is judged on its strongest three or four repositories, each with a real README, an honest status, and a commit history that shows actual work, not on its total count. If your profile currently has many low-effort forks cluttering it, the single highest-value edit you can make today is not writing new code at all — it is un-pinning those repositories from your profile page and pinning your three best instead.
Practice: Active Recall
- Your GitHub profile has 15 repositories: 12 are forks of tutorial projects with no commits of your own, 3 are original work with real READMEs. Before you put this profile link on an internship application, what specific change should you make, and why does it matter more than adding a 16th repository?
git log --onelineon your very first project still shows the commit message"first commit"at the very bottom of the output. Is this something you need to fix before showing the repository to a recruiter? Explain your answer using how GitHub orders its commit history by default.- You and a partner are building a cricket-prediction project for a CBSE AI practical, and the submission deadline is still two weeks away. What repository visibility setting should you use right now, and at what point should you change it — and why?
- A Smart India Hackathon judge and a college admissions reader open the same team repository. Name one specific thing each of them is likely to check that the other is not.
- Your first commit message is
"stuff". Your second is"Tune hyperparameters + add wickets-in-hand feature: 78% accuracy (+13 pts)."Both might represent the same five lines of code changed. Explain concretely why the second message makes you more credible to a reviewer than the first, using the idea of a commit history as evidence rather than just a save point. - A classmate says force-pushing to rewrite their commit history right before an internship interview will make their profile "look cleaner." What do they lose by doing this, and what would you suggest instead?
Summary
- A portfolio has to prove three narrow things: you finish things, you can explain your own work, and you improve under feedback — not that you have produced a large volume of code.
- The README is read before anything else; open with what the project does, a working demo link if one exists, and an honest statement of the project's current state.
- Every commit is a timestamped, chained snapshot; parent-hash chaining makes history tamper-evident, and branching creates a DAG, which merges reconstruct exactly, in order.
git logand GitHub both show commits newest-first — your latest work is what a browsing reviewer sees first, though your very first commit still sits at the bottom, permanently, for anyone who scrolls that far.- Commit messages that state a measured before/after result (like accuracy climbing from 65% to 78% across two commits) demonstrate improvement instead of merely claiming it.
- Recruiters, admissions readers, and hackathon judges read the same repository differently — front-load the demo and summary, keep messages honest about setbacks, and keep team contributions visible under each person's own account.
- Use private repository visibility while school assessments are still open to avoid enabling copying, and switch to public afterward; label incomplete projects honestly rather than hiding or deleting them.
- Avoid committed secrets, dead demo links, force-pushed history, and single giant "final" commits — and judge your own profile on its strongest few repositories, not its total count.
Think About It
Think about this: How would you explain building a portfolio and github profile: showcase your skills to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.