Nilamber-Pitamber University Students: Turning an Internship Backend Project Into a Polished GitHub Repository

To turn an internship backend project into a polished GitHub repository, give it a predictable structure, a clear README, a licence, useful issue labels and a readable commit history, and strip every secret and any company data before anything goes public. You can do all of this in about a day if you plan for it from the start of a 14-day internship rather than leaving it to the last evening.

This guide is written for students of Nilamber-Pitamber University (NPU) and anyone else building a Python backend portfolio. It gives you a full checklist, a sanitising routine, a 14-day timeline, an illustrative example and a short set of verification steps specific to NPU.

What a recruiter or reviewer actually sees in the first minute

A reviewer opening your repository usually looks at four things: the README, the folder layout, the recent commits and whether the project appears to run. They rarely read your code line by line at first. A repository that answers “what is this, how do I run it, and what did this person actually build?” within a minute gets a second look. One that has a default README, a single commit called “final” and a committed .env file does not.

Polish matters more for backend work than for front-end work, because there is nothing visual to show. Your documentation, tests, API description and commit history are the product that people can inspect.

Repository-polish checklist for a Python backend project

Work through this table top to bottom. Each row has a concrete “done” test so you can tick it off honestly.

Sanitising step: removing secrets and company data before you publish

This is the step that cannot be skipped. A repository that leaks a database password or a company’s internal data can harm you and the organisation, and deleting a file in a later commit does not remove it from Git history.

What counts as something you must not publish

• API keys, tokens, database passwords, JWT signing secrets and cloud credentials.
• Any file named .env, plus key files such as *.pem.
• Internal hostnames, private URLs, staging server addresses and admin panel links.
• Customer, employee or user records, even if only a few rows or a screenshot.
• Proprietary code, business rules, pricing logic, internal documents or architecture diagrams that belong to the organisation.
• Names, emails and phone numbers of real people in fixtures, logs or test data.

A sanitising routine you can follow

1. Ask first. If the project was built for an organisation, get written permission (an email is enough) saying what you may publish. If you cannot get it, publish a rebuilt, generic version instead.
2. Search the working tree. Search for words like password, secret, token, key, mongodb://, postgres:// and the company’s name or domain.
3. Search the history. Run a secret scanner (for example gitleaks or trufflehog) across all commits, not just the latest.
4. Revoke anything that ever leaked. If a real key was ever committed, treat it as compromised and rotate it, even if you remove it later.
5. Decide how to clean history. The simplest safe route is to create a brand-new repository from a cleaned copy of the code. Rewriting history with a dedicated tool is possible but easy to get wrong.
6. Replace data with fakes. Generate sample records with a seeding script instead of shipping a real database dump.
7. Move config out. Keep real values in environment variables and commit only .env.example.
8. Clone and test. Clone the cleaned repository into an empty folder and run it from the README alone. Search it once more.

If a fresh start loses your commit history, that is acceptable. A clean, safe repository with a shorter history is better than a rich history that exposes something.

Folder structure that reads well for a Flask, FastAPI or Django API

Exact layout depends on the framework, but this shape works for most small backend projects. It is a suggested layout, not a required standard.

project-name/
  app/
    __init__.py
    main.py
    models.py
    schemas.py
    routes/
    services/
  tests/
  docs/
  scripts/
    seed_sample_data.py
  .env.example
  .gitignore
  LICENSE
  README.md
  requirements.txt

• Keep business logic in services/ so routes stay thin and testable.
• Put the seeding script in scripts/ so reviewers can get working sample data in one command.
• Use docs/ for an API summary or a short architecture note, not for large exports.

README template for a backend project

Copy these headings and fill each one with real content from your project.

1. Title and one-line summary: what the API does and for whom.
2. Features: three to six bullets, written as capabilities (for example “token-based login”, “paginated listing”).
3. Tech stack: language version, framework, database, key libraries.
4. Setup: clone, create a virtual environment, install, copy .env.example to .env, run migrations or seed data.
5. Run: the exact command to start the server and the local address.
6. API examples: two or three sample requests and responses, clearly marked as examples.
7. Tests: the command to run them. Only report a result you have actually seen.
8. Design notes: why you chose a particular structure, schema or approach.
9. Limitations and next steps: what is unfinished. Honesty here builds trust.
10. Licence and acknowledgements: licence name and any credit owed.

Choosing a licence for work done during an internship

A licence tells others what they may do with your code. Common permissive choices are MIT and Apache-2.0; GPL-style licences require derivative work to stay open. Without any licence, the default is that nobody may legally reuse your code, which is fine for a pure portfolio piece but should be a deliberate choice.

The bigger question is whether you own the code. If an organisation assigned the task or supplied requirements, data or code, they may have rights over the result. Ask in writing before choosing a licence. If you rebuilt a generic version using only your own design and fake data, the choice is yours.

Issue labels that make a portfolio repository look maintained

Default labels are noisy. A small, purposeful set shows you think like a maintainer. Create the labels below and open a handful of real issues for the work you did not finish.

Do not create fake activity. Only open issues for work that is genuinely outstanding.

Cleaning up commit history without rewriting what actually happened

Commit history is evidence of how you work. Aim for small, logical commits with messages that say what changed and why.

