There are two popular suggestions here:
git branch --edit-description : We don't like this because you can't push it. Maybe I can remember what the branches I created do, but my team sure can't.
README file pr. branch. This is a pain during merges: Super-prone to merge conflicts and we'll be pulling in README from branches when we merge feature branches. Diffs between branches are also a pain.
We've decided to create an orphan branches-readme branch. Orphan branches are branches with their own separate history - you may know them from Github's gh-pages branches. This orphan branch contains a single README file. It has contents like:
master:
The default branch
mojolicious:
Start using Mojolicious
branch-whatever:
Description of the whatever branch
It is push-able and merge-friendly. View the README from any branch with:
git show branches-readme:README
Disadvantages are that you need to checkout the weird orphan branch when you want to update the README and the README doesn't auto-update as branches get renamed, come or go. That is fine for us, though.
Do it like:
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
Similary, individual team members can also create their own branches-$user orphan branches describing their own private branches if they want to, as long as they don't push them to the team.
With further tooling this could also be integrated with the output of git branch. To that end, perhaps a README.yaml file could be considered instead of a plain README.