← ClaudeAtlas

git-workflowlisted

Hands-on Git workflows: resolve merge/rebase conflicts with a documented rationale, generate professional Conventional-Commit messages from the actual diff, and author complete CI/CD GitHub Actions pipelines. TRIGGER when the user says 'resolve the merge conflicts in this branch and explain what you kept from each side', 'commit these changes with a message that summarizes what I did', 'write a GitHub Actions workflow that runs tests, builds, and deploys to staging on push to develop', or similar. Hebrew: 'תפתור את הקונפליקטים', 'תסביר מה שמרת מכל צד', 'תעשה commit עם הודעה טובה', 'תכתוב workflow ל-GitHub Actions', 'CI/CD', 'pipeline של דיפלוי'. Follows the global Git Hygiene rules (atomic commits, conventional messages). NOT for routine `git status`/`git log` questions — just answer those directly.
hiyabh/claude-skills · ★ 0 · Code & Development · score 66
Install: claude install-skill hiyabh/claude-skills
# Git Workflow — Conflicts · Commits · CI/CD ## Purpose Three focused Git workflows, each done end-to-end by Claude (never hand a git command back to the user — run it): - **Conflict resolution** with a decision log. - **Commit message** authoring from the real diff (Conventional Commits). - **CI/CD pipeline** authoring for GitHub Actions. **Language:** explanations in Hebrew; commit messages, YAML, and code in English. --- ## Workflow A — Resolve merge/rebase conflicts (with documented decisions) Trigger: "resolve the merge conflicts in this branch and explain what you kept from each side". 1. **Survey** — `git status` to list conflicted files; `git log --oneline --left-right --merge` and `git diff` to understand both sides. Know which branch is "ours" vs "theirs" and what each was trying to do. 2. **Resolve each hunk on merit**, not mechanically: - Understand the intent of both sides before choosing. - Prefer a resolution that keeps *both* intents when they're compatible (e.g. two independent additions) rather than dropping one. - Never blindly take one side across the board. - Watch for semantic conflicts that aren't textual (both sides compile, logic still breaks) — reason about behavior, not just markers. 3. **Remove all conflict markers**, then verify: build + run the test suite. A "resolved" branch that doesn't compile isn't resolved. 4. **Document the decisions** — for each conflicted file, one line: what you kept from each side