xtdb-git

Guides rebasing, conflict resolution, and merging branches into main with linear history.

3.0k|192|Updated Mar 19, 2018
One-click install
npx skills add https://github.com/xtdb/xtdb --skill xtdb-git
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: xtdb-git
Source: https://github.com/xtdb/xtdb/tree/main/.claude/skills/xtdb-git
Command: npx skills add https://github.com/xtdb/xtdb --skill xtdb-git

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Rebasing a stale branch or resolving a merge conflict risks silently reverting fixes that landed on main, and choosing the wrong merge strategy can obscure history. This Skill codifies XTDB's branch-level git practices so those decisions are made safely and consistently.

Core Features & Use Cases

  • Linear history guidance: Explains why rebasing a feature branch onto main is preferred over merging main into the branch.
  • Safe conflict resolution: Provides a step-by-step procedure — inspect intervening commits with git log, read the related PRs and issues for intent, then choose a side and trace the fixed code path end-to-end.
  • Three merge patterns: Covers GitHub squash-and-merge, committing a single reviewed change directly, and git merge --no-ff for preserving individual commits.
  • Use Case: Before rebasing a long-lived feature branch with many conflicts, follow the Skill to check each conflicting file's history on main so a competing fix is not accidentally reverted.

Quick Start

Read this Skill before rebasing a branch, resolving a rebase conflict, or merging a branch back into main in the XTDB repository.

Frequently Asked Questions about xtdb-git

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely resolve a git rebase conflict?

Run git log <merge-base>..origin/main -- <file> to find intervening commits, read their PRs and issues to understand intent, then choose a side. After resolving, trace the fixed code path end-to-end rather than only checking the conflict markers.

Should I rebase or merge main into my feature branch?

Prefer rebasing the feature branch onto main over merging main into the branch. Linear history is easier to reason about and to bisect when debugging regressions.

Why can resolving a merge conflict silently revert a fix?

Taking the branch's side of a conflict can undo a fix that landed on main after the branch forked. The risk is highest on stale branches rebased across heavily churned paths, so check each conflicting file's history on main first.

When should I use git merge --no-ff instead of squash and merge?

Use git switch main && git merge --no-ff <branch> when you want the original commits visible, such as for git blame. Squash and merge is a reasonable default, and a single reviewed commit can go straight onto main.

What topics does this git guidance not cover?

Commit messages are covered by the chalk:commit skill, ship/show/ask and code review are in dev/CODING.adoc, and issues, PRs, and the board belong to the xtdb-github skill. This Skill only covers what happens to a branch.