Backend code changes constantly: new endpoints, database migrations, bug fixes. Without version control, you cannot reliably undo changes, compare versions, or collaborate. Git is the standard: it tracks every change in a repository (repo) so you have a full history and can branch to try ideas without breaking the main line.

GitHub (or GitLab, Bitbucket) hosts your repo in the cloud, adds pull requests (PRs), issues, and CI/CD integration. Most teams use Git + a host; learning both is essential.

A commit is a snapshot of your project at a point in time. You stage changes with git add, then git commit with a message. Each commit has a unique hash and lives in the history forever.

A branch is a movable pointer to a commit. You create a branch (e.g. feature/add-login) to work on a change, make commits there, then merge or rebase back into main (or master). This keeps main stable while you experiment.

Remote is the copy of the repo on the server (e.g. origin on GitHub). You push your branches to the remote and pull others’ changes. git pull is usually fetch plus merge in one step.

Clone the repo (git clone), create a branch for your task (git checkout -b feature/orders-api), make changes, commit often with clear messages (git add, git commit -m "Add POST /orders"). Push the branch (git push -u origin feature/orders-api) and open a pull request on GitHub.

Teammates review the PR; CI runs tests. Once approved, you merge into main. Then pull the latest main locally (git checkout main, git pull) and delete the feature branch. Start the next task from an up-to-date main.

When two branches change the same lines, Git reports a merge conflict. Open the files, look for conflict markers (<<<<<<<, =======, >>>>>>>), choose the correct code (or combine both), remove the markers, then git add and git commit to complete the merge.

Rebase (e.g. git rebase main) replays your commits on top of the latest main, giving a linear history. Use it for cleaning up before merging; avoid rebasing shared branches. Merge is safer for shared branches and keeps an explicit merge commit.

Commit small, logical units: one fix or one endpoint per commit. Write messages that explain why (e.g. "Add rate limiting to prevent abuse" not just "Update API").

Protect main: require PR reviews and passing CI before merge. Use branch protection on GitHub so no one pushes directly to main. Keep main deployable so you can release at any time.