Dev Bhoomi Uttarakhand University Students: Git Basics Every Testing Intern Needs

A testing intern needs about a dozen Git commands: clone, branch, add, commit, push, pull, merge and a way to resolve conflicts. That is enough to keep your test scripts safe, reviewable and separate from other people’s work. This guide gives you those commands in a cheat sheet, a conflict-resolution routine, and a practice exercise that fits a 14-day internship.

Why Git matters more for testers than most students expect

Testers write code too: Selenium or Playwright scripts, API collections, test data files, bug-report templates and configuration. All of it changes constantly. Git records every change, lets you try something without breaking the working version, and lets a reviewer see exactly what you altered.

In an internship, a mentor or reviewer will usually ask for your work as a repository link, not a zip file. Being comfortable with Git is therefore part of looking professional from day one. Three habits matter most:

• Small commits: one logical change per commit, such as “Add login negative test cases”.
• Branches for every task: never edit the main branch directly.
• Clear messages: a reviewer should understand the change without opening the files.

Setting up Git once: the five-minute install checklist

1. Install Git from the official git-scm.com download page and confirm it with git --version.
2. Set your identity so commits carry your name: git config --global user.name "Your Name" and git config --global user.email "you@example.com".
3. Create a free account on a hosting service such as GitHub or GitLab.
4. Create a new repository, for example qa-practice, with a README.
5. Clone it: git clone <repository-url>, then move into the folder with cd qa-practice.

Use an email you are comfortable showing publicly, because it is stored in every commit.

Git cheat sheet for testing interns: commands by task

Branching for test work: naming and scope

One branch should hold one testing task. If your task is “write test cases for the signup form”, the branch should contain only that. A reviewer can then approve or reject it cleanly.

A simple naming pattern keeps things readable:

• test/signup-form for new test scripts
• bug/cart-total-mismatch for evidence or reproduction scripts linked to a defect
• docs/test-plan for test plans and checklists
• fix/flaky-login-wait for repairing an unreliable test

Avoid names like new, final or test2. Two days later you will not remember what they hold.

Committing test scripts: what to include and what to leave out

Commit the things someone else needs to re-run your tests: scripts, small test data files, a requirements file, and a short README explaining how to execute them. Leave out anything generated or private.

Put the “keep out” items in a .gitignore file at the top of the repository. A starting point is shown below; adjust it for your tool.

node_modules/
venv/
__pycache__/
*.log
reports/
screenshots/
.env

If you accidentally commit a secret, treat it as exposed: change the password or key at once and tell your mentor. Deleting the file in a later commit does not remove it from history.

Writing commit messages a reviewer will thank you for

• Start with a verb in present tense: “Add”, “Fix”, “Remove”, “Update”.
• Name the feature under test: “Add boundary tests for age field”.
• Keep the first line under about 70 characters.
• Avoid “changes”, “stuff” and “final version”.

Resolving merge conflicts in test files, step by step

A conflict happens when two people change the same lines, or one edits a file the other deleted. In testing teams this often occurs in shared files such as a test data file, a config file or a common helper script. Conflicts look frightening but follow a fixed routine.

1. Run git status. Files marked “both modified” are in conflict.
2. Open one conflicted file. You will see markers like the ones below.
3. Decide what the final text should be. Often you keep both changes, sometimes one, sometimes a rewritten blend.
4. Delete the three marker lines completely.
5. Run the affected tests to confirm they still pass.
6. Stage the file with git add, then finish with git commit.

<<<<<<< HEAD
BASE_URL = "https://staging.example.com"
=======
BASE_URL = "https://qa.example.com"
>>>>>>> main

The part between <<<<<<< HEAD and ======= is your version. The part below, up to >>>>>>> main, is the incoming version. If you are unsure which environment is correct, ask the teammate who made the other change rather than guessing. If the merge turns into a mess, git merge --abort returns you to the state before you started.

Illustrative example: a conflict in a shared test data file

This scenario is illustrative, not a record of real events or of tests being run. Two interns, Asha and Ravi, both branch from main. Asha adds an invalid-email row to users.csv for signup tests. Ravi adds an expired-card row to the same spot in the same file for payment tests. Ravi’s branch is merged first. When Asha runs git merge main, Git reports a conflict in users.csv.

Asha opens the file and finds both rows between conflict markers. Both rows are valid and unrelated, so she keeps both, removes the markers, and re-runs the signup tests. She then runs git add users.csv and git commit with the message “Merge main and keep both test data rows”. The lesson: most test-data conflicts need keeping both sides, but you must still run the tests afterward to confirm nothing broke.

Practice exercise: a 14-day Git routine for a testing intern

Use this plan alongside whatever tasks your internship gives you. The free two-week online internship from CareerSwami is 14 days long, so the plan is sized to match. It is built on a small practice repository you control.

