Git Workflow, History & CI/CD
The moment more than one person works on a repository, the center of gravity shifts from the commit to the history and the process for integrating change. Here Git turns from a save tool into a collaboration tool — with its own sharp edges. Rewriting history (rebase, amend) is convenient locally and dangerous on a shared branch. Rescue tools (reflog, bisect, cherry-pick) pull you out of situations that look like a disaster. And CI/CD automates what used to be manual: checking, building, and delivering.
The principle everything here revolves around: any operation that changes a commit's SHA is only safe while the commit is private. rebase, amend, cherry-pick create new commits with new hashes; the old ones become unreachable. Locally that is a cleanup before you push. On a branch someone has already pulled, it is sabotage — their history diverges from yours. Understanding this splits "before push" from "after push" and makes the whole team process predictable. The full map lives in the layers below.
Topic map
- Rebase vs merge — how
rebasemoves commits and changes SHAs, how it differs frommerge, why it is dangerous on a shared branch. - Rewriting history —
amend,fixup, interactiverebase; why it requires a force-push and when it is acceptable. - Rescue tools —
reflog,bisect,cherry-pick, git hooks; how to recover "lost" work and find the commit that broke things. - Team process — the pull-request lifecycle, Conventional Commits, annotated vs lightweight tags, branching strategies.
- CI/CD — what continuous integration and delivery are, what a pipeline is made of, what guarantees it gives.
- Submodules and monorepos — how
git submodulepins a dependency to a commit, the alternatives, monorepo vs polyrepo.
Common traps
| Mistake | Consequence |
|---|---|
rebase of an already-pushed, shared branch | SHAs change; teammates' history diverges from yours — merge chaos on their next push |
amend/rebase without realizing a force-push is needed | A plain push is rejected (non-fast-forward); a blind force-push overwrites others' commits |
Treating cherry-pick as free copying | It creates a new commit with a new SHA; a later merge of the same branch yields a duplicate or conflict |
Relying on reflog as a backup | reflog is local and expires (~90 days by default); it does not exist on another machine |
Forgetting git submodule update --init | The wrong (or empty) dependency version is built — a submodule is pinned to a specific commit |
| A lightweight tag for a release | No author, date, or message; releases need an annotated tag (git tag -a) |
| CI without required checks on merge | A red main — broken commits merge because the pipeline does not block the merge |
git commit --amend on someone else's commit in a PR | Changes the authorship/SHA of another's work; breaks commit links in the discussion |
Interview relevance
Here the interviewer is checking your maturity working on a team. The key dividing line is whether you understand that history-rewriting operations are only safe before a commit is published. "Rebase is better because the history is linear", with no caveat about shared branches, is a warning sign.
Typical checks:
rebasevsmerge— how each affects the shape of history and the SHAs, and why rebasing a shared branch is dangerous.- What
amendandfixupdo and why a force-push is needed afterward. - How
reflogrescues "lost" commits and why it is not a backup. git bisectto find the breaking commit inO(log n)steps.- How
cherry-pickdiffers frommerge/rebaseand when it is appropriate. - The pull-request lifecycle and what makes it easy to review.
- What CI/CD is and what guarantees a pipeline gives.
Common wrong answer: "Always rebase instead of merge — the history is cleaner". That opens the discussion that rebase rewrites SHAs, so it is not acceptable on a branch teammates have already pulled — there you need merge.