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
Anthony Bilinski
parent
9ac44ee09c
commit
345e33b531
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue