我非常确定目前不支持该特性。我认为最好的办法是创建一个描述文本文件，基本上是一个README，在包含您想要的信息的分支中。

Chris J建议的README可以工作，只要它使用.gitattribute中定义的自定义合并驱动程序进行设置。 这样，在合并期间始终保留README的本地版本。

分支的“描述”也被称为与元数据相关联的“注释”，它是不受支持的。

至少，对于一个README文件，你可以对任何分支执行:

$ git show myBranch:README

如果你的README在你的REPO的根目录，它将从任何路径工作，因为git show使用的路径是绝对的一个从REPO的顶部目录。

选定的答案对我来说似乎太夸张了。我倾向于维护每个分支的描述文件，这是一个正常的源代码控制文件，比如master.txt, dev.txt等，如果有一个难以处理的数字或分支，我会创建一个层次结构来更好地组织它。

你可以给标签添加注释:

git tag -m 'this was a very good commit' tag1

按照惯例，您可以使用与分支名称相关的标记，或者您可以使用标记-f在主题分支的头部保留一个注释标记。

如果您最终要使用README，请创建一个git别名，修改git checkout，以便在每次切换分支时显示您的README。

例如，在~/中添加这个。Gitconfig，在[alias]下

cor = !sh -c 'git checkout $1 && cat README' -

在此之后，您可以运行git cor <branch_name>来切换分支，并显示您要切换到的分支的README。

Git 1.7.9支持这一点。从1.7.9版本说明中可以看到:

 * "git branch --edit-description" can be used to add descriptive text
   to explain what a topic branch is about.

你可以在提交6f9a332、739453a3、b7200e8时看到该特性早在2011年9月就已经引入:

struct branch_desc_cb {
  const char *config_name;
  const char *value;
};

--edit-description::

打开编辑器并编辑文本以解释分支的用途，以供各种其他命令使用(例如请求-拉取)。

注意，它不适用于分离的HEAD分支。

这个描述被脚本request-pull使用:参见commit c016814783，还有git merge——log。

request-pull是一个脚本，用于总结两次提交到标准输出之间的更改，并在生成的摘要中包含给定的URL。

不幸的是，你不能推送描述，因为它们存储在你的配置中，这对于团队中的分支来说是无用的。

下面是Greg Hewgill提到的git分支命令的一个可能实现:

#!/usr/bin/perl

