chore(docs): Remove generic git instructions from docs

General version control, git, or github instructions can be found in abundance
elsewhere. Keep qTox docs more focused on qTox.

CONTRIBUTING.md

@@ -5,8 +5,6 @@
     - [Before you start…](#before-you-start)
     - [Must read](#must-read)
     - [Pull request](#pull-request)
-    - [How to open a pull request](#how-to-open-a-pull-request)
-    - [How to deal with large amounts of merge conflicts](#merge-conflicts)
     - [Git Commit Guidelines](#commit)
        - [Commit Message Format](#commit-message-format)
         - [Header](#header)
@@ -109,97 +107,6 @@ It's important to keep amount of changes in the PR small, since smaller PRs are
 easier to review and merging them is quicker. PR diff shouldn't exceed `300`
 changed lines, unless it has to.
 
-## How to open a pull request
-1. Fork the qTox repository on Github to your existing account.
-2. Open a Terminal and do the following steps:
-```bash
-# Go to a directory of your choice, where the qTox directory will be created:
-cd /to/the/directory
-
-# Clone the forked repo:
-git clone git@github.com:<YOUR_USER>/qTox.git
-
-# Add the "upstream" remote to be able to fetch from the qTox upstream repository:
-git remote add upstream https://github.com/qTox/qTox.git
-
-# Fetch from the "upstream" repository
-git fetch upstream
-
-# Point the local "master" branch to the "upstream" repository
-git branch master --set-upstream-to=upstream/master
-```
-
-You're now all set to create your first pull request! Hooray! :)
-
-Still in Terminal, do the following steps to actually create the pull request:
-
-```bash
-# Fetch from the "upstream" repository:
-git fetch upstream master:master
-
-# Checkout a local branch on up-to-date "master" and give it a sane name, e.g.:
-git checkout -b feat/brandnew-feature master
-```
-
-Now do your changes and commit them by your heart's desire. When you think
-you're ready to push for the first time, do the following:
-
-```bash
-# Push to the new upstream branch and link it for synchronization
-git push -u origin feat/brandnew-feature
-
-# From now on, you can simply…
-git push
-# ...to your brand new pull request.
-```
-
-That's it! Happy contributing!
-
-<a name="merge-conflicts" />
-
-## How to deal with large amounts of merge conflicts
-
-Usually you want to avoid conflicts and they should be rare. If conflicts
-appear anyway, they are usually easy enough to solve quickly and safely.
-However, if you find yourself in a situation with large amounts of merge
-conflicts, this is an indication that you're doing something wrong and you
-should change your strategy. Still… you probably don't want to throw away and
-lose all your valuable work. So don't worry, there's a way to get out of that
-mess. The basic idea is to divide the conflicts into smaller – easier to solve
-– chunks and probably several (topic) branches. Here's a little "Rule of Thumb"
-list to get out of it:
-
-1. Split your commit history into topic related chunks (by
-   rebasing/cherry-picking "good" commits).
-2. Split "API" and "UI" (widget related) changes into separate commits.
-3. Probably split PR into several smaller ones.
-
-In addition it helps to regularly keep rebasing on the upstream repository's
-recent master branch. If you don't have the upstream remote in your repo, add
-it as described in [How to open a pull request](#how-to-open-a-pull-request).
-
-~~~bash
-# If not on PR branch, check it out:
-git checkout my/pr-branch
-
-# Now fetch master ALWAYS from upstream repo
-git fetch upstream master:master
-
-# Last, rebase PR branch onto master…
-git rebase -i master
-
-# …and, if everything's clear, force push to YOUR repo (your "origin" Git remote)
-git push -f
-~~~
-
-## Good to know
-* **Search** the pull request history! Others might have already implemented
-  your idea and it could be waiting to be merged (or have been rejected
-  already). Save your precious time by doing a search first.
-* When resolving merge conflicts, do `git rebase <target_branch_name>`, don't
-  do `git pull`. Then you can start fixing the conflicts.  [Here is a good
-  explanation](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).
-
 <a name="commit" />
 
 ## Git Commit Guidelines