Software engineering practice and Git

How professional teams write, track, test and review code. Your GitHub history is the first evidence of these habits anyone sees.

Also called git commit, commit message, commit

What: A commit is a saved snapshot of your project with a message. Good commits are small, do one thing, and have a message saying what changed and why.
Why: Clear history lets you and reviewers understand changes, find when a bug appeared and undo one change safely.

Shell

git status
git add src/expenses.py tests/test_expenses.py
git commit -m "Reject negative amounts in add_expense"
git log --oneline -5

Watch out

Messages like "update" or "final final" and one giant commit at the end of a project.

Also called PR, feature branch, branch

What: A branch is an independent line of work. A pull request on GitHub proposes merging a branch into main, shows the diff and collects review comments and CI results.
Why: It is how every team works: nothing reaches main without a branch, review and passing checks. Using it on solo projects builds the habit.

Shell

git switch -c feature/monthly-report
git push -u origin feature/monthly-report
git switch main && git pull

Also called merge conflict

What: git merge combines branches with a merge commit. A conflict happens when both changed the same lines and Git needs you to choose. git rebase replays your commits on top of another branch for a straight history.
Why: Resolving conflicts calmly is a daily team skill. Rebasing your own branch before a pull request keeps history clean.

Watch out

Rebasing a branch someone else is also using, which rewrites history under them.

Also called git revert, git reset, reflog

What: git restore discards file edits, git commit --amend fixes the last local commit, git revert undoes a pushed commit with a new one, and git reflog finds commits you thought were lost.
Why: Knowing safe ways back means you can experiment without fear and fix mistakes on shared branches without breaking others.

Watch out

Committing a password or API key and only deleting it in the next commit; it stays in history, so rotate the key.

Also called test pyramid, automated testing

What: Unit tests check one function or class in isolation. Integration tests check parts working together, such as your code with a real database. The test pyramid suggests many unit tests and fewer slow end-to-end tests.
Why: Tests catch regressions before users do and let you refactor with confidence. A project with tests stands out immediately.

Watch out

Testing only the happy path and never empty input, invalid data or failures.

What: Code review is another engineer reading a change before it merges, checking correctness, readability, tests and design, and leaving comments the author responds to.
Why: It catches bugs, spreads knowledge across the team and is where most learning on the job happens. Giving and receiving reviews well is a skill employers notice.

Also called debugger, breakpoint, stack trace

What: Debugging is finding why code behaves wrongly: read the error and stack trace, reproduce the bug reliably, form a guess, and check it with a debugger, breakpoints or targeted prints.
Why: It is most of real engineering work. Debugging on your own, instead of pasting the error somewhere and copying a fix, is what builds skill.

Watch out

Changing several things at once until it works, without knowing which change fixed it.

Also called software development life cycle, Scrum, Kanban

What: The software development life cycle covers requirements, design, build, test, release and maintenance. Agile teams run it in short iterations, often with Scrum sprints or a Kanban board.
Why: You will join a team working this way. Knowing stand-ups, sprints, tickets and retrospectives makes the first weeks of an internship or job much easier.

Go deeper