回答:
トピックブランチは通常、ローカルで作成する軽量のブランチであり、わかりやすい名前が付けられています。バグ修正や機能（機能ブランチとも呼ばれます）が完了するまでに時間がかかることが予想される場合は、これらの作業を行うことができます。
別のタイプのブランチは、「リモートブランチ」または「リモートトラッキングブランチ」です。このタイプのブランチは、他の誰かの作業の開発に従い、独自のリポジトリに格納されます。このブランチを定期的に更新し（を使用git fetch）、他の場所で何が起こっているかを追跡します。他の人の変更に追いつく準備ができたらgit pull、フェッチとマージの両方に使用します。
また、本質的に同じリポジトリ内のファイルの完全に別のツリーである別の種類のブランチも見ました。たとえば、Gitリポジトリ自体には、masterブランチとはまったく異なるコンテンツを含むmanおよびhtmlという名前のヘッドが含まれています。私はこれらの種類のブランチが通常何と呼ばれるかわかりません。
専門用語ではありません。特定の機能を実装したり、バグを修正したりするために作成されたブランチを参照するだけです。「トピック」は、本質的にブランチを作成する理由です。
https://github.com/dchelimsky/rspec/wiki/Topic-Branchesはこれをうまく説明しています：
「トピック」ブランチは、単一の「トピック」（バグ修正、新機能、または実験的なアイデア）で作業するときに使用する個別のブランチです。「マスター」の上に直接ではなく、トピックブランチで作業することをお勧めします。
{...リンクにアクセス...}
したがって、これらすべての理由から、シングルコミットのバグ修正などの単純なコントリビューションの場合でも、トピックブランチを使用して投稿を準備することをお勧めします。
このサンプルは例も示します。これは私に実際に考えさせられました、これはおそらくほとんどの店がすでにしていることです。私がこれまで行ってきたアジャイルプロジェクトはすべてやっています。「専門用語ではない」と賛成したのは、これが頭の釘に当たったように感じたからです。
トピックブランチではない最も有名で重要なタイプのブランチは、一般に公開されている主要なリポジトリのリリースブランチでしょう。
それはおそらくあなたにとって正しいことですが、それはあなたとあなたが考えているプロジェクトについてです。それはGitによって決定されません。
ほとんどのバージョン管理システム（特に一元化されたもの）は、特定のワークフローを規定または強制します。これには、ブランチを使用する意味があるものも含まれます。Git（およびある程度分散したVCS）は、ワークフロー、ブランチの用途、コミットのタイミング、さまざまなリポジトリの用途などはすべて、ユーザーとユーザー間の合意（ポリシー）によって選択されることを考慮しています。したがって、Gitはこれらを技術的に強制しません。
これは、Gitの学習を困難にした要因の1つです。Oliver Steeleはこれをユーザーの視点から説明し、コミットポリシーについて書いています。