I had used Git for personal projects before joining a team, and I thought I knew how it worked: you make changes, you commit, you push. That model is fine for solo work, where the only person you're coordinating with is yourself. In a team setting, Git becomes a completely different tool, because its primary function shifts from backup to communication. Every commit message, every branch name, every pull request is a message to your teammates about what you did and why, and the quality of those messages directly affects how quickly your team can review, merge, and build on your work.

My first week on a real team, I committed directly to the main branch, didn't write commit messages beyond "fix," and pushed changes without telling anyone. None of these things broke anything, but they made me a liability to the team — my changes appeared in the shared branch without warning, my commit messages were useless for understanding what changed, and the senior engineers had to spend time educating me on the workflow they expected. That education was patient and thorough, and it instilled habits that I still rely on: always branch, always write descriptive commit messages, always open a PR for review, always coordinate before merging.

The most important habit I learned was writing good commit messages. A commit message that says "fix" tells the reader nothing; a commit message that says "fix null reference in order form when optional field is blank" tells the reader exactly what changed and why. That level of detail matters because future developers — including future you — will need to understand the change, and `git log` is the primary way they'll do it. A good commit message answers two questions: what does this change do, and why was this change necessary? If you can't answer both in a few sentences, you might not understand the change well enough to be committing it.