Maharishi University of Management and Technology: Handling Git in a Java Team Internship

To handle Git in a Java team internship, work on a short-lived branch per task, commit small changes with clear messages, open a pull request early, and resolve merge conflicts by reading both sides before editing. Always build and run tests after resolving a conflict, because a Java file can merge cleanly and still fail to compile. The cheat sheet below covers the full routine for a 14-day internship.

Why Git habits matter more than Git commands in a two-week Java internship

In 14 days you will not learn every Git feature, and you do not need to. What mentors notice is whether your changes are small, reviewable, and traceable to a task. A Java enterprise repository usually has several developers touching the same controllers, services and configuration files, so sloppy habits cause conflicts quickly.

The free two-week online internship at CareerSwami is one place to practise this routine on a short project. Whatever the setting, the same routine applies: sync, branch, change, test, commit, push, review, merge.

Branch naming and lifecycle cheat sheet for a Java repository

Teams differ, so ask your mentor which branching model is used. The most common pattern for small teams is a protected main branch with short feature branches off it.

Branch name conventions worth following

• Use a prefix that states intent: feature/, bugfix/, docs/, test/.
• Include a ticket number if the team uses one, for example bugfix/123-null-customer-email.
• Keep it lowercase and hyphenated, with no spaces.
• Delete the branch after merge so the remote stays readable.
• Never force-push to a shared branch. Ask first if you think you need to.

Keeping Java build files and IDE clutter out of commits

A frequent beginner problem is committing generated files. Check that the repository has a .gitignore that covers at least:

• target/ for Maven or build/ and .gradle/ for Gradle
• *.class and *.log
• .idea/, *.iml, .vscode/, .settings/, .classpath
• local configuration containing secrets, such as application-local.properties

Never commit database passwords, API keys or tokens. If you do so by mistake, tell your mentor immediately, because deleting the file in a later commit does not remove it from history.

Commit message template for Java changes

A good message tells a reviewer what changed and why, without opening the diff. A widely used shape is a short imperative subject line, a blank line, then an optional body.

Add discount validation to OrderService

Reject negative discount percentages before price calculation.
Throws IllegalArgumentException, handled in OrderController.
Adds unit tests for 0, 100 and out-of-range values.

Refs: #123

• Keep the subject near 50 to 72 characters.
• Use the imperative: “Add”, “Fix”, “Remove”, not “Added” or “Fixing”.
• One logical change per commit. A refactor and a bug fix belong in separate commits.
• Follow the team’s own format if it differs, for example prefixes like feat: and fix:.

Pull request checklist before you ask a Java reviewer to look

Open the pull request when the change is understandable, not when it is perfect. A draft pull request is fine for early feedback if the platform supports it.

1. The branch is up to date with main and has no unresolved conflicts.
2. The project compiles: mvn clean verify or ./gradlew build, whichever the repository uses.
3. Existing tests pass, and you added tests for the new behaviour.
4. The diff contains no unrelated formatting changes, no unused imports and no debug System.out.println lines.
5. The title states the change in one line and the description says what, why, and how you tested it.
6. Any API, database or configuration change is called out explicitly.
7. You have re-read your own diff on the pull request page as if you were the reviewer.

Responding to review comments

• Reply to each comment, even if only to say it is done.
• Push fixes as new commits during review, then follow the team’s rule on squashing at merge.
• If you disagree, ask a question and give a reason rather than ignoring the comment.
• Do not mark a conversation resolved on behalf of the reviewer unless the team does that.

Merge conflict walkthrough on a Spring service class (illustrative)

This scenario is invented for teaching. No code was run, and the class names are placeholders. Suppose two interns changed the same method in OrderService. You added discount validation; a teammate added audit logging. Your teammate’s pull request merged first. When you merge main into your branch, Git reports a conflict.

$ git fetch origin
$ git merge origin/main
Auto-merging src/main/java/com/example/order/OrderService.java
CONFLICT (content): Merge conflict in src/main/java/com/example/order/OrderService.java
Automatic merge failed; fix conflicts and then commit the result.

Open the file. Git marks the competing sections:

public Order createOrder(OrderRequest request) {
<<<<<<< HEAD
    if (request.getDiscount() < 0 || request.getDiscount() > 100) {
        throw new IllegalArgumentException("Discount must be between 0 and 100");
    }
=======
    auditLogger.info("Creating order for customer {}", request.getCustomerId());
>>>>>>> origin/main
    Order order = orderMapper.toEntity(request);
    return orderRepository.save(order);
}

The section above ======= is your branch; the section below is main.

Steps to resolve it

1. Understand both intents. Yours is input validation. Theirs is audit logging. They do not contradict each other, so both should stay.
2. Decide the order. Validating before logging avoids recording invalid requests as created orders. If unsure, ask the teammate or mentor.
3. Edit the file and delete all three marker lines.
4. Check the rest of the file. The teammate may also have added an auditLogger field and an import. Confirm those exist exactly once, since a merge can duplicate or drop them.
5. Compile and test before committing.
6. Complete the merge with git add on the file and git commit.

The resolved method might read:

