Terminal and Git

The two tools every backend task starts with: moving around a machine in a shell, and keeping every change in version control.

Terminal essentials

Also called shell, bash, command line, terminal

What: A shell runs commands such as cd, ls, cat, grep and curl, and pipes (|) feed one command's output into the next. Environment variables and exit codes carry state between commands.
Why: Servers, containers and CI all run in a shell, so reading logs, testing an endpoint with curl or checking a port happens here long before any dashboard.

Shell

ls -la                        # list with permissions
grep -rn "TODO" src/          # search the codebase
curl -i localhost:3000/health # status line and headers
echo $?                       # exit code of the last command
export PORT=8080              # env var for child processes

Watch out

Pasting commands with sudo or rm -rf from the internet without reading what they do.

Git commits and branches

Also called git, version control, commit

What: Git records snapshots of your project as commits. A branch is a movable pointer to a commit, so you can build a feature on its own branch and merge it when it works.
Why: Every team ships through Git. Small, well-described commits make bugs easy to find with git log and git bisect, and changes easy to review or revert.

Shell

git switch -c add-orders-endpoint
git add -p                 # stage hunks, not whole files
git commit -m "Add POST /orders with validation"
git push -u origin add-orders-endpoint

Watch out

Committing a .env file or a key. Once pushed, rotate the secret: deleting the file does not remove it from history.

Pull requests

Also called PR, merge request, code review

What: A pull request proposes merging a branch into main and shows the diff, CI results and review comments in one place.
Why: It is where the team checks behaviour, tests and naming before code reaches production, and where you learn fastest from feedback.
Example: A good description says what changed, why, how it was tested and what the reviewer should look at first.

Watch out

One huge pull request that mixes a refactor with a feature, which nobody can review properly.