diff --git a/docs/hacking-howto b/docs/hacking-howto
index 6d8092b5..cf812069 100644
--- a/docs/hacking-howto
+++ b/docs/hacking-howto
@@ -48,29 +48,21 @@ tarball, but shouldn’t hurt either.
 * Coverage reports are now generated using +make check-code-coverage+, which
   requires specifying +--enable-code-coverage+ when calling configure.
 
-== Using git / sending patches
-
-For a short introduction into using git, see
-https://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy
-or, for more documentation, see https://git-scm.com/documentation
+== Pull requests
 
 Please talk to us before working on new features to see whether they will be
 accepted. A good way for this is to open an issue and asking for opinions on it.
-Even for accepted features, this can be a good way to refine an idea upfront. However,
-we don't want to see certain features in i3, e.g., switching window focus in an
-Alt+Tab like way.
+Even for accepted features, this can be a good way to refine an idea upfront.
+However, we don't want to see certain features in i3, e.g., switching window
+focus in an Alt+Tab like way.
 
-When working on bugfixes, please make sure you mention that you are working on
-it in the corresponding bug report at https://github.com/i3/i3/issues. In case
-there is no bug report yet, please create one.
+When working on bugfixes, please make sure you mention that you are working on it
+in the corresponding bug report at https://github.com/i3/i3/issues. In case there
+is no bug report yet, please create one.
 
 After you are done, please submit your work for review as a pull request at
-https://github.com/i3/i3.
-
-Do not send emails to the mailing list or any author directly, and don’t submit
-them in the bugtracker, since all reviews should be done in public at
-https://github.com/i3/i3. In order to make your review go as fast as possible, you
-could have a look at previous reviews and see what the common mistakes are.
+https://github.com/i3/i3. In order to make your review go as fast as possible,
+you could have a look at previous reviews and see what the common mistakes are.
 
 === Which branch to use?
 
@@ -81,9 +73,8 @@ repository).
 The contents of “master” are always stable. That is, it contains the source code
 of the latest release, plus any bugfixes that were applied since that release.
 
-New features are only found in the “next” branch. Therefore, if you are working
-on a new feature, use the “next” branch. If you are working on a bugfix, use the
-“next” branch, too, but make sure your code also works on “master”.
+New features are only found in the “next” branch. Always use this branch when
+writing new code (both bugfixes and features).
 
 == Window Managers