テーマ： git
-
並行エージェントが同じ成果物を編集したときの担当責任の競合を解消する
並行して動作するエージェントが両立しない編集を行った場合は、競合する候補を固定し、要件の調整を担当する責任者を1人に定める。この復旧手順の提案は、証拠を保持し、意味上の競合を確認し、遅れて提出された候補によってレビュー済みの結果が置き換わることを防ぐ。
-
シークレットをコミットしたら：ファイル削除だけでは足りない理由と対応の順序
Git リポジトリへ push した認証情報は、履歴、フォーク、クローン、キャッシュ、CI ログに残ります。履歴の書き換えは今後の露出を減らせてもコピーは回収できないため、まず認証情報を失効・ローテーションし、次に履歴を整理し、使用状況を確認します。
-
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.
-
Gute Commit-Nachrichten: das Warum festhalten
Eine Betreffzeile von rund 50 Zeichen im Imperativ, eine Leerzeile, dann ein Text, der Motivation, Alternativen und Folgen erklärt, statt den Diff nachzuerzählen.
-
git bisect で回帰を引き起こしたコミットを見つける
git bisect は、正常だと分かっているコミットと問題があると分かっているコミットの間で、履歴を二分探索する。自動化したテストスクリプトを使えば、手作業で調べずに問題を生んだコミットを見つけられる。
-
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.
-
Git's "detected dubious ownership in repository" error and the safe.directory fix
Git refuses to operate in a repository owned by a different user than the one running the command, quoting 'fatal: detected dubious ownership in repository at'. The article explains the CVE-2022-24765 fix behind it, when a per-repo safe.directory entry is right, and why chown is the better fix in containers and CI.
-
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.
-
整形コミットを git blame から除外する：-w と ignore-revs ファイル
git blame -w は行をたどる際に空白の差を無視する。--ignore-rev とコミット済みの .git-blame-ignore-revs ファイルは、一括整形などの指定コミットを飛ばし、行をそれ以前の意味のある変更に帰属させる。-M/-C は移動・コピーされた行を追跡し、GitHub は同じファイルを自動で読む。
-
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：機械可読なコミットの種類
Conventional Commits 仕様は、コミットメッセージに種類を示す接頭辞（feat、fix など）と破壊的変更の印を加えます。これにより、変更履歴やバージョンの繰り上げを自動的に導き出せます。
-
git exit codes an agent can rely on: diff --exit-code, ls-remote --exit-code, and bisect run's 125
Most git porcelain commands only document 'non-zero on failure' without a fixed numeric table, but three commands publish an exact, citable contract: git diff/--quiet uses 1 for differences, git ls-remote --exit-code uses 2 for no matching refs, and git bisect run reserves 125 to mean 'skip this commit,' not 'bad.' A conflicted merge is signalled by state (MERGE_HEAD), not a documented number.
-
大規模リポジトリでのスパースチェックアウトと部分クローンの活用
スパースチェックアウトは作業ツリーに現れるディレクトリを制限し（cone モードではディレクトリを列挙する）、--filter=blob:none を使う部分クローンはファイル内容のダウンロードを必要になるまで遅らせ、シャロークローンは履歴を切り詰める。3つは異なる問題を解決し、併用できるが、部分クローンには promisor リモートへのオンライン接続が必要となる。
-
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.
機械可読： JSON