{"dataset":{"id":"00000000-0000-0000-0000-000000000030","slug":"git-best-practices","name":"Git best practices","description":"Source-linked guidance on Git fundamentals: branching workflows, rewriting history, rebasing versus merging, remote-tracking branches, and distributed workflows. Scoped to Git; not a hosting-platform or GitHub-specific corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Centralized, integration-manager, and dictator workflows","sourceUrl":"https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows","text":"Because Git is distributed, every developer is potentially both a node and a hub, able to contribute code to other repositories and to maintain a public repository that others base work on, which supports several standard workflows. In the centralized workflow, one hub repository accepts code and every developer synchronizes with it: the first developer to push succeeds, and others must fetch and merge before pushing, because Git rejects non-fast-forward pushes rather than letting users overwrite each other. This model works as well in Git as in centralized systems such as Subversion, and with Git's branching it can scale to hundreds of developers on dozens of simultaneous branches. The integration-manager workflow gives each developer write access to their own public repository and read access to everyone else's: a contributor pushes to their public clone and asks the maintainer to pull, and the maintainer adds that repository as a remote, merges locally, and pushes to the canonical repository — a pattern common on hub-based tools like GitHub and GitLab. Huge projects with hundreds of collaborators, such as the Linux kernel, use the dictator-and-lieutenants variant. Scope: Git. Reviewed October 4, 2026.","id":"git-best-practices:Centralized, integration-manager, and dictator workflows","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Remote-tracking branches and upstreams","sourceUrl":"https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches","text":"Remote-tracking branches are local references to the state of branches on a remote, named in the form <remote>/<branch> such as origin/master. You cannot move them yourself; Git moves them whenever you do network communication, so git fetch origin updates your local database and moves origin/master forward. Cloning names the source origin — a default from git clone, not a special name — and creates origin/master plus a local master branch to work from. A tracking branch is a local branch with a direct relationship to a remote branch, called its upstream: on a tracking branch, git pull knows which server to fetch from and which branch to merge in. Create one with git checkout --track origin/serverfix, or git checkout -b sf origin/serverfix for a different name; if the branch name you check out does not exist locally and exactly matches a name on only one remote, Git creates the tracking branch for you. Point an existing branch at an upstream with git branch -u origin/serverfix, reference the upstream with the @{upstream} or @{u} shorthand, and list all tracking relationships with git branch -vv. Scope: Git. Reviewed October 4, 2026.","id":"git-best-practices:Remote-tracking branches and upstreams","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Rebasing versus merging","sourceUrl":"https://git-scm.com/book/en/v2/Git-Branching-Rebasing","text":"Git has two main ways to integrate changes from one branch into another: merge and rebase. Merge performs a three-way merge between the two latest branch snapshots and their most recent common ancestor, creating a new merge commit. Rebase instead goes to the common ancestor, takes the diff introduced by each commit on your branch, and replays those changes in order on top of the other branch, after which the target branch can fast-forward. The snapshot you end up with is identical either way; only the history differs, and rebasing produces a linear log that looks as if the work happened in series even when it happened in parallel. That makes rebasing useful when contributing to a project you do not maintain, since the maintainer needs only a fast-forward or a clean apply. The perils reduce to one rule: do not rebase commits that exist outside your repository and that people may have based work on. Rewriting pushed commits forces collaborators to re-merge their work and makes pulling their work back into yours messy. Scope: Git. Reviewed October 4, 2026.","id":"git-best-practices:Rebasing versus merging","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Rewriting history with amend and interactive rebase","sourceUrl":"https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History","text":"Git lets you revise local commit history before sharing it: reordering commits, changing messages or the files in a commit, squashing commits together, splitting them apart, or removing commits entirely. The cardinal rule is to avoid pushing until you are happy with your work; once pushed, consider it final unless you have good reason to change it. For the most recent commit, git commit --amend loads the previous message into an editor, or replaces the commit's content when you stage changes first, and --no-edit skips the editor. Amending changes the commit's SHA-1, behaving like a very small rebase, so do not amend a commit you have already pushed. For commits farther back, git rebase -i HEAD~3 opens an interactive session listing the last three commits, where commands such as reword, edit, squash, and fixup rewrite each step; squash melds a commit into the previous one and fixup does the same but discards its log message. Aiming for small, self-contained commits that rebase cleanly is Koskamo editorial guidance, not a Git requirement. Scope: Git. Reviewed October 4, 2026.","id":"git-best-practices:Rewriting history with amend and interactive rebase","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Long-running and topic branches","sourceUrl":"https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows","text":"Because Git merging is a simple three-way merge, teams can keep several long-running branches at different stability levels and merge between them regularly over a long period. A common arrangement keeps only entirely stable, possibly released, code in master, with a parallel develop or next branch used to test stability and to pull in topic branches once they pass all tests; larger projects sometimes add a proposed or pu branch for integrated work not yet ready for next or master. Think of these as work silos where commits graduate to a more stable silo when fully tested. Multiple long-running branches are optional but often helpful on very large or complex projects. Topic branches are useful at any size: a short-lived branch for a single feature or related work that you create, work on, merge, and delete, cheaply enough to do several times a day. Keeping a branch's changes confined to one topic makes context-switching complete and code review easier. Scope: Git. Reviewed October 4, 2026.","id":"git-best-practices:Long-running and topic branches","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}