mirror of
https://github.com/qTox/qTox.git
synced 2024-03-22 14:00:36 +08:00
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.
This commit is contained in:
Anthony Bilinski
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
Block a user