DevOps Engineer · Step 3 of 8 · 8 min
Git and code review
Use branches, commits and pull requests the way teams do, and review changes usefully.
Git is the record of every change
Git tracks every change to code and configuration: who changed what, when and why. In DevOps, everything that defines a system should live in Git, including infrastructure and pipeline files. If it is not in Git, it is hard to review, repeat or roll back.
The daily loop
Clone a repository, create a branch, make a small change, commit it with a clear message, push it, and open a pull request. Others review it, automated checks run, and it is merged into the main branch.
Keep commits small and messages useful: what changed and why, not just fix. Learn git status, git diff, git log, and how to resolve a merge conflict calmly.
Reviewing well
Code review catches bugs, spreads knowledge and keeps standards consistent. Good reviews ask: does this do what it says, what could break, is it tested, and could someone else run it in a year.
Be kind and specific. Comment on the code, not the person. Small pull requests get better reviews; a change of 2,000 lines usually gets a quick approval and no real review.
Protect the main branch
Most teams require a review and passing checks before anything merges to main. Turn this on in your own projects too. Never commit passwords or keys; once pushed, assume they are public and revoke them.
Try it
Make and review your first pull request
- 1.Create a free GitHub or GitLab account and a new public repository with a README.
- 2.Install Git locally, clone the repository, and create a branch.
- 3.Edit the README, commit with a clear message, push, and open a pull request.
- 4.Read your own diff as a reviewer and leave one comment before you merge.
Here is a diff from my pull request: [paste diff, with no secrets]. Review it like a careful senior engineer. List risks, missing tests and unclear names, ordered by importance.