Git is version control — a history of every change to your project. Mess something up? Go back. Working with others? Merge your changes without emailing zip files. Git lives on your computer; GitHub, GitLab, and Bitbucket host copies online so teams collaborate.
The mental model is simple. A repo holds your project. Commits are saved snapshots with messages explaining what changed. Branches let you work on a feature without breaking the main code. `main` (or `master`) is usually production-ready; feature branches are where experiments happen.
Daily commands you will actually use: `git clone` to copy a repo, `git pull` to get updates, `git add` and `git commit` to save your work, `git push` to upload, `git checkout -b my-feature` to start a branch. Merge or open a pull request when the feature is ready. That loop is 90% of professional Git.
Pull requests (PRs) on GitHub are where review happens. Push your branch, open a PR, describe what you did, ask teammates to look. CI tests run automatically on many teams. Merge when approved. Good commit messages and small PRs get faster reviews than a thousand-line mystery dump.
Conflicts happen when two people edit the same lines. Git marks them; you choose what to keep. Pull often to reduce pain. `.gitignore` tells Git to skip `node_modules`, `.env`, and build folders — never commit secrets or huge dependency folders.
Learn Git before you need it in a crisis. Make a test repo, break things on purpose, practice branches and reverts. Git feels picky at first; after a month it becomes muscle memory and you will wonder how anyone shipped software without it.