J.G. University Students: A Beginner’s Guide to Version Control for AI Internship Code

Version control means saving your AI internship work as a series of small, labelled snapshots with Git, so you can see what changed, undo mistakes and show a reviewer your progress. For a 14-day internship, the essentials are a clean repository layout, a .gitignore that keeps datasets and secrets out, notebooks saved without bulky output, and a consistent commit message format. This guide gives you a cheat sheet for notebooks and data files, a commit convention, and a day-by-day plan.

Why a 14-day AI internship needs Git from day one

A short internship leaves no room for lost work. In two weeks you might load a dataset, clean it, train a baseline model, change features, rerun everything and write a summary. Without version control, this ends up as folders called final_v2_REAL.ipynb and final_v3_fixed.ipynb, and you cannot remember which one produced the numbers in your report.

Git solves three practical problems for AI work:

• Reproducibility: you can point to the exact commit that produced a given accuracy figure.
• Safe experiments: you can try a new model on a branch and discard it if it fails.
• Evidence of your work: a readable history shows a mentor or future interviewer how you think, in a way a single final file cannot.

AI projects add two complications that ordinary software tutorials skip: Jupyter notebooks are JSON files that produce messy diffs, and datasets and model files are often too large for a repository. Most of this guide deals with those two issues.

Starting point: a repository layout built for AI projects

Create the repository before you write any code. A simple structure keeps code, data and outputs separate:

ai-internship/
  README.md
  requirements.txt
  .gitignore
  notebooks/
    01_eda.ipynb
    02_baseline_model.ipynb
  src/
    preprocess.py
    train.py
  data/
    README.md        (how to obtain the data; the data itself is NOT committed)
    sample/          (optional tiny sample, a few KB)
  models/            (ignored; saved weights stay local)
  reports/
    summary.md

Two files matter most. The README.md states the problem, how to install requirements and the order in which to run notebooks. The data/README.md says where the dataset comes from, its licence if known, and the exact steps to download it. That second file replaces the dataset in the repository.

A starter .gitignore for notebooks, data and models

# Data and models
data/raw/
data/processed/
*.csv
*.parquet
*.h5
*.pt
*.pkl
*.joblib
models/

