I85PREP
⌘ K
Google IT Automation with Python study materials
Google IT Automation with Python study resources

Google IT Automation with Python: Version control with Git and GitHub collaboration workflows

Google IT Automation with Python · Work through your exam, one topic at a time.

All guide sections

Version control with Git and GitHub collaboration workflows

Version control with Git and GitHub collaboration workflows

This domain tests whether you understand Git's object and branch model well enough to collaborate safely: staging changes, committing coherent units, branching, merging, resolving conflicts, and using GitHub pull requests and reviews. Expect scenario questions about recovering from mistakes and about which command changes local versus remote state.

Core rules and concepts

  • The working tree, staging area, and repository are separate. git add stages; git commit records the staged snapshot. git status shows all three states; git diff shows unstaged changes, while git diff --staged shows what will be committed.
  • A branch is a movable pointer to a commit. git switch -c feature creates and switches; git switch main returns. Commits are local until git push.
  • git fetch downloads remote refs without changing your working tree. git pull is fetch plus merge or rebase, depending on configuration. Pull before pushing to avoid a non-fast-forward rejection.
  • Merge preserves history and can create a merge commit. Rebase rewrites commits onto a new base and produces a linear history; never rebase commits that others have already pulled.
  • A GitHub pull request proposes merging a branch. Reviewers comment on lines, checks run, and protected branches can require approvals. Forking creates your own copy; cloning copies a repository locally.
  • .gitignore prevents untracked files from being added. It does not untrack a file already committed; use git rm --cached for that.

Worked example

You are on main, need to fix a typo, and must not disturb a teammate's work.

git switch -c fix-readme-typo
# edit README.md
git add README.md
git commit -m 'Fix README typo'
git push -u origin fix-readme-typo

Then open a pull request from fix-readme-typo into main. Reasoning: the branch isolates the change; the commit contains only the intended file; -u sets upstream tracking so later pushes are shorter. If main moved while you worked, fetch and merge or rebase your branch, resolve conflicts locally, test, then push again.

Traps that cost marks

git reset --hard discards local changes and is a poor first response to a mistake. git checkout -- file also discards edits. Force-pushing a shared branch rewrites history for everyone. Committing secrets is hard to undo because history retains them. Merge-conflict markers (<<<<<<<, =======, >>>>>>>) must be removed and the result tested. A detached HEAD is not on a branch; create a branch before committing if you want to keep work.