Git for designers: rebase, amend, and how to earn engineering trust

Most designers interact with git through a GUI—if at all. I use git from the terminal every day: rebasing branches, amending commits, resolving merge conflicts, and keeping a clean history before opening a pull request. It started out of necessity—working directly in codebases alongside engineers—but it’s become one of the most valuable skills in my toolkit as a design leader. Git literacy is the single fastest way to change how engineering perceives design: from “the person who sends Figma links” to “the person who ships alongside the team.” That shift in perception is worth investing in.

Why git matters for designers working in code

Git is the lingua franca of software development. Every codebase that engineering teams build and maintain is tracked in git. Every change, every fix, every feature—it’s all in there, with a record of who changed what and why. When you work directly in the codebase alongside engineers, not knowing git means you’re working with one hand tied behind your back.

For design directors and design engineers specifically, git literacy enables three things that matter at the leadership level:

Direct codebase participation. When you can branch, commit, and push changes yourself, you can fix small front-end issues directly instead of creating tickets and waiting. A spacing fix, a color token update, a missing hover state—these can be a three-minute git task instead of a multi-day engineering ticket. The engineering team sees you contributing directly, which changes the relationship.

Meaningful PR reviews. Reviewing pull requests for visual and interaction fidelity is one of the most high-leverage practices a design director can adopt. But you can only do this effectively if you understand what you’re looking at in the git diff, can check out the branch and run it locally, and can suggest specific code changes when you spot issues.

Credibility in engineering conversations. When you understand branching strategies, rebase flows, and release management, you can participate in sprint ceremonies and architecture discussions as a peer, not a visitor. This isn’t about technical ego—it’s about removing the friction that comes from having a design leader who speaks a fundamentally different language than the engineering team.

The git commands designers actually need

You don’t need to be a git expert to be effective. You need fluency with about ten commands and a deep understanding of three concepts: branching, commit hygiene, and rebase.

Branching:

git checkout -b feature/update-card-component    # Create and switch to a new branch
git checkout main                                 # Switch back to main
git branch -d feature/update-card-component      # Delete a branch after merge

Every unit of work—a component update, a design token change, a layout fix—gets its own branch. This keeps your work isolated, makes review easy, and lets you switch context without losing work in progress.

Commit hygiene:

git add -p                                        # Stage changes interactively (review before adding)
git commit -m "fix: update card border-radius to 8px per design spec"
git commit --amend                                # Fold a small fix into the last commit

Commit messages are communication. “Fix stuff” is noise. “fix: update card border-radius to 8px per design spec” tells the reviewer exactly what changed and why, without opening the diff. The amend command is useful when you’ve just committed and immediately notice you forgot something small—instead of adding a “oops forgot” commit, you fold the fix into the previous commit cleanly.

Rebase:

git rebase main                                   # Rebase your branch onto the latest main
git rebase -i HEAD~4                              # Interactively rebase the last 4 commits

Rebase is the command that separates functional git users from fluent ones. When you’ve been working on a branch for a few days and main has moved forward, rebasing brings your work up to date while keeping the history clean. Interactive rebase (-i) lets you squash multiple “work in progress” commits into a single clean commit before opening a PR. Engineers reviewing your PR see a coherent set of changes, not a changelog of your thought process.

How do you keep a clean commit history on a design branch?

Clean commit history is the thing that makes PR reviews fast and pleasant for the engineering team. The principle is simple: by the time you open a PR, your commits should tell a coherent story of what changed and why. The work-in-progress commits—“wip,” “fix typo,” “trying this,” “reverting last change”—should be cleaned up before anyone sees them.

The workflow I use:

1. Work on the branch freely, committing as often as useful. Don’t worry about message quality during active work.
2. Before opening a PR, run git rebase -i main to bring the branch up to date and enter the interactive rebase editor.
3. In the interactive editor, squash or fixup the noise commits into the meaningful ones. End up with two to five commits that each represent a coherent unit of change.
4. Write final commit messages that would be useful to someone reading the git history in six months.
5. Force-push the cleaned branch (git push --force-with-lease), then open the PR.

The result: a PR that’s easy to review, a git history that’s useful as documentation, and an engineering team that genuinely appreciates having a design collaborator who respects their workflow.

For how this connects to the broader branching strategy for design-engineering teams, branching strategies for design-engineering collaboration covers the naming conventions and PR patterns in more depth.

Handling merge conflicts without fear

Merge conflicts are the thing that makes most non-technical designers avoid the terminal entirely. They look cryptic the first time, but the pattern is simple once you’ve seen it twice.

A conflict happens when two branches modify the same line of the same file. Git can’t automatically decide which version to keep, so it marks both and asks you to choose:

<<<<<<< HEAD
  padding: 16px 24px;
=======
  padding: 12px 20px;
>>>>>>> feature/tighten-card-padding

Everything above ======= is your version. Everything below is the incoming change. You delete one, delete the conflict markers, and save the file. Then:

git add <resolved-file>
git rebase --continue

Most conflicts in design work are in CSS, design token files, or component files—concrete, visual values where the right resolution is usually obvious from context. The harder conflicts are in configuration files or component logic, where you might need to ask an engineer. But recognizing what kind of conflict you’re in and being able to resolve the simple ones yourself is a significant capability jump.

Git GUIs vs. terminal: which should designers use?

Both are valid, and the right choice depends on your level of investment. Git GUIs (GitHub Desktop, Fork, Sourcetree, Tower) are excellent for everyday branching, committing, and pushing. They make the common operations fast and visual. I use a GUI for some operations even now—it’s faster than typing for certain things.

The terminal becomes necessary when you need to:

• Run interactive rebase (git rebase -i)
• Resolve complex rebase conflicts
• Do targeted staging (git add -p)
• Run scripts or automation alongside git commands
• Work on a remote server over SSH where no GUI is available

My recommendation: start with GitHub Desktop for the basics, learn the terminal commands in parallel, and gradually shift more operations to the terminal as you get comfortable. Don’t let the terminal feel like a barrier—most git operations are a single line.

What happens when your engineering team sees you in the git log

The trust shift that happens when engineers see a design director in the git history—opening PRs, committing small fixes directly, rebasing before review—is genuinely meaningful. It signals something important: design understands and respects the engineering workflow. Design is a participant in the production process, not just a supplier of upstream artifacts.

That shift compounds. Engineers start asking design for input earlier. They stop making silent UI judgment calls because they know design is in the same tools and will see it. They start treating design reviews as collaborations rather than approvals. The cultural change starts from a technical practice—and the technical practice starts with learning git.

For how this connects to the day-to-day embedding practice in engineering teams, how I embed in engineering teams as a design director covers the sprint rituals and PR review practices that build on this foundation.

Key Takeaways

• Git literacy shifts design’s relationship with engineering from “supplier of Figma links” to “participant in the production process”—this is worth investing in
• The ten commands you need: checkout -b, add -p, commit, commit --amend, push, pull, rebase, rebase -i, merge, log
• Clean commit history is a professional courtesy: squash WIP commits with interactive rebase before opening a PR
• Merge conflicts follow a predictable pattern—learn to resolve the simple ones (CSS, tokens, component values) yourself; ask engineers for the complex ones
• Start with a GUI for daily operations, learn the terminal commands in parallel, and shift gradually as comfort builds