This is clearly more elegant, though it adds a new dependency, which is OK.
I really like that, too, I wish we'd track our requirements in git instead of having an IBM enterprise solution which is slow, has a terrible web interface and no ability to diff requirements properly.
The more information is versioned in the same system, the better the coherence of the information.
So does that mean that bug reports are tied to branches? (I.e. depending on which branch you've checked out, you see a different list of bugs?) I wouldn't like that idea at all because how would you keep track of bugs (and related discussions) across branches? (For instance, having 10 branches would imply that you suddenly have 10 versions of the same bug discussion, too.)
I see more value in it for clear technical tasks with technical descriptions, and not so much for discussions. Then proposals can be peer-reviewed before accepted as work that needs to be done (as a merge request to master, for example).
Then another problem that comes along with that, especially for golang users, is that your master branch is getting bombarded with issue updates, causing what looks like releases, when there's no effective change.