OP1 week ago
I do a lot of resume reviews for juniors and one thing I notice constantly, final year students who've built decent projects but have literally zero understanding of Git beyond "git add, git commit, git push" that they copy-pasted once from a tutorial. That's a problem in interviews, because almost every technical round now asks at least one Git question, and "I just push everything" is an instant red flag to interviewers.
Here's the minimum I think every CS/IT student here should actually understand before final year placements, not just be able to type from memory.
First, understand what a commit actually is, it's a snapshot of your project at a point in time, not just a "save button." Each commit has a message, and that message should describe what changed and why, not just say "update" fifty times in a row, which is genuinely one of the most common things I see on student GitHub profiles and it looks bad to anyone reviewing your work.
Second, branches. A branch lets you work on a new feature or fix without touching your main, working code. The real-world pattern is: your main branch always has stable, working code; you create a new branch for each feature or bug fix; once it's tested and working, you merge it back. If you're currently doing all your project work directly on main, start practicing branches now on a personal project, it's a five-minute habit change that instantly makes your workflow look professional.
Third, and this is the one almost nobody practices until it bites them, merge conflicts. This happens when two people (or you, working on two branches) change the same lines of the same file. Git can't automatically decide which version is correct, so it asks you to resolve it manually. If you've never intentionally caused and resolved a merge conflict, do it on purpose with a friend on a shared repo, pick the same line in the same file, both edit it differently, push, and work through resolving it. This exact scenario gets asked in interviews constantly, and having actually done it once makes explaining it in an interview completely natural instead of a memorized textbook answer.
Fourth, a proper .gitignore file. I still see repos on GitHub with node_modules folders committed, or .env files with actual API keys sitting in plain sight in public repos. Both are bad: one bloats your repo for no reason, the other is a genuine security problem if that key is real and active.
Lastly, write a proper README for every project, what it does, how to run it locally, what tech stack you used. This is often the first thing a recruiter or interviewer looks at before even opening your code, and a project with zero README makes a much worse first impression than the actual code quality deserves.
None of this takes more than a weekend to properly practice. If someone wants, I can put together a short practice exercise covering all of this with a partner-based merge conflict scenario.
💻
techbhai
Tech Member
Sharing programming, web dev, and hardware tips on Hyd.Circle.
Login to join the discussion.