Sant Baba Bhag Singh University: Using Git and GitHub During a Frontend Internship

Use Git as a daily habit, not a last-day upload: clone or create a repository on day one, work on a branch, make small commits with clear messages, and open a pull request for every meaningful piece of work. In a 14-day frontend internship, that routine produces a visible trail of progress that a reviewer can read in minutes. This guide gives you the full workflow, commit message examples and a hygiene checklist.

Why Git history matters more in a short frontend internship

Fourteen days is not long. You will probably build a few pages or components, fix layout bugs and push something live. Anyone reviewing your work, whether a mentor, a faculty member at Sant Baba Bhag Singh University or a future interviewer, will not run your project locally. They will open your GitHub page, glance at the README, check the live link and scroll through the commits.

A clean history answers three questions fast:

• Did you build this yourself? Steady commits across several days look very different from one giant upload.
• Can you work in a team-style process? Branches and pull requests show you know how real frontend teams ship changes.
• Can others understand your work? Descriptive commits and a clear README show communication skill, which counts as much as CSS skill.

The free two-week online internship at CareerSwami is one way to get a structured 14-day window to practise this. It includes a free offer letter and a free completion certificate after successful completion, and the certificate is far more convincing when a repository backs it up.

Setting up Git and GitHub before day one

Spend the first hour on setup so it never blocks you later.

1. Install Git and confirm it works with git --version.
2. Set your identity: git config --global user.name "Your Name" and git config --global user.email "you@example.com". Use the email attached to your GitHub account so commits are linked to your profile.
3. Create a GitHub account with a professional username. Your name or a clean variant works better than a nickname with numbers.
4. Set up authentication, either an SSH key or HTTPS with a personal access token. GitHub no longer accepts account passwords for command-line pushes.
5. Add a short profile bio and a real photo. Reviewers do click through to the profile.

Git workflow cheat sheet: clone to pull request

This is the core asset. Follow it in order for each task, whether it is a navbar, a form or a responsive fix.

If you started from your own project instead of cloning, replace step 1 with git init, create an empty repository on GitHub, then run git remote add origin <url> and push.

Forking when you do not have write access

If the project belongs to someone else, fork it on GitHub, clone your fork, and add the original as a second remote with git remote add upstream <original-url>. Pull updates with git pull upstream main, push to your fork, and open the pull request from your fork to the original.

Writing commit messages a reviewer can scan

A widely used convention is a short type prefix, a colon, then an imperative summary under about 50 characters. Common prefixes are feat, fix, style, refactor, docs and chore.

When a change needs explanation, add a body after a blank line by running git commit without -m. Explain why you made the change, not what the diff already shows.

Writing a pull request description that gets read

Even if you are the only contributor, open pull requests against your own main branch. They create a reviewable record of each feature. Use this template:

## What this changes
Adds a responsive navbar with a mobile hamburger menu.

## How to check it
1. Open index.html
2. Resize the window below 768px
3. Confirm the menu toggles with the button and with Enter/Space

## Screenshots
Desktop and mobile images attached.

## Notes
Colour contrast checked against the brand palette.

Worked example: one frontend task across three days (illustrative)

This sequence is illustrative and shows how a single task might be split. No code or tests were run for this article.

Task: build a pricing section for a landing page.

1. Day 5, morning. Run git switch main, git pull, then git switch -c feature/pricing-section.
2. Day 5, afternoon. Write the markup and commit: feat: add pricing section markup with three plan cards.
3. Day 5, evening. Add styles and commit: style: lay out pricing cards with CSS grid.
4. Day 6. Fix the mobile view and commit: fix: stack pricing cards on screens under 600px. Then add a hover state: style: add hover and focus states to plan buttons.
5. Day 6, end. Push the branch, open a pull request with two screenshots, review your own diff on GitHub, then merge.
6. Day 7. Pull main, delete the branch locally with git branch -d feature/pricing-section and start the next task.

The result is four small commits and one pull request, each readable on its own. A reviewer can see how the section took shape without opening a single file.

A 14-day Git rhythm for the internship

Repository hygiene checklist for a reviewable profile

Run through this list on day 13 or 14. Each item takes minutes and changes how the repository looks.

Structure and files

• A .gitignore that excludes node_modules/, build folders, .env files and OS clutter such as .DS_Store.
• No secrets committed: API keys, tokens or passwords. If one slipped in, revoke it, because deleting the file does not remove it from history.
• Sensible folders such as src/, assets/ and css/, with lowercase file names and no spaces.
• No unused files, duplicate copies like index-final.html, or large unoptimised images.

README

• Project title and a one-sentence description of what it does.
• A live demo link and one or two screenshots near the top.
• Tech used (HTML, CSS, JavaScript, any framework) and how to run it locally.
• A short list of what you built during the 14 days and what you would improve next.

