diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 851126bfe..be94eb427 100644 --- a/CONTRIBUTING.md +++ b/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:/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! - - - -## 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 `, 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). - ## Git Commit Guidelines