public Order createOrder(OrderRequest request) {
    if (request.getDiscount() < 0 || request.getDiscount() > 100) {
        throw new IllegalArgumentException("Discount must be between 0 and 100");
    }
    auditLogger.info("Creating order for customer {}", request.getCustomerId());
    Order order = orderMapper.toEntity(request);
    return orderRepository.save(order);
}

Spring-specific conflict traps

• Constructor injection. Two people adding different dependencies to the same constructor produce a conflict in the parameter list. Keep both, and make sure the field assignments match.
• Imports. Merge tools often keep both import blocks. Remove duplicates and unused imports.
• Configuration files. In application.properties or application.yml, check for duplicate keys. In YAML, indentation errors can silently change meaning.
• pom.xml or build.gradle. A conflicted dependency block can still be valid XML but pull in two versions. Run the build and inspect the dependency tree.
• Database migrations. If your team uses Flyway or Liquibase, two migrations with the same version number are a real problem. Raise it with your mentor rather than guessing.

If the conflict looks too tangled, use git merge --abort to return to the pre-merge state and ask for help. That is far better than committing a guess.

Fourteen-day Git practice plan for a Java internship

MUMT students: documenting Git work when your university rules on internships are unclear

Maharishi University of Management and Technology was established as a private university in Mangla, Bilaspur, under a Chhattisgarh Act, and its About page gives the 2018 assent date and says it is listed on the UGC website. For a student, the practical question is how a Git-based internship gets recorded.

The university prospectus (2025) lists BCA, B.Sc. (IT), M.Sc. (IT), DCA and PGDCA, the programmes most likely to fit a Java internship. It names project work and work-related field projects as part of teaching but mentions internships only generically, with no stated duration, credits, semester or evaluation rules. Check the current version, as this is an older document.

The Academic Council minutes of 28 August 2025 directed that syllabi be outcome-based with provision for project work and industrial visits. The syllabus page links PDFs for BCA, DCA, M.Sc(IT) and PGDCA, but the M.Sc(IT) file name carries 2021-22, so the current scheme may differ. Nothing in these sources says whether an online internship counts toward any requirement, so do not assume it does. CareerSwami’s internship is free and gives an offer letter and a completion certificate; it does not carry academic credit.

Because the evidence is thin, build your own record. Keep your repository link, pull request URLs, commit history and a short log of tasks. A mentor or faculty member can then judge the work on its merits.

Verification steps for MUMT students

1. Ask your department office in writing whether an external or online internship is permitted and whether it is recorded in any semester.
2. Request the current syllabus PDF for your exact programme and batch and look for project, internship or training components.
3. Ask which document or format your department wants as proof, such as a certificate, a report or a supervisor letter.
4. Check the Academic Calendar page for semester breaks so the 14 days do not clash with exams or classes.
5. If you want placement guidance, ask who currently runs the Placement Cell, since the minutes only mention it for reconstitution.
6. Keep the written replies in one folder together with your repository links.

Warning signs that a Git habit will hurt you in a team repository

• Committing straight to main. Switch to a branch and ask whether main is protected.
• One giant commit at the end. Reviewers cannot follow it, and a bug is hard to trace.
• Reformatting whole files. Set your IDE to match the team’s formatter so diffs show real changes only.
• Using git add . without checking. Run git status first.
• Accepting “ours” or “theirs” wholesale in a conflict. You may silently delete a teammate’s work.
• Pushing code that does not compile. Build locally first.

Frequently Asked Questions

Should I use merge or rebase to update my feature branch?

Follow whatever your team states. Merging is simpler and safer for beginners because it does not rewrite history. Rebase gives a linear history but should only be used on branches that nobody else is working on.

How often should I commit during a Java task?

Commit whenever you complete a small logical step that compiles, such as adding a method, then adding its test. Several small commits are easier to review and undo than one large one.

What if I accidentally commit a password or API key?

Tell your mentor straight away and rotate the credential. Removing it in a new commit does not erase it from history, so the secret must be treated as exposed.

Can I resolve conflicts using my IDE?

Yes. IntelliJ IDEA and Eclipse offer three-way merge tools. They are useful, but still read both versions and run the build afterwards, since the tool cannot judge intent.

Do I need to write tests before opening a pull request?

Most Java teams expect tests for new behaviour. At minimum, run the existing suite and tell reviewers what you tested. Ask your mentor what coverage they expect.

Will a Git-based internship count for credit at MUMT?

The prospectus reviewed gives no internship credit or evaluation rules, so confirm with your department in writing. CareerSwami does not offer academic credit; it provides a free offer letter and completion certificate.

How do I show my Git work to recruiters or faculty?

Share a repository or pull request link plus a short summary of what you changed and tested. Make sure you are permitted to share the code, because some internship repositories are private.

What should I do if I break the build on a shared branch?

Tell the team quickly. Revert the offending commit with git revert or push a small fix, whichever the team prefers, then add a check so it does not recur.

Related Java & Enterprise Software guides

• C.U. Shah University Students: Choosing Between a Startup and a Service Company Java Internship
• Kadi Sarva Vishwavidyalaya: A Question Bank for Core Java Viva After Your Internship
• CSVTU Students: Writing Java Internship Documentation a Reviewer Will Actually Read
• All Java & Enterprise Software internship guides