hacking-howto: Update git section

This still had some leftovers from the patch era. Since git and
specifically GitHub-like developing is much more mainstream now we don't
need to link introductions or even mention the idea of "patching".

The deleted "them" was referencing an old sentence referring to patches,
generated by the git cli. As emailing patches is not common at all for
GitHub repos, I removed the sentence altogether.

Also simplifies the 'branches' subsection a bit. Asking people to verify
their patch on master seems too much preliminary work and I doubt that
anyone does it anyway.

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
+== Pull requests
-
-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
 
 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,
+Even for accepted features, this can be a good way to refine an idea upfront.
-we don't want to see certain features in i3, e.g., switching window focus in an
+However, we don't want to see certain features in i3, e.g., switching window
-Alt+Tab like way.
+focus in an Alt+Tab like way.
 
-When working on bugfixes, please make sure you mention that you are working on
+When working on bugfixes, please make sure you mention that you are working on it
-it in the corresponding bug report at https://github.com/i3/i3/issues. In case
+in the corresponding bug report at https://github.com/i3/i3/issues. In case there
-there is no bug report yet, please create one.
+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.
+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.
-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.
 
 === 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
+New features are only found in the “next” branch. Always use this branch when
-on a new feature, use the “next” branch. If you are working on a bugfix, use the
+writing new code (both bugfixes and features).
-“next” branch, too, but make sure your code also works on “master”.
 
 == Window Managers