Page 2 of 2
Two tools for figuring out why code looks the way it does.
git blame file.py # shows which commit last touched each line, and who
blame is often the fastest way to find who to ask about a confusing piece of code, or which commit introduced it.
git bisect start
git bisect bad # current commit has the bug
git bisect good v1.2.0 # this earlier tag was fine
# Git checks out a commit halfway between - you test it and report:
git bisect good # or
git bisect bad
# repeat - Git binary-searches down to the exact commit that introduced the bug
bisect turns "somewhere in these 400 commits a bug appeared" into a handful of test-and-answer steps, which is dramatically faster than checking commits one at a time.
Local branches can be linked to a remote branch so push/pull know where to go without you specifying it every time.
git push -u origin feature-x # -u sets up tracking, future push/pull need no args
git branch -vv # shows each local branch and what it tracks
git fetch downloads remote changes without merging them into your working branch - it's the safe, look-before-you-leap counterpart to git pull, which is really just fetch followed immediately by merge.
git fetch origin
git log main..origin/main # see exactly what's new on the remote before merging it
A tag is a permanent, named pointer to a specific commit, typically used to mark releases (v1.0.0).
git tag v1.0.0 # lightweight tag on the current commit
git tag -a v1.0.0 -m "First release" # annotated tag, stores message/author/date
git push origin v1.0.0 # tags aren't pushed automatically - explicit step
Unlike branches, tags aren't meant to move - once v1.0.0 points at a commit, it should stay there permanently, so anyone can check out exactly what was released.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.