mirror of https://github.com/qTox/qTox
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.reviewable/pr6477/r3
parent
9ac44ee09c
commit
345e33b531
|
@ -5,8 +5,6 @@
|
||||||
- [Before you start…](#before-you-start)
|
- [Before you start…](#before-you-start)
|
||||||
- [Must read](#must-read)
|
- [Must read](#must-read)
|
||||||
- [Pull request](#pull-request)
|
- [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)
|
- [Git Commit Guidelines](#commit)
|
||||||
- [Commit Message Format](#commit-message-format)
|
- [Commit Message Format](#commit-message-format)
|
||||||
- [Header](#header)
|
- [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`
|
easier to review and merging them is quicker. PR diff shouldn't exceed `300`
|
||||||
changed lines, unless it has to.
|
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" />
|
<a name="commit" />
|
||||||
|
|
||||||
## Git Commit Guidelines
|
## Git Commit Guidelines
|
||||||
|
|
Loading…
Reference in New Issue