sub clean {
    map { s/^[\s\*]*\s// } @_;
    map { s/\s*$// } @_;
    return @_;
}

sub descr {
    $_ = `git config branch.@_.description`;
    s/\s*$//;
    return $_;
};
sub indent {
    $_ = shift;
    s/^/      /mg;
    return $_;
};

my @branches = clean `git branch --color=never --list`;
my %merged = map { $_ => 1 } clean `git branch --color=never --merged`;

for my $branch (@branches) {
    my $asis = `git branch --list --color=always $branch`;
    $asis =~ s/\s*$//;
    print "  $asis";
    print " \033[33m(merged)\033[0m" if ($merged{$branch} and $branch ne "master");
    print "\n";

    print indent descr $branch;
    print "\n";
    print "\n";
}

使用git branch——edit-description来设置或编辑分支描述。

下面是一个shell函数，它显示与git分支类似的分支，但附加了描述。

# Shows branches with descriptions
function gb() {
  current=$(git rev-parse --abbrev-ref HEAD)
  branches=$(git for-each-ref --format='%(refname)' refs/heads/ | sed 's|refs/heads/||')
  for branch in $branches; do
    desc=$(git config branch.$branch.description)
    if [ $branch == $current ]; then
      branch="* \033[0;32m$branch\033[0m"
     else
       branch="  $branch"
     fi
     echo -e "$branch \033[0;36m$desc\033[0m"
  done
}

下面是gb的样子，在这里显示为文本，以防图像腐烂:

$ gb
* logging Log order details.  Waiting for clarification from business.
  master 
  sprocket Adding sprockets to the parts list.  Pending QA approval.

作为一个图像，你可以看到颜色:

Use

git branch --list -v

显示上游分支:

git branch --list -vv

添加-r只显示远程或-a显示远程和本地。

这里有两个流行的建议:

git分支——edit-description:我们不喜欢这样，因为你不能推送它。也许我能记住我创建的分支是做什么的，但我的团队肯定不能。 README文件pr.分支。这是合并过程中的一个痛苦:非常容易合并冲突，当我们合并特性分支时，我们将从分支中拉入README。分支之间的差异也是一种痛苦。

我们决定创建一个孤儿分支——readme分支。孤儿分支是有自己独立历史的分支——你可能从Github的gh-pages分支知道它们。这个孤儿分支包含一个单独的README文件。它的内容包括:

master:
    The default branch
mojolicious:
    Start using Mojolicious
branch-whatever:
    Description of the whatever branch

它是可推的和合并友好的。从任何分支查看README:

git show branches-readme:README

缺点是，当您想要更新README时，您需要签出奇怪的孤立分支，并且README不会随着分支的重命名、出现或消失而自动更新。不过，这对我们来说还好。

这样做:

git checkout --orphan branches-readme
# All the files from the old branch are marked for addition - skip that
git reset --hard
# There are no files yet - an empty branch
ls
vi README
# put in contents similar to above
git add README
git commit -m "Initial description of the branches we already have"
git push origin branches-readme
# get all your original files back
git checkout master

类似地，每个团队成员也可以创建他们自己的分支-$user孤儿分支，如果他们愿意，只要他们不把它们推给团队，就可以描述他们自己的私有分支。

通过进一步的工具，这也可以与git分支的输出集成。为了这个目的，可能需要一个自述书。可以考虑使用yaml文件来代替普通的README。

git config --global --add alias.about '!describe() { git config branch."$1".description; }; describe'

命令将定义全局选项别名。About as shell表达式。如果在存储库中运行git about <branch>，将显示分支的描述。

只使用:

git config branch.<branch name>.description

在该表扬的地方表扬: https://glebbahmutov.com/blog/git-branches-with-descriptions/

下面是一个git别名，它可以让你设置和读取当前分支的描述:

git config --global --add alias.about '!describe() { msg="$1"; git config branch."$(git rev-parse --abbrev-ref HEAD)".description ${msg:+"$msg"}; }; describe'

使用/例子:

(develop) $ git about
(develop) $ git about message
(develop) $ git about
message
(develop) $ git about "this is a new message"
(develop) $ git about
this is a new message
(develop) $ git checkout -b test_branch
Switched to a new branch 'test_branch'
(test_branch) $ git about
(test_branch) $ git about "this is the test branch"
(test_branch) $ git about
this is the test branch
(test_branch) $ git checkout -
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
(develop) $ git about
this is a new message

特别感谢@Felicio的回答，让我开始了。

假设您想创建一个分支

git branch branch-20200328
git notes add branch-20200328 -m "This branch is for whatever"
git notes show branch-20200328

你可以使用

git config --get-regexp "branch.*.description"

关于Greg Hewgill 2012年的回答，Git 1.7.9(2012年第一季度)也包含了一些对Git分支的检查——edit-description:

参见Junio C Hamano (gitster)提交c2d17ba(2012年2月05日)。 (由Junio C Hamano—gitster—在commit d88698e中合并，2012年2月10日)

分支——edit-description:防止输入错误的分支名称

It is very easy to mistype the branch name when editing its description, e.g. $ git checkout -b my-topic master : work work work : now we are at a good point to switch working something else $ git checkout master : ah, let's write it down before we forget what we were doing $ git branch --edit-description my-tpoic The command does not notice that branch 'my-tpoic' does not exist. It is not lost (it becomes description of an unborn my-tpoic branch), but is not very useful. So detect such a case and error out to reduce the grief factor from this common mistake. This incidentally also errors out --edit-description when the HEAD points at an unborn branch (immediately after "init", or "checkout --orphan"), because at that point, you do not even have any commit that is part of your history and there is no point in describing how this particular branch is different from the branch it forked off of, which is the useful bit of information the branch description is designed to capture. We may want to special case the unborn case later, but that is outside the scope of this patch to prevent more common mistakes before 1.7.9 series gains too much widespread use.

虽然Greg Hewgill 2012年的答案是准确的，但使用git分支——edit-description可能会导致:

fatal: could not unset 'branch.main.description'

GIT_EDITOR=: git branch——edit-description(man)导致失败，这已在git 2.39 (Q4 2022)中得到纠正。

参见juno C Hamano (gitster)提交e288b3d (30 Sep 2022)。 (由Junio C Hamano—gitster—在commit 272be0d中合并，2022年10月17日)

分支:不要失败no-op——edit-desc

Imagine running "git branch --edit-description"(man) while on a branch without the branch description, and then exit the editor after emptying the edit buffer, which is the way to tell the command that you changed your mind and you do not want the description after all. The command should just happily oblige, adding no branch description for the current branch, and exit successfully. But it fails to do so: $ git init -b main $ git commit --allow-empty -m commit $ GIT_EDITOR=: git branch --edit-description fatal: could not unset 'branch.main.description' The end result is OK in that the configuration variable does not exist in the resulting repository, but we should do better. If we know we didn't have a description, and if we are asked not to have a description by the editor, we can just return doing nothing. This of course introduces TOCTOU.

(Time-of-check to time-of-use (tocou):由竞态条件引起的一类软件错误，包括对系统部分状态的检查(例如安全凭证)以及对检查结果的使用。)

如果您从另一个窗口向同一分支添加了一个分支描述，而您打开了编辑器来编辑该描述，然后退出编辑器而没有在那里写入任何内容，那么我们最终不会删除您在另一个窗口中添加的描述。 但是在这一点上，您在自己的存储库中愚弄自己，如果这很痛苦，您最好不要这样做;-)。

另外:“git branch -edit-description”(man)在一个未出生的分支上误导性地说不存在这样的分支，这已在git 2.39(2022年第四季度)中更正。

参见Rubén Justo (rjusto)提交bcfc82b (08 Oct 2022)。 (由Junio C Hamano—gitster—在commit 4050354中合并，2022年10月17日)

分支:对不存在的分支错误的描述 署名:Rubén Justo

When the repository does not yet have commits, some errors describe that there is no branch: $ git init -b first $ git branch --edit-description first error: No branch named 'first'. $ git branch --set-upstream-to=upstream fatal: branch 'first' does not exist $ git branch -c second error: refname refs/heads/first not found fatal: Branch copy failed That "first" branch is unborn but to say it doesn't exists is confusing. Options "-c" (copy) and "-m" (rename) show the same error when the origin branch doesn't exists: $ git branch -c non-existent-branch second error: refname refs/heads/non-existent-branch not found fatal: Branch copy failed $ git branch -m non-existent-branch second error: refname refs/heads/non-existent-branch not found fatal: Branch rename failed Note that "--edit-description" without an explicit argument is already considering the empty repository circumstance in its error. Also note that "-m" on the initial branch it is an allowed operation. Make the error descriptions for those branch operations with unborn or non-existent branches, more informative. This is the result of the change: $ git init -b first $ git branch --edit-description first error: No commit on branch 'first' yet. $ git branch --set-upstream-to=upstream fatal: No commit on branch 'first' yet. $ git branch -c second fatal: No commit on branch 'first' yet. $ git branch [-c/-m] non-existent-branch second fatal: No branch named 'non-existent-branch'.

在Git 2.39 (Q4 2022)中，“Git branch——edit-description @{-1}”(man)现在是一种在切换到当前分支之前编辑你所在分支的分支描述的方法。

参见Rubén Justo (rjusto)提交0dc4e5c (11 Oct 2022)。 (由Junio C Hamano—gitster—在commit c2058ea中合并，2022年10月21日)

分支:支持快捷方式，如@{-1}，已完成 署名:Rubén Justo

branch command with options "edit-description", "set-upstream-to" and "unset-upstream" expects a branch name. Since ae5a6c3 (checkout: implement "@{-N}" shortcut name for N-th last branch, 2009-01-17, Git v1.6.2-rc0 -- merge), a branch can be specified using shortcuts like @{-1}. Those shortcuts need to be resolved when considering the arguments. We can modify the description of the previously checked out branch with: $ git branch --edit--description @{-1} We can modify the upstream of the previously checked out branch with: $ git branch --set-upstream-to upstream @{-1} $ git branch --unset-upstream @{-1}