Version control tools track how a project changes over time, and Git is the one you'll run into almost everywhere. It has a large surface area, but you don't need most of it to work effectively — a small set of commands, understood properly, covers the vast majority of day-to-day use.
Commit in small, meaningful chunks
A commit is a saved snapshot of your project, with a message describing what changed. Committing often, in small logical chunks — "add login form validation" rather than one giant commit at the end of the week — makes it far easier to find when a specific bug was introduced later.
Branches are for trying things safely
A branch lets you work on a change without touching the main version of the project until you're ready. This means you can experiment, make mistakes, and throw work away without any risk to the code everyone else depends on.
Understand what a merge conflict actually is
A merge conflict happens when two changes touch the same lines in incompatible ways, and Git can't decide which one should win. It looks alarming the first time, but it's just Git asking you to pick — read both versions, decide what the final result should be, and mark it resolved.
Write commit messages for a future reader
Six months from now, "fix bug" tells you nothing. "Fix off-by-one error in pagination when the last page has one item" tells you exactly what to expect if you're looking through history to understand why something changed.
Almost everything else — rebasing, cherry-picking, more advanced history rewriting — can be learned later, when a specific situation actually calls for it. Commit often, use branches for anything experimental, and write messages for a reader who has forgotten the context, and you'll be ahead of a lot of the confusion people run into.