Tema: git
-
Tags and releases: lightweight versus annotated tags and how they travel
A lightweight tag is only a name for a commit; an annotated tag is an object with tagger, date, message and optional signature, which is why git describe ignores lightweight tags by default and why releases should use annotated or signed tags; tags are not pushed with branches unless --follow-tags or --tags is used, and a published tag should never be moved.
-
At what repository size do teams need monorepo build tooling beyond plain Git?
Open question: sparse checkout, partial clone and per-directory CI filters cover the first stage of a growing single repository; at which size, team count or build time have teams found that a build graph tool with remote caching became necessary, and what did the transition cost?
-
Describing a change so that reviewers can review it
A change description states the problem, the approach and its alternatives, how it was tested and what reviewers should look at; it links the ticket and lists risks and follow-ups, so review starts with understanding instead of archaeology.
-
How do teams run several coding agents in parallel git worktrees without their caches, hooks and ports colliding?
Open question: worktrees give each agent its own branch and files, and the git-worktree documentation says a linked worktree shares everything except per-worktree files such as HEAD and the index, so hooks and configuration are shared while build caches, dependency directories and local ports are often hard-coded; which conventions have kept parallel agent runs isolated, and what broke first?
-
Cherry-picking: when it fits and what it costs the history
git cherry-pick replays the change of a commit as a new commit with a different ID; it is the right tool for backporting a fix to a maintenance branch or salvaging one commit from an abandoned branch, but each pick creates a duplicate that merges cannot recognise, so record the origin with -x and merge instead of picking when the whole branch is wanted.
-
Recovering lost commits and branches with the reflog
The reflog records every movement of HEAD and of each branch in the local repository, so a bad reset, rebase, amend or branch deletion can be undone by finding the earlier position and putting a new branch on it; entries expire after 90 days (30 for unreachable ones) by default, and uncommitted changes were never in it.
-
Finding the commit that introduced a regression with git bisect
git bisect performs a binary search over history between a known-good and a known-bad commit; with an automated test script it finds the offending commit without manual inspection.
-
Changes that touch tests and code together are reverted less often than code-only changes of similar size
Hypothesis: a change that modifies or adds tests alongside its code has been exercised at least once by its author in the way the tests describe, so it is followed by a git revert or a corrective commit less often than a code-only change of the same size and area; a proposed test on repository history with matching on size.
-
Rebase or merge: integrating a branch
Merging preserves history as it happened and adds a merge commit; rebasing rewrites a branch onto a new base for a linear history. Never rebase commits that others have based work on.
-
Signing commits and tags with an SSH key or GPG
Git signs commits and tags with OpenPGP, X.509 or, since gpg.format=ssh, a plain SSH key; the signer sets gpg.format and user.signingKey, verifiers need an allowed-signers file (SSH) or a trusted key ring (GPG), and forges are checked with git verify-commit or the host's signature badge.
-
Keeping reformatting commits out of git blame: -w and ignore-revs files
git blame -w ignores whitespace when tracing lines, --ignore-rev and a committed .git-blame-ignore-revs file skip named commits such as mass reformattings so lines are attributed to the previous meaningful change, and -M/-C follow moved or copied lines; GitHub reads the same file automatically.
-
Stashing safely: messages, untracked files and stash branches
A stash is a commit stored under refs/stash whose older entries live only in that ref's reflog; give each stash a message, include untracked files deliberately, prefer apply over pop until the result is verified, and use git stash branch when the base has moved on.
-
Conventional Commits: machine-readable commit types
The Conventional Commits specification adds a typed prefix (feat, fix, and others) and breaking-change markers to commit messages so that changelogs and version bumps can be derived automatically.
-
Working in a large repository with sparse checkout and partial clone
Sparse checkout limits which directories appear in the working tree (cone mode lists directories), partial clone with --filter=blob:none delays downloading file contents until they are needed, and shallow clone truncates history; the three solve different problems and combine, but partial clone needs the promisor remote online.
-
Mit git bisect den verursachenden Commit finden
git bisect sucht binär zwischen einem bekannten guten und einem schlechten Commit; mit einem Prüfskript findet es den ersten fehlerhaften Commit ohne manuelles Ausprobieren.
-
Choosing a Git branching workflow
How long-running and topic branches combine into a workflow, and which questions decide between trunk-based, feature-branch and release-branch models.
-
Linear history shortens regression diagnosis
Hypothesis: teams with a linear, squash- or rebase-based integration history locate regressing commits faster with bisect than teams with merge-heavy histories, because each step is a coherent, buildable change.
-
Writing commit messages that explain why
A short, testable format for commit messages: a summary line under about 50 characters, a blank line, and a body that explains motivation and consequences rather than restating the diff.
-
Removing large binaries from Git history with git filter-repo
A repository stays large after a big file is deleted because every clone carries its history; shrinking means finding the offending blobs, rewriting all commits that contain them with git filter-repo in a fresh clone, force-pushing every branch and tag, and having everyone re-clone, because rewritten commits have new IDs.
-
.gitattributes: line endings, diff drivers, merge drivers and export-ignore
A committed .gitattributes file settles per-path behaviour for the whole team: text=auto and eol normalise line endings, diff= assigns hunk-header patterns or textconv for binaries, merge= picks a driver such as union, binary marks files to leave alone, and export-ignore keeps paths out of git archive.
Legible por máquina: JSON