Ramchandra Chandravansi University Students: Handling Common Git Mistakes During an Internship

Most Git mistakes in an internship can be undone, provided you stop, check git status and git reflog, and choose the recovery that matches the mistake. The exception is a leaked secret: once a key has been pushed, you must revoke it first and clean history second. This guide gives a decision tree, exact commands and a 14-day habit plan for full stack interns.

Why Git trouble peaks in a two-week internship

A short internship compresses everything. You clone a repository on day one, ship a feature by day ten and present on day fourteen. There is no slack for a corrupted branch. The usual causes are predictable: working directly on main, pulling without reading what arrives, copying a .env file into a commit, and typing git push --force because a forum answer said so.

The good news is that Git keeps a local safety net. Nearly every command that “loses” work only moves a pointer, and the old commits remain reachable through the reflog for a good while (by default, around 30 to 90 days for unreachable entries). Panic is the real danger, because it makes people run a second destructive command on top of the first.

First-response rules before any recovery command

1. Stop typing. Do not run git reset --hard, git clean or git push --force yet.
2. Run git status to see your branch and any unstaged or conflicted files.
3. Run git log --oneline --graph --decorate -15 to see where each branch points.
4. Run git reflog -20 to find the commit hash from before the mistake.
5. Create a safety branch: git branch backup-before-fix. It costs nothing and gives you a way back.

Troubleshooting decision tree for the four common Git failures

Start at the top and follow the first question that matches your situation.

1. Is there a secret (API key, password, token, database URL) in a commit?
   • Yes and it was pushed: go to the leaked key section. Revoke the key before anything else.
   • Yes but not pushed: go to the section on removing a secret from local commits.
2. Did a push go wrong (rejected, overwritten, or history rewritten)? Go to the force push section.
3. Does Git report CONFLICT or show <<<<<<< markers? Go to the merge conflict section.
4. Did you commit on the wrong branch? Go to the wrong-branch section.
5. None of these? Use the reflog to find the last good state, then git switch -c rescue <hash>.

Quick lookup table: symptom, cause and recovery command

Wrong-branch commits: moving work without losing it

Case A: committed on main, nothing pushed

This is the most common mistake. The fix is to give the commit a proper branch and then rewind main.

git status
git branch backup-before-fix
git switch -c feature/login-form     # new branch keeps your commit
git switch main
git reset --hard origin/main         # main returns to the remote state
git switch feature/login-form

Check that origin/main is current by running git fetch first. If you have uncommitted changes you want to keep on main, run git stash before the reset.

Case B: committed on the wrong feature branch

git log --oneline -3                 # copy the hash of the misplaced commit
git switch correct-branch
git cherry-pick a1b2c3d
git switch wrong-branch
git reset --hard HEAD~1              # remove it from the wrong branch

Case C: you have not committed yet

Git carries uncommitted changes across a switch when files do not clash. If it refuses, use git stash, then git switch correct-branch, then git stash pop.

Case D: the commit was already pushed to main

Do not rewrite shared history. Use git revert <hash>, which adds a new commit that undoes the change, then re-apply the work on a branch with cherry-pick. If the repository protects main, tell your mentor before trying anything else.

Merge conflicts: reading markers and resolving them safely

A conflict is not an error in your work. It means Git cannot decide between two edits to the same lines. A conflicted file looks like this:

<<<<<<< HEAD
const API_URL = "http://localhost:5000";
=======
const API_URL = process.env.REACT_APP_API_URL;
>>>>>>> feature/env-config

The top block is your current branch; the bottom block is the incoming one. Pick one, combine them, or write something new, then delete all three marker lines.

1. git status lists files under “Unmerged paths”.
2. Open each file, resolve the markers, and save.
3. Search the project for leftover markers: git grep -n "<<<<<<<".
4. Run the app and any tests. A clean merge can still break behaviour.
5. git add <file> for each resolved file, then git commit (or git rebase --continue).

If you are lost halfway, git merge --abort or git rebase --abort returns you to the state before you started. For lock files such as package-lock.json, do not hand-edit. Take one side with git checkout --theirs package-lock.json (or --ours), then run npm install to regenerate it consistently.

To reduce conflicts: pull from the base branch at the start of each working session, keep commits small, and avoid reformatting whole files you do not own.

Leaked keys: revoke first, clean history second

Treat any pushed secret as public. Automated scanners watch public repositories, and even a private repository can be cloned by many people. Rewriting history does not un-leak a key. Order matters.

If the secret was pushed

1. Revoke or rotate the key in the provider’s dashboard (cloud, payment gateway, database, email service, OAuth app). Generate a new one.
2. Tell your mentor immediately. Reporting quickly is professional; hiding it is the real mistake.
3. Put the new key in an untracked .env file and add .env to .gitignore.
4. Remove the file from tracking: git rm --cached .env and commit.
5. Only then, if the team agrees, purge history with git filter-repo (install it separately) and coordinate a forced push.

git filter-repo --path .env --invert-paths
git remote add origin <url>        # filter-repo removes remotes; re-add
git push --force-with-lease --all

Everyone else must re-clone or hard-reset afterwards, which is why the team lead should decide on this step. Also check forks, open pull requests and CI logs, which may still hold the old commits.

If the secret is in a local commit only

git rm --cached .env
echo ".env" >> .gitignore
git add .gitignore
git commit --amend       # if it was the last commit
# older commit: git rebase -i HEAD~3, mark the commit as "edit"

Still rotate the key if it ever touched a shared machine or a synced folder.

Prevention checklist

• Add .env, *.pem and config/secrets.* to .gitignore on day one.
• Commit a .env.example with placeholder values only.
• Run git diff --staged before every commit and read it.
• Consider a pre-commit scanner such as gitleaks, if your mentor allows extra tooling.

