💬 What I keep seeing on student Git profiles during resume reviews

I review a lot of resumes for juniors, and the same thing keeps coming up. Final year students with decent projects who know Git only as add, commit, push, copied once from a tutorial. Almost every technical interview asks at least one Git question now, and "I just push everything" does not go down well. The first thing I look at is commit messages. A commit is a snapshot of your project, not a save button, and fifty commits that all say update look bad. Second is branches. Keep your main branch working, make a new branch for each feature or fix, and merge it back when it is tested. If you do all your work on main right now, start using branches on a personal project this week. The third one nobody practises until it bites them, which is merge conflicts. Do one on purpose with a friend. Edit the same line of the same file differently, push, and resolve it together. When an interviewer asks about it, you will explain it naturally instead of reciting a textbook. Fourth, a proper .gitignore. I still see public repos with the node_modules folder committed, or an .env file with a real API key in it, and that second one is a real security problem. Last, a README for every project. What it does, how to run it, what you used. It is often the first thing a recruiter opens. None of this takes more than a weekend. If people want, I can put together a practice exercise with a partner merge conflict.

I only learned branches in my second year, and I wish a senior had shown me earlier. The merge conflict part is true. The first time I saw those strange symbols in my file I panicked. A friend and I did the practice you describe, both editing the same line, and it stopped scaring me.

Knowing Git commands and understanding Git are different things. In my first job I could run commit and push, but I froze at a merge conflict in the second week. A senior sat with me for 20 minutes and showed me branching and .gitignore, and that taught me more than any tutorial. For interviews, be ready to explain your own workflow in plain words, not just the commands.