Y

Git and GitHub · Beginner

Everyday Git in fifteen commands

3 min read

Why it matters

Git appeared in 86% of the DevOps job descriptions we read and across every other engineering role. It is also how reviewers see your work: a GitHub profile with small, well-described commits says more about your habits than a CV line.

The concept

Git records snapshots of your project called commits. Three places matter:

  • the working directory: files as you edit them

  • the staging area: changes you have chosen for the next commit (git add)

  • the repository: the history of commits (git commit)

A branch is a movable name for a line of commits. A remote (usually origin on GitHub or GitLab) is another copy of the repository you push to and pull from.

Worked example: a small report project

everyday.sh
git init trips-reports && cd trips-reports
git config user.name "Asha" && git config user.email "asha@example.com"
git switch -c main

printf 'select count(*) from trips;\n' > report.sql
git status                               # report.sql is untracked
git add report.sql                       # stage it
git commit -m "Add trip count report"    # snapshot it

# Connect to an empty repository created on GitHub, then publish
git remote add origin git@github.com:your-name/trips-reports.git
git push -u origin main

# Work on a change in its own branch
git switch -c feature/zone-report
printf 'select PULocationID, count(*) from trips group by 1;\n' > zones.sql
git add zones.sql
git commit -m "Add trips per pickup zone"
git push -u origin feature/zone-report   # then open a pull request on GitHub

# See what happened
git log --oneline --graph --all
git diff main..feature/zone-report

Good commit messages start with a verb in the imperative and say what changed and why in one line: "Exclude refunds from trip count", not "update" or "fix stuff". Keep each commit to one logical change so it can be reviewed and, if needed, reverted on its own.

A .gitignore file keeps secrets and generated files out of history:

.gitignore
.env
*.parquet
__pycache__/
.venv/

Common mistakes

  • Committing secrets. Removing a key in a later commit does not remove it from history. Rotate the key, then clean history.

  • Giant commits that mix formatting, features and fixes. Reviewers cannot follow them.

  • Working directly on main. Use a branch for every change, even small ones.

  • Committing data files. Large or sensitive data belongs in storage, not in Git.

Interview angle

"What is the difference between git fetch and git pull?" Fetch downloads remote changes without touching your branch; pull is fetch plus merge (or rebase). Mention that you fetch and inspect first when unsure.

Practice task

  1. Create a public repository for one of your projects with a README, a .gitignore and at least five meaningful commits.

  2. Make a change on a branch, open a pull request against your own main, review it yourself and merge it.

  3. Use git log -p report.sql to read the full history of one file.

Further reading