# Keep the tiny sample
!data/sample/*.csv

# Notebook and Python noise
.ipynb_checkpoints/
__pycache__/
*.pyc
.venv/
env/

# Secrets
.env
*.key
kaggle.json

Create this file before your first git add. Ignoring a file after it has been committed does not remove it from history, and that is the root of the most common beginner problem described later.

Git cheat sheet for notebooks and data files

Use this table as your working reference. The right-hand column covers the AI-specific points that general Git tutorials leave out.

Keeping Jupyter notebooks Git-friendly

A notebook stores code, text, outputs, images and execution counters in one JSON file. Every rerun changes counters and embedded images, so Git shows a huge diff even when you changed one line. A few habits fix most of this.

1. Strip outputs before committing. Run jupyter nbconvert --clear-output --inplace notebooks/01_eda.ipynb, or install the nbstripout tool as a Git filter so it happens automatically. If a reviewer needs to see charts, save key figures into reports/ as image files and link them in the README.
2. Run top to bottom before you commit. Use “Restart kernel and run all”. A notebook that only works when cells are run in a particular hidden order is a reproducibility bug.
3. Move reusable code into src/. Cleaning functions and training loops in .py files produce readable diffs. Import them in the notebook.
4. Number notebooks and keep each one to one purpose. 01_eda, 02_baseline_model and 03_error_analysis are easier to review than one giant file.
5. Set random seeds and record them. Put the seed in the first cell and mention it in the commit message when results change.
6. Consider pairing notebooks with plain-text versions. Tools such as Jupytext can keep a .py copy in sync, which makes code review easier. This is optional for a two-week project.

Handling datasets and model files without bloating the repository

Git stores every version of every committed file permanently. A 200 MB CSV committed once stays in the history even if you delete it the next day. GitHub also rejects individual files above 100 MB, and a rejected push can leave you untangling history under deadline pressure.

Use this decision list:

• Public dataset (Kaggle, UCI, Hugging Face): do not commit it. Put the download link or command in data/README.md, or write a small src/download_data.py script.
• Dataset supplied privately by a mentor: do not commit it unless you have been told you may. It may carry licence or privacy restrictions.
• Tiny sample for testing: a few hundred rows in data/sample/ is reasonable, and lets a reviewer run your pipeline quickly.
• Trained model weights: keep them out of Git. Record the training command, seed and metrics instead. If you must share weights, use a release asset, cloud storage link or a tool built for large files, such as Git LFS or DVC.
• Derived files such as processed features: regenerate them from a script rather than committing them.
• Checksums: if reproducibility matters, note a file hash or row count in data/README.md so others can check they have the same version.

A commit message convention for AI experiments

A consistent format makes your history scannable. This convention borrows the widely used “type(scope): summary” pattern and adds a few AI-specific types.

type(scope): short imperative summary (max ~60 characters)

Optional body: what changed, why, and the result.
Metric: F1 0.78 -> 0.81 on validation (seed 42)

Rules that keep messages useful:

• Write in the imperative: “add”, “fix”, “remove”, not “added” or “fixing”.
• One logical change per commit. Cleaning data and changing the model belong in separate commits.
• Put the metric and seed in the body whenever a commit changes results.
• Avoid messages such as “update”, “final” or “changes”. They tell a reviewer nothing.

A 14-day commit plan for an AI internship repository

This plan fits any two-week project, including the free two-week online internship from CareerSwami, which offers 26 tracks. Adjust the content to whichever track you choose; the Git habits stay the same.

Worked example: tracking a sentiment classifier and recovering from a committed dataset

This example is illustrative. The commands and numbers are invented to show the workflow and were not run on a real project.

Asha is building a movie-review sentiment classifier. On day 1 she creates the repository and commits her README and .gitignore. On day 2 she downloads reviews.csv (about 180 MB) into data/ and, in a hurry, runs git add . followed by a commit. Her .gitignore did not yet contain the *.csv rule.

She notices the problem when git push is rejected because the file is too large. Because she has not shared the repository with anyone, she can fix it before it spreads:

1. She adds *.csv to .gitignore.
2. She runs git rm --cached data/reviews.csv so Git stops tracking the file without deleting it.
3. Since the big file is still in her last commit, she undoes that commit while keeping her work, using git reset --soft HEAD~1, then unstages the dataset and recommits only the code and ignore rules.
4. She writes data/README.md with the download link and expected row count.
5. She checks git status and git log --oneline to confirm the CSV is neither tracked nor in history.

Had the large file been committed several commits earlier or already pushed, a simple reset would not be enough. She would need a history-rewriting tool such as git filter-repo, or, for a brand-new project, deleting the repository and starting again with the first commit done properly. On day 7 her history then looks like this:

a1f3c2e docs(report): outline results section
9bd04aa eval(baseline): confusion matrix, F1 0.78 (seed 42)
5c7e1d0 model(baseline): logistic regression with TF-IDF
2e8a9b4 data(split): stratified 80/20 split
7d41f06 chore: ignore csv files and model weights
03bb5e1 chore: initial structure and ignore rules

A reviewer can read these six lines and understand the project’s progress without opening a single notebook.

Version control mistakes that cost AI interns the most time

• Committing a large dataset or model file. It bloats the repository and may block your push. Prevent it with .gitignore first and git status before every commit.
• Committing API keys or credentials. A kaggle.json or cloud token in a public repository can be misused. If it happens, revoke and regenerate the key immediately; deleting the file later does not undo the exposure.
• Committing notebooks with huge embedded outputs. Images and long printouts make files heavy and diffs unreadable.
• Test data leaking into training. This is a modelling error, not a Git error, but Git helps you find it: a commit that changes the split should be separate and clearly labelled.
• One giant commit on the last day. It hides your process and removes the ability to undo one step.
• Vague messages. “Final version” tells nobody what changed.
• Working only on main. Risky experiments belong on branches.
• Never pushing. A repository that exists only on your laptop is one broken drive away from disappearing.
• Using git add . without checking. It sweeps in checkpoints, caches and data files.

JG University, Ahmedabad: Where Git Habits Meet Its Computing and Internship Structure

J.G. University is sponsored by the ASIA Charitable Trust and sits on Drive-In Road in Thaltej, Ahmedabad. Its official website lists a School of Computing and programmes that touch AI directly, including B.Tech CSE (AI & ML), B.Tech AI & Data Science, BCA (Hons) with Full Stack & AI, and MCA. Students on these courses are the ones most likely to write code during an internship, which is exactly when version control habits start to matter.

The university’s Industry Linkage page states that students are required to do a compulsory extensive internship in the industry. It also says its collaborations help students find internships and capstone projects, and that every student has an industry mentor with structured engagement. For a student keeping AI code in Git, those three points translate into concrete habits. Internship code often needs to be shown to a mentor, and a clean history with clear commit messages makes that conversation easier.

A capstone or internship project is also something a mentor or faculty reviewer may want to inspect. Keeping experiments on separate branches, committing notebooks and scripts in small steps, and writing a README that explains how to reproduce results all make the work easier to review and later to describe on a resume. The page does not publish a duration, credit value or evaluation format for the internship, so those details should come from the department rather than from assumption.

One caution applies to every AI internship: code, datasets and model files created at a host company may belong to that company. A student should check what can be placed in a personal repository before pushing anything public.

Practical checks for JG University AI students using Git

• Ask your school which semester the compulsory internship falls in and what documents it requires.
• Ask your industry mentor whether a private repository, or the company’s own, should hold internship code.
• Confirm in writing with the host company which code and data may appear in a personal portfolio.
• Agree early on how the department wants project work submitted, for example a repository link, a report or both.
• Keep large datasets and model weights out of the repository history and record how to obtain them instead.

Pre-submission checklist for your internship repository

• README explains the problem, setup, run order and results in under a page.
• requirements.txt (or environment file) lists library versions.
• git status is clean and no dataset, weights or .env file is tracked.
• Notebooks run top to bottom after a kernel restart.
• Key charts and metrics are saved in reports/.
• Commit messages follow the convention, with metrics and seeds noted where results changed.
• A fresh clone into a new folder works by following your README alone.
• Final milestone is tagged, for example v1.0-final.

Frequently Asked Questions

Should I commit my dataset to GitHub for an AI internship project?

Usually not. Link to the source in data/README.md or provide a download script. If you need to show the pipeline working, commit a tiny sample of a few hundred rows. Check the dataset’s licence, and if a mentor supplied it privately, ask before sharing any part of it.

How do I stop Jupyter notebooks from creating huge Git diffs?

Clear outputs before committing, either with jupyter nbconvert --clear-output --inplace or by installing nbstripout as a Git filter. Also move reusable code into .py files so the important logic produces readable diffs.

What should I do if I already committed a large CSV file?

If it is only in your latest unpushed commit, undo that commit with git reset --soft HEAD~1, unstage the file, add it to .gitignore and recommit. If it is buried in older commits or already pushed, you need a history-rewriting tool like git filter-repo, or a fresh repository for a very new project.

What is a good commit message for a model experiment?

Use a type, scope and short imperative summary, then put the result in the body, for example model(svm): try linear kernel with a line such as “F1 0.80 on validation, seed 42”. The point is that someone can find the commit behind any number in your report.

Is Git LFS or DVC necessary for a two-week internship?

Rarely. Most short projects can keep data outside the repository and document how to get it. Consider Git LFS or DVC only if a mentor specifically asks you to share large files through the repository, and learn the basics on a practice project first.

Should my GitHub repository be public or private?

Start private. Switch to public only after checking that it contains no credentials, no restricted data and nothing your supervisor or institution wants kept confidential. Ask your department whether any rule applies to publishing project code.

How many commits should a 14-day project have as a J.G. University student?

There is no required number. A useful target is one or more meaningful commits on each working day, each representing one logical change. Twenty to forty clear commits tell a better story than three large ones, but quality of messages matters more than quantity.

Can I use the CareerSwami internship project as my Git portfolio piece?

Yes, if the project work is yours and you follow the track’s instructions on what may be shared. Treat the repository as the evidence of your process: a clear README, a sensible history and a reproducible run order will help in later applications, though the internship itself offers no placement guarantee.

Related Artificial Intelligence guides

• MAHE Students: Applying AI to Healthcare Data in an Internship Without Breaking Privacy Rules
• Sri Dev Suman Uttarakhand Vishwavidyalaya Students: Planning an AI Internship for Hill-Region Problems
• P.K. University Students: Writing Your AI Internship Learning Objectives Before Day One
• All Artificial Intelligence internship guides