West Bengal State University Students: Structuring a GitHub Repository for Analytics Internship Work

A good analytics repository lets a stranger understand your question, rerun your steps and see your conclusion within two minutes. Use a fixed folder layout, short and honest commit messages, and a README that opens with the business question and the answer. This guide gives you all three, plus a checklist a recruiter can skim, fitted to a 14-day internship.

Why the repository matters more than the notebook alone

A single notebook uploaded to GitHub often looks like a pile of experiments. Recruiters and mentors reviewing many applications rarely open every cell. They look at the repository’s front page, the file names, the commit history and whether the work seems reproducible. A tidy repository signals that you can handle real analytics work, where other people inherit your files.

In a short internship you will not build something huge. That is fine. A small, clean project with a clear question beats a sprawling one with unexplained files. The structure below is designed so that even a two-week project looks deliberate.

Repository folder layout for an analysis project

Use one repository per project. Keep the layout predictable so readers know where to look.

sales-analysis-internship/
├── README.md
├── requirements.txt
├── .gitignore
├── data/
│   ├── raw/            # original files, never edited
│   ├── interim/        # partly cleaned files
│   └── processed/      # final analysis-ready files
├── notebooks/
│   ├── 01_data_audit.ipynb
│   ├── 02_cleaning.ipynb
│   └── 03_analysis.ipynb
├── src/
│   └── cleaning.py     # reusable functions
├── reports/
│   ├── summary.md
│   └── figures/
└── docs/
    └── data_dictionary.md

What each folder is for

Files that quietly improve trust

• requirements.txt: the libraries and versions used, so others can install the same environment.
• .gitignore: keeps out checkpoints, cache folders, virtual environments and any private data.
• A data dictionary: a short table of columns, types and meanings.
• Exported charts: PNG files in reports/figures so readers can see results without running anything.

Commit message guide for analytics work

Commit history is a diary of your thinking. Use a short verb-first line of around 50 characters, and add a second line only when the reason is not obvious. Commit after each meaningful step, not once at the end of the day.

A simple prefix system

Weak and strong messages side by side

• Weak: “update”, “final”, “final2”, “changes”. These say nothing about what changed.
• Strong: “clean: convert order_date to datetime, flag 37 null values”. Specific, and it records a decision.
• Weak: one commit named “all work” containing everything.
• Strong: five commits across the week, each tied to one step.

Honest history is better than perfect history. If you made an error and fixed it, a “fix:” commit shows you can find and correct problems, which is a real analytics skill.

README template for an analysis project

Copy this into README.md and replace the bracketed parts. Keep it under one screen where you can.

# [Project title: question-style or result-style]

## Business question
[One sentence. Example: Which product categories drive the most repeat purchases?]

## Key finding
[Two or three sentences with the actual numbers and the recommendation.]

## Data
- Source: [name, link or description, and date downloaded]
- Size: [rows x columns]
- Licence or access notes: [public, sample, synthetic]
- Data dictionary: docs/data_dictionary.md

## Method
1. Audited missing values and duplicates
2. Cleaned and standardised fields
3. Explored trends and segments
4. Tested [comparison or metric]
5. Summarised findings in reports/summary.md

## How to reproduce
pip install -r requirements.txt
Open notebooks in order: 01, 02, 03.

## Results
[One or two embedded charts from reports/figures]

## Limitations
[What the data cannot tell you. Assumptions made.]

## Next steps
[What you would do with more time or data.]

## Author
[Your name, LinkedIn or email]

Writing the key finding well

Weak: “I analysed sales data using pandas and made charts.” Stronger: “Repeat customers made up 38% of orders but 52% of revenue in the sample, so a retention offer is likely worth testing.” The second names a number, a meaning and an action. Use your own real figures, never borrowed ones.

Worked illustration: organising a 14-day analytics project

This plan is illustrative. The project, data and numbers are examples, not results from a real run.

Imagine you choose a public retail orders dataset and a question: “Which regions have the highest return rate?” Here is how the repository could grow across 14 days.

A commit history for this project might read: “docs: add project question and README skeleton”, “data: add raw orders file and source”, “clean: standardise region names”, “analysis: calculate return rate by region”, “viz: add bar chart of return rate”, “docs: write limitations”. A reader can follow the story from the log alone.

If you are looking for a structured project to fill this plan, the free two-week online internship from CareerSwami offers 26 tracks, a free offer letter and a free completion certificate after successful completion, and the repository approach here fits its 14-day length.

Two-minute recruiter review checklist

Recruiters scan quickly. Run this checklist on your own repository before you share the link. Each item takes a few seconds to check.

