Tag
git
Published articles tagged git.
A short history of Git
Git began in 2005 when the Linux kernel lost BitKeeper and needed a new distributed version control system fast. This overview follows Linus Torvalds' design goals, Junio Hamano's long stewardship, GitHub's rise, and the defaults and hash algorithms teams use today.
Advanced Git
Revision syntax, log search, blame, reflog, history filtering, bisect, worktrees, hooks, and rerere—for when everyday commands are not enough to find a commit, recover a lost branch, or automate repository policy.
Code review and pull request hygiene
Good pull requests are small, test-backed, and easy to revert; good reviews focus on design and risk, not style nitpicks. Practices for authors and reviewers when Git history is shared on a protected main branch.
Collaborating with Git
Git stores history; teams add agreements on top—who merges, how branches are named, and how review happens before code reaches main. This overview maps those social layers to remotes, pull requests, and protected branches.
Everyday Git commands
Configure identity, create commits, inspect history, manage branches, and ignore build artifacts—the commands you use on most working days. Assumes you know how Git's working tree, index, and repository fit together.
Git cheat sheet
Scannable Git commands for daily work—config, commits, branches, remotes, undo, and merge—grouped for quick lookup beside the Git and GitHub series.
Git glossary
Git and GitHub terms used across the series—blob, index, rebase, pull request, and more—each defined briefly and linked to the chapter that explains the idea in depth.
Git workflows for teams
Trunk-based development, Git Flow, and GitHub Flow compared—how branch lifetimes, release cadence, and CI maturity drive the model, plus scaling patterns for monorepos and open source.
GitHub Actions
GitHub Actions runs workflows on Git events—push, pull request, schedule— using YAML in .github/workflows. This overview covers jobs, steps, runners, reusable actions, secrets, matrices, caching, and a complete Node CI pipeline you can adapt.
How Git works
Git tracks snapshots of your project as commits linked in a graph, not as a single linear tape of diffs. This page explains what version control is solving, the four areas where your files live during a command, and how blobs, trees, and commits fit together.
Merging versus rebasing
Merge and rebase both integrate branch work, but they rewrite history differently—one adds merge commits, the other replays commits on a new base. Compare fast-forward merges, conflict resolution, squash merges, interactive rebase, and when each approach fits a team.
Pull requests with and without GitHub
Review and integrate changes through pull requests on GitHub—or through email patches and git request-pull when no host is involved. Covers forks, the PR lifecycle, merge strategies, branch protection, and the gh CLI.
Undoing and moving changes
Stash work in progress, amend the last commit, reset or restore files, revert published history safely, undo merges, and cherry-pick fixes onto other branches—without guessing which Git area each command touches.
Working with remotes
Clone a repository, add a remote, fetch and push commits, and set upstream tracking branches—the mechanics of sharing history with GitHub or any Git server, plus pitfalls when pulling or force-pushing with teammates.