Exercise: create and resolve a conflict on purpose

1. On main, create config.txt containing timeout=10. Commit it.
2. Create branch fix/timeout-a, change the line to timeout=20, commit.
3. Switch to main, create branch fix/timeout-b, change the line to timeout=30, commit.
4. Merge fix/timeout-a into main, then run git merge fix/timeout-b while on main.
5. Git reports a conflict. Choose a final value, remove the markers, add and commit.
6. Write one sentence in your README on why you chose that value.

Self-check scorecard: is your repository ready to show a mentor?

Eight yes answers mean the repository is ready to share. Fix each “No” before sending the link.

Git for DBUU students: using version control alongside your coursework

Dev Bhoomi Uttarakhand University’s homepage says it offers 120+ programmes across 12 schools, including engineering and computer applications. That means students from different programmes may end up doing testing work, and not all of them will have met Git in class. If your syllabus does not cover it, learning it yourself through a practice repository is a sensible fix.

The same homepage says students are encouraged to apply for internships and industry visits. It describes this in general terms and does not set out internship rules. So whether an online internship, or a Git repository as evidence of it, is accepted for any university requirement is something you must confirm, not assume. The homepage also lists a mid-semester examination datesheet and a Diwali holidays notice for 2026. Open those notices, check the dates, and schedule your 14-day plan around exams so the practice does not clash with them.

The homepage has a Placements section too, but the extracted content gave no detail on how it works. Treat a public GitHub repository as a portfolio piece you can show anyone, and ask the placement office what they expect to see from students with testing skills.

Five steps to verify before you rely on an internship for university purposes

1. Ask your department coordinator in writing whether an online internship is permitted for your programme and semester, and request the relevant regulation or circular.
2. Ask what document the university needs from you, such as an offer letter, a completion certificate or a supervisor report, and in what format.
3. Check the October 2026 mid-semester and supplementary datesheets and the Diwali holiday notice on the official site before fixing your 14-day start date.
4. Ask the training and placement office whether a link to a code repository is accepted as supporting evidence of project work.
5. Confirm whether the rule is set by the university or by your individual school, since this may differ.

Git slip-ups testers make and the quickest fix for each

• Committed to main by mistake: create a branch from the current state with git switch -c my-branch, then ask your mentor how to reset main safely.
• Typo in the last commit message: before pushing, run git commit --amend -m "New message".
• Forgot a file in the last commit: stage it and run git commit --amend --no-edit, again only before pushing.
• Push rejected: run git pull first, resolve any conflict, then push again.
• Tests pass on your laptop only: a missing dependency or hard-coded path is likely; list requirements in the README and test with a fresh clone.
• Huge repository: screenshots, reports or drivers were committed; add them to .gitignore and remove them from tracking with git rm --cached.

Avoid rewriting history on anything already pushed and shared, unless a mentor tells you to.

Frequently Asked Questions

Do I need to learn Git before starting a software testing internship?

You do not need mastery, but the cheat sheet commands above cover most daily use. Spending the first two days on setup and a first commit means you can focus on testing tasks afterward.

Should manual test cases go into Git as well as automation scripts?

Yes, if they are in a text-friendly format such as Markdown or CSV. Git shows line-by-line changes in those files, which makes reviews easier. Large binary spreadsheets are harder to compare, so export them if you can.

What is the difference between git pull and git fetch for a tester?

git fetch downloads new changes without altering your files, so you can inspect them first. git pull fetches and then merges immediately. Beginners can use git pull, but fetch is safer when you have uncommitted work.

How often should I commit test scripts?

Commit whenever one logical piece works, such as one test case or one fixed helper function. A rough guide is every 20 to 40 minutes of focused work, as long as each commit leaves the tests in a runnable state.

Is it safe to put test credentials in my repository?

No. Keep credentials in environment variables or a local .env file listed in .gitignore, and provide a sample file with placeholder values instead.

Can a Git repository serve as proof of my work in a free online testing internship?

It is useful supporting evidence of what you did, such as scripts, test cases and commit history, but it does not replace official documents. The free two-week internship from CareerSwami provides an offer letter and a completion certificate after successful completion, and your repository can sit alongside those. Whether your university accepts either one for any requirement must be confirmed in writing with your department.

What should I do if I am scared of breaking the main branch?

Work only on your own branch and practise in a personal repository first. Most hosting services can protect the main branch so changes need review, and you can ask your mentor whether that is turned on.

Related Software Testing guides

• Guru Kashi University Students: Preparing for a Practical Test Round in Intern Selection
• Dr. B.R. Ambedkar University Agra: Applying for Testing Internships in Small Local Firms
• Apeejay Stya University Students: Test Automation Framework Basics for Interns
• All Software Testing internship guides