• Use the imperative style: “Add user registration endpoint”, not “stuff” or “final2”.
• Keep one concern per commit: do not mix a bug fix with a refactor.
• Before publishing a private working repository, you can tidy local commits with an interactive rebase. Do this only on commits you have not shared.
• Never rewrite shared history without telling collaborators.
• If you are starting a fresh repository for sanitising reasons, rebuild a sensible sequence: project skeleton, models, endpoints, auth, tests, docs.

A 14-day plan that bakes in repository polish

The free two-week online internship from CareerSwami runs for 14 days and includes a free offer letter and a free completion certificate after successful completion, with 26 tracks to choose from. Whatever track you take, this timeline keeps your repository publishable at the end.

Illustrative example: polishing a small task-tracker API

This example is illustrative. It is not a real student project and no code or tests were run for it.

Imagine a student builds a task-tracker API in FastAPI over 14 days. At day 12 the repository has these problems:

• A .env file with a database password was committed on day 2 and removed on day 5.
• The README is the auto-generated title only.
• Commits are named “update”, “fix” and “final”.
• A sample.db file contains names and emails copied from a mentor’s demo spreadsheet.

The student applies the checklist:

1. Rotates the database password, because it exists in history.
2. Deletes sample.db and writes seed_sample_data.py that creates fictional users.
3. Asks the mentor by email whether the generic task-tracker can be published, and receives a yes for a version with no organisation data.
4. Creates a new repository from the cleaned folder, with a new sequence of meaningful commits.
5. Writes the README using the ten-heading template and lists “no rate limiting yet” under limitations.
6. Adds an MIT licence, seven labels and three honest open issues.
7. Clones into an empty folder and follows the README to confirm it starts.

The outcome is a smaller but safe repository that a reviewer can run and understand.

Nilamber-Pitamber University: what is and is not confirmed for your internship repository

NPU describes itself as a state university established on 17 January 2009 with headquarters in Medininagar (formerly Daltonganj), Palamu. The same page says postgraduate teaching happens in university departments while undergraduate teaching happens in constituent and affiliated colleges. In practice, that means rules about projects and internships could sit at university level, college level or department level, and it is not verified which applies to you.

The same page lists MCA and BCA among mostly self-financed vocational courses, and the home page carries notices on MBA and MCA admission. If you are in one of those programmes, a backend repository fits naturally as portfolio evidence. However, no official internship, industrial-training or project-work rules were verified, so do not assume an online internship counts toward any requirement, credit or evaluation.

On careers support, the site menu lists a Central Placement Cell and a Training & Placement Cell on the home page, and the Placement Details page shows a 2024 placement drive in the MCA Department. It carries no statistics, so treat it as a single data point rather than a pattern. A polished repository is something you can bring to those offices or to any recruiter, but it does not guarantee any outcome.

Verification steps for NPU students

1. Ask your department office or coordinator, in writing, whether the university or your college sets internship and project-work rules for your programme and batch.
2. Request the current scheme and syllabus document for your course and look for any internship, project or industrial-training component, its duration and its evaluation method.
3. Ask whether an online internship is accepted for any requirement and what documents (offer letter, certificate, report) are needed.
4. Check the Academic Calendar page, which is shown as an image, and confirm dates for breaks with your department before planning your 14 days.
5. Ask the Training & Placement Cell or your department whether they review student portfolios or GitHub links, and in what format.
6. If your project used an organisation’s data or code, get written permission before making the repository public.

Final pre-publish check before you flip the repository to public

• Fresh clone runs from the README with no private files.
• Secret scan of the whole history is clean and any leaked credential has been rotated.
• No real names, emails, records or company identifiers anywhere, including screenshots and logs.
• Licence matches what you are allowed to publish.
• Description, topics and labels are set.
• Your claims in the README match what the code actually does.
• Your CV or LinkedIn link points to the repository, not to a private or empty one.

Frequently Asked Questions

Can I publish the project I built during an internship?

Only if you have the right to. If the work used an organisation’s requirements, data or code, ask for written permission first. If you cannot get it, build a generic version with your own design and fake data and publish that instead.

I committed a password and deleted it later. Is that enough?

No. The password still exists in Git history. Rotate or revoke it immediately, then either start a new repository from a cleaned copy or use a dedicated history-rewriting tool carefully.

Which licence should I choose for a portfolio project?

MIT and Apache-2.0 are common permissive choices. Pick one only after confirming you own the work. If you are unsure about ownership, wait and ask before adding any licence.

Do I need tests for a 14-day project?

Yes, a few. Tests for your main endpoints and core logic show that you verify your work. Report only results you have actually seen when you ran them.

Is it dishonest to start a fresh repository with a new commit history?

Not if you are clear in your README about what the project is and you built the code yourself. Starting fresh is a legitimate way to avoid exposing secrets. Do not pad it with fake commits or invented contributors.

Will a GitHub repository count towards my NPU course requirements?

That is not verified. No official internship or project-work rules for NPU programmes were confirmed, so ask your department in writing whether any external internship or portfolio work is recognised.

Does the CareerSwami internship give a stipend or credit?

The confirmed benefits are a free two-week online internship, a free offer letter and a free completion certificate after successful completion. No stipend, academic credit, placement or job is promised.

How many issues and labels should a small repository have?

Around five to eight labels and two to five genuine open issues is plenty. Quality matters more than quantity, and each issue should describe real unfinished work.