What is a git topic branch?

Question

Topic branches are typically lightweight branches that you create locally and that have a name that is meaningful for you. They are where you might do work for a bug fix or feature (they're also called feature branches) that is expected to take some time to complete.

Another type of branch is the "remote branch" or "remote-tracking branch". This type of branch follows the development of somebody else's work and is stored in your own repository. You periodically update this branch (using git fetch) to track what is happening elsewhere. When you are ready to catch up with everybody else's changes, you would use git pull to both fetch and merge.

I have also seen another kind of branch which is essentially a completely separate tree of files in the same repository. For example, the Git repository itself contains heads named man and html that contain entirely different content from the master branch. I don't know what these types of branches are usually called.

It's not a technical term; it just refers to a branch that was created to implement a specific feature or fix a bug. The "topic" is the reason for the creation of the branch, essentially.

https://github.com/dchelimsky/rspec/wiki/Topic-Branches explains this well:

A “topic” branch is a separate branch that you use when working on a single “topic” (a bug fix, a new feature, or an experimental idea). Working on a topic branch instead of directly on top of “master” is recommended because:

{... visit link ...}

So, for all of these reasons it’s recommended to use a topic branch for preparing submissions even for simple contributions like single-commit bugfixes and the like.

This sample also gives examples. Which actually got me to thinking, this is probably what most shops do already. All of the agile projects I've ever been with do. I upvoted th "It's not a technical term" because I feel this hits the nail on the head.

it looks like the most prominent and important type of branches that aren't topic branches would be release branches on a major, publicly-available repository, right?

That's probably right for you, but that's about you and the project you're thinking about; it's not determined by Git.

Most version control systems (particularly centralized ones) prescribe or enforce a particular workflow, including what it makes sense to use a branch for. Git ( and to some extent most distributed VCSs) consider that workflow, what branches are used for, when to commit, what different repos are used for, etc. is all chosen by the users and agreements among the users (policies). So Git doesn't enforce these technically.

This is one of the things that made Git hard for me to learn. Oliver Steele explained this from user's view, writing about Commit Policies.