History and branches

• Commit messages follow one consistent style.
• Commits are spread across the internship days, not clustered into one upload.
• Merged branches are deleted; main holds working code only.
• At least two or three pull requests with real descriptions.

Profile presentation

• The repository has a short description and topics such as frontend, html, css, javascript.
• Your best one to three repositories are pinned.
• Your profile README or bio states what you are learning and how to contact you.
• The live demo actually loads and works on a phone.

Git mistakes that hurt beginners during a short internship

• Committing directly to main for everything. It hides your process. Use branches for anything beyond a typo fix.
• Using git add . blindly. This is how node_modules and .env files end up on GitHub. Check git status first.
• Force pushing on shared branches. git push --force can erase a teammate’s work. Avoid it unless you fully understand the result.
• Ignoring merge conflicts. Open the conflicted file, keep the correct lines, remove the <<<<<<< markers, then add and commit.
• Uploading a zip through the browser. It skips history entirely and looks like copied work.

Sant Baba Bhag Singh University: Using Git on Frontend Work Alongside Its CSE Internship Records

Sant Baba Bhag Singh University is at Village Khiala, Padhiana, Jalandhar, Punjab. Its official site says it was established under a Punjab Government Act and is recognised by the UGC under Section 2(f). The University Institute of Engineering & Technology sits within its Engineering faculty, and the Computer Science & Engineering department offers B.Tech CSE (AI & ML) and B.Tech CSE (Cyber Security).

The university’s internship and training page for CSE lists downloadable records of students who completed 4-week, 6-week and 6-month training across several batches. This shows that short and long trainings are both part of the department’s practice, but the page states no eligibility, timing or evaluation rules, so those must be confirmed for your own batch.

The Training & Placement page describes pre-placement training, industrial visits and expert lectures, and gives the office as Room 402, Block 5, with the email placements@sbbsuniversity.ac.in. That office is a sensible first contact for questions about letters and certificates.

For a frontend intern, a clean GitHub history is useful evidence for a department report: small, clearly labelled commits show what was done and when. Keep it within what the host company permits, since employer code is often private and may not be published.

Things to check at SBBSU before putting internship code on GitHub

• Ask the CSE department which training duration, 4-week, 6-week or 6-month, applies to your batch.
• Email the Training & Placement office to ask what documents a certificate or record needs.
• Get written permission from the host company before publishing any of its code.
• Use a personal repository for practice work and keep company work in the repository the employer provides.
• Ask your department whether a repository link is accepted as evidence in the final report.

Turning the repository into proof for your internship report

Once the 14 days end, convert the repository into evidence:

• Link the repository and live demo in your report, with one screenshot per feature.
• List pull requests by title as a short work log: “PR 1: Navbar”, “PR 2: Pricing section”.
• Pick three commits that show a bug you fixed and describe the cause and solution in two lines each.
• Add the repository link to your resume under Projects, with one line on what it demonstrates.

Frequently Asked Questions

Do I need to learn the whole Git command set for a 14-day internship?

No. The ten steps in the cheat sheet cover almost everything you need. Add git log --oneline, git stash and git restore once the basics feel comfortable.

Should I use the command line or a GUI like GitHub Desktop?

Either works, but learn the command line basics because interviews and team projects assume them. A GUI is fine for visualising history while you learn.

How many commits should a two-week frontend project have?

There is no fixed number. Aim for small, logical commits, often several per working day. Quality and spread across days matter more than the total.

What if I committed a password or API key by mistake?

Revoke or regenerate the key immediately, then remove it from the code and add the file to .gitignore. Deleting it in a later commit does not hide it, because the old commit still contains it.

Is it a problem if my repository is private?

Reviewers cannot see a private repository unless you invite them. For portfolio purposes make it public, after checking it holds no secrets or personal documents.

Can I rewrite or squash messy commits before submitting?

You can, using interactive rebase, but only on branches no one else uses, and never to fake a timeline. Honest history with a few awkward commits is better than a misleading one.

Will my GitHub repository count towards my university requirements?

That depends on your department. Ask in writing what evidence it accepts and whether a repository link can support your report.

How do I show the project is live without paid hosting?

GitHub Pages and similar free static hosts work for HTML, CSS and JavaScript projects. Put the live URL in the README and the repository description.

Related Frontend Development guides

• Harichand Guruchand University Students: Applying for a Frontend Internship with a Cold Email
• Ajeenkya D.Y. Patil University: Frontend Internship Project Using Figma Handoff
• Gautam Buddha University Students: Debugging Routine for Frontend Internship Beginners
• All Frontend Development internship guides