mark up ‘master’ (four instances)

1 files changed, 4 insertions, 4 deletions

diff --git a/developers-manual.rst b/developers-manual.rst
index 2910c9fb..337e986b 100644
--- a/developers-manual.rst
+++ b/developers-manual.rst
@@ -107,9 +107,9 @@ to sign them, you can retroactively add signatures using:
    $ git rebase -S
 
 
-Whether you commit to a personal branch, a feature branch or to master should
+Whether you commit to a personal branch, a feature branch or to ``master`` should
 depend on your level of comfort and the nature of the change.  As a general
-rule, the code in master must always build and tests should always pass, at
+rule, the code in ``master`` must always build and tests should always pass, at
 least on your own system. However, we all make mistakes and you should expect
 to receive friendly reminders if your change did not live up to this simple
 standard.  We plan to move to a system where the CI guarantees this invariant
@@ -117,7 +117,7 @@ in the future.
 
 In order to keep a linear and clean commits history, we advise to avoid
 merge commits and instead always rebase your changes before pushing to
-the master branch.  If you commit and later find out that new commits were
+the ``master`` branch.  If you commit and later find out that new commits were
 pushed, the following command will pull the new commits and rebase yours
 on top of them.
 
@@ -130,7 +130,7 @@ on top of them.
 Observing changes
 -----------------
 
-Every commit to the master branch of any of our public repositories
+Every commit to the ``master`` branch of any of our public repositories
 (and almost all are public) is automatically sent to the
 gnunet-svn@gnu.org mailinglist.  That list is for Git commits only,
 and must not be used for discussions. It also carries commits from