Aim for at least nine ticks. If you fail the first three, fix those before anything else, because many reviewers will not read further.

Data privacy and licensing habits in public repositories

• Never upload personal data such as names, phone numbers or emails from a real organisation.
• Check the licence of any public dataset and mention it in the README.
• Keep passwords, API keys and tokens out of notebooks. If one slips in, revoke it, not just delete the file.
• If the data is large, store a small sample and link to the original source.
• If you worked with data from a company, confirm in writing that you may publish it before you do.

West Bengal State University students: fitting repository work into your college context

West Bengal State University is based in Barasat, North 24 Parganas; its own B.A. Honours Sanskrit draft syllabus is headed with that address. The same document shows a CBCS structure over six semesters and a 10-mark project component inside the internal assessment of at least one course. That is a course-level project, not an internship rule, but it hints at how a well-documented repository can help: a clear README and report make any project easier to present to an examiner or mentor.

A secondary source, a Wikipedia excerpt on Barasat College, indicates the university has affiliated colleges. This is not an official page, so treat it as a hint only. It matters because internship or project rules may be set by the university, by your own college, or by both, and that has not been confirmed here. Syllabus pages for computer science, statistics, data science or management programmes were not verified, so do not assume your department requires or credits a GitHub portfolio.

In practice, keep your repository independent of any assumed rule: build it for recruiters first, and adapt the report if your department asks for a particular format. Use the steps below to find out what your own programme requires.

Verification steps for WBSU students before using internship work as project evidence

1. Ask your department office or internship coordinator, in writing, whether a regulation on internships or project work exists for your programme and which scheme year applies.
2. Ask whether an online internship is acceptable, and whether credit or marks attach to it. Do not assume credit.
3. Check the official university website for the syllabus PDF of your own course and look for project, dissertation or internship wording.
4. If you study at an affiliated college, ask the college office whether the college or the university sets the format and submission rules.
5. Ask what documents are needed: offer letter, completion certificate, report, supervisor signature, or a repository link.
6. Ask your guide whether a public repository is allowed for any work counted for assessment, and keep the reply as an email.

Polishing steps in the last 48 hours

1. Restart the kernel and run every notebook from top to bottom to confirm they work.
2. Read your README as if you had never seen the project. Cut jargon and add missing definitions.
3. Pin the repository on your GitHub profile and add a short description and topics such as data-analysis, pandas and visualisation.
4. Check that links in the README open and that images display.
5. Ask someone outside your field to say what the project found. If they cannot, rewrite the key finding.

Naming conventions that keep files readable

• Use lowercase letters and hyphens or underscores, with no spaces: return_rate_by_region.png.
• Prefix notebooks with numbers so they sort in reading order.
• Put dates in ISO format, 2026-11-13, when a file needs one.
• Name the repository after the question or topic, such as retail-returns-analysis, not project1.

Frequently Asked Questions

Should I upload the raw dataset to GitHub?

Only if the licence allows it and the file is small. Otherwise add a short note in the README on where to download it and place a small sample in data/raw. Never upload confidential or personal data.

Is one notebook enough for a 14-day internship?

It can be, but three short notebooks (audit, cleaning, analysis) are easier to read. What matters most is a README that states the question and the answer so a reviewer does not need to open the notebook first.

How many commits should an internship repository have?

There is no required number. Aim for a handful of meaningful commits across the two weeks, each describing one step. A single commit containing everything hides your process.

Can I use SQL or Excel instead of Python?

Yes. Keep the same structure: raw data note, query or workbook files in a clear folder, a report, and a README. Export SQL queries as .sql files and include screenshots or exported charts of Excel dashboards.

Will a GitHub repository count for credit at West Bengal State University?

That has not been verified for any programme. Ask your department or college in writing whether internship work, online or otherwise, carries marks or credit, and what evidence they accept.

What should I do if my data contains sensitive information?

Do not publish it. Use a public or synthetic dataset instead, or anonymise heavily and get written permission from the data owner. Mention in the README that the data shown is a sample or has been altered.

Does a completion certificate replace a repository?

No. A certificate shows you finished the programme; a repository shows what you can do. Link both on your CV, with the repository front and centre.

How do I show the project to a recruiter?

Share the repository link with one line stating the question and the main finding. Pin it on your profile, and make sure the README can stand alone without your explanation.

Related Data Analytics guides

• The Global University Students: Finding Remote Data Analytics Internships from Arunachal Pradesh
• ICT Mumbai Students: Applying Data Analytics to Lab and Process Data in an Internship
• RKDF University Students: Spotting and Avoiding Fake Data Analytics Internship Offers
• All Data Analytics internship guides