Force pushes: undoing and avoiding the overwrite

A plain git push --force replaces the remote branch with yours, even if it discards other people’s commits. --force-with-lease refuses if the remote has changed since you last fetched, which makes it the safer choice when a force push is genuinely needed (for example, after an interactive rebase on your own feature branch).

If you overwrote the remote

1. Tell the team straight away and ask everyone to stop pushing to that branch.
2. Ask anyone who pulled before your push to run git reflog show origin/main or git reflog and share the old hash.
3. Restore: git push --force-with-lease origin <old-hash>:main.
4. Rebuild your own work on top: git rebase origin/main or git cherry-pick your commits.

If you are the one whose work vanished

git reflog
git branch recovered <hash>
git log recovered --oneline

Rules that prevent most force-push disasters

• Never force push to main, develop or any shared branch.
• Rebase only branches that you alone use.
• Use --force-with-lease, never bare --force.
• Run git fetch and git log origin/branch..branch before pushing.

Worked example: one intern’s bad Thursday, step by step (illustrative)

This scenario is invented to show the order of decisions; no commands were executed to produce it. An intern building a Node and React expense tracker finishes the login form on day 8. She notices three problems at once: the commit is on main, it contains a .env with a MongoDB connection string, and the push has already happened.

1. Triage with the decision tree. A secret was pushed, so that comes first, even though the wrong-branch issue is also present.
2. Revoke. She resets the database user’s password in the hosting dashboard and updates her local .env. She messages her mentor with the commit hash and the time.
3. Stop the leak. git rm --cached .env, add .env to .gitignore, commit and push a fix.
4. Fix the branch. Because main is shared and already pushed, she does not reset it. She creates feature/login-form from the current state for future work and lets the mentor decide whether to purge history.
5. Mentor decision. The mentor opts for git filter-repo on a small, two-person repository. Both people re-clone afterwards.
6. Record. She adds a short note in her internship log: what happened, what was revoked, what she changed in her routine.

The password rotation took minutes and mattered most. The history purge was optional once the credential was dead.

A 14-day habit plan that prevents Git disasters

If you want a structured place to practise, the free two-week online CareerSwami internship includes a free offer letter and a free completion certificate after successful completion, and spans 26 tracks, including full stack work where these Git habits apply directly.

Ramchandra Chandravansi University interns: Git evidence and the internship paperwork

The Academic Byelaws (UG regulations, clause 2.11.1) require pre-final or final year degree students to complete at least four weeks of internship, industrial or field training in the summer vacation, carrying two credits. A 14-day internship is therefore shorter than that minimum on its own. Whether it can count toward it, or be combined with other training, is something the byelaws do not say. The clause as read does not mention online internships, and the byelaws are an unversioned upload, so check the current version.

The same byelaws ask for a certificate from the training centre’s competent authority and a training report signed by the training supervisor and verified by the department’s Training Coordinator. For a developer, your Git history is the natural evidence for that report: dated commits, pull requests and a clean README show what you built. This is also why a purged or force-pushed history can create awkward questions, so keep a record of any rewrite in your log.

The byelaws also say the Institute arranges training centres, and direct student applications are forwarded only if the Training & Placement Cell’s requested seats are unavailable. The Training & Placement Cell page lists its chairperson and members but gives no procedures. The 2024-25 academic calendar left summer vacation dates “to be decided later”, so check the current year’s dates before planning.

Verification steps for RCU students

1. Email your department’s Training Coordinator, asking in writing whether a 14-day online internship is accepted, alone or alongside other training, under clause 2.11.1.
2. Ask the T&P Cell whether you must route the application through the Institute or may apply directly.
3. Request the current Academic Byelaws and the training report format.
4. Ask who signs as training supervisor when the host is an online programme.
5. Ask whether a repository link, commit log or screenshots may be attached as work evidence.
6. Confirm the current summer vacation dates with your department office.

Frequently Asked Questions

Can I recover a commit after git reset --hard?

Usually yes, if the commit existed. Run git reflog, find the hash from before the reset, and use git reset --hard <hash> or git branch recovered <hash>. Uncommitted changes that were never staged or committed cannot be recovered this way.

What is the difference between git revert and git reset?

reset moves a branch pointer backwards and rewrites history, which suits local, unpushed work. revert adds a new commit that undoes an earlier one, which is the safe choice for anything already pushed to a shared branch.

Is deleting the file and committing again enough after leaking a key?

No. The key remains in earlier commits and anyone can read it from history. Revoke or rotate the key first. Purging history is a second, optional step that your team should agree on.

When is --force-with-lease acceptable?

On a branch that only you use, typically after rebasing or amending a commit. It refuses to overwrite remote work you have not seen. Do not use it on main or on shared branches.

How do I practise merge conflicts without risking project work?

Create a throwaway repository, make two branches that edit the same line of one file, and merge them. Resolve the markers, then repeat with git rebase and practise --abort. Ten minutes of this removes most of the fear.

Will my Git history count as proof of my internship at RCU?

The byelaws ask for a certificate from the training centre and a signed, verified training report. Git history can support the report as evidence, but the byelaws do not say it replaces either document. Confirm the accepted evidence with your Training Coordinator.

Should I tell my mentor if I make a serious Git mistake?

Yes, and quickly, especially for leaked secrets or overwritten shared branches. Early reporting limits damage and is treated as good practice. Bring the commit hash, the time, and what you have already done.

What should I do if a conflict makes no sense to me?

Run git merge --abort (or git rebase --abort), then ask the author of the other change what they intended. Resolving a conflict without understanding both sides is how bugs enter a clean-looking merge.