forked from ISPsystem/isp-maintenance
76 lines
3.0 KiB
Markdown
76 lines
3.0 KiB
Markdown
|
# Contributing to isp-maintenance
|
||
|
|
||
|
|
||
|
### Getting started
|
||
|
|
||
|
To get started, fork the isp-maintenance `isp-maintenance` git repository on Gitea and clone it:
|
||
|
|
||
|
$ git clone git@git.isptech.ru:<user>/isp-maintenance.git
|
||
|
|
||
|
To keep your forked repository up to date, setup the `upstream` remote to pull in new changes:
|
||
|
|
||
|
$ git remote add upstream https://git.isptech.ru/ISPsystem/isp-maintenance.git
|
||
|
$ git pull --rebase upstream main
|
||
|
|
||
|
|
||
|
### Creating a new feature, fix, etc
|
||
|
|
||
|
|
||
|
Using the Gitea web editor for making changes is strongly discouraged, because you will need to clone the repo anyways to edit and test your changes.
|
||
|
|
||
|
Using the `main` branch of your fork for contributing is also strongly discouraged.
|
||
|
It can cause many issues with updating your pull request (also called a PR), and having multiple PRs open at once.
|
||
|
To create a new branch:
|
||
|
|
||
|
$ git checkout main -b <a-descriptive-name>
|
||
|
|
||
|
- Stick to PEP and use a linter. We use flake8 (default config)
|
||
|
|
||
|
|
||
|
### Starting a pull request
|
||
|
|
||
|
Once you have successfully built the package, you can [create a pull request](https://docs.gitea.com/usage/pull-request).
|
||
|
Pull requests are also known as PRs.
|
||
|
|
||
|
Most pull requests should only contain a single feature or fix.
|
||
|
|
||
|
|
||
|
Before a pull request, update the `main` branch and rebase to your branch.
|
||
|
[rebase docs](https://git-scm.com/book/ru/v2/Ветвление-в-Git-Перебазирование).
|
||
|
|
||
|
$ git checkout main
|
||
|
$ git pull --rebase upstream main
|
||
|
$ git checkout <your-branch-name>
|
||
|
$ git rebase main
|
||
|
|
||
|
|
||
|
#### Review
|
||
|
|
||
|
It's possible (and common) that a pull request will contain mistakes or reviewers will ask for additional tweaks.
|
||
|
Reviewers will comment on your pull request and point out which changes are needed before the pull request can be merged.
|
||
|
|
||
|
Most PRs will have a single commit, as seen so if you need to make changes to the commit and already have a pull request open, you can use the following commands:
|
||
|
|
||
|
$ git add <file>
|
||
|
$ git commit --amend
|
||
|
$ git push -f
|
||
|
|
||
|
A more powerful way of modifying commits than using `git commit --amend` is with [git-rebase](https://git-scm.com/docs/git-rebase#_interactive_mode), which allows you to join, reorder, change description of past commits and more.
|
||
|
|
||
|
Alternatively, if there are issues with your git history, you can make another branch and push it to the existing PR:
|
||
|
|
||
|
$ git checkout main -b <attempt2>
|
||
|
$ # do changes anew
|
||
|
$ git push -f <fork> <attempt2>:<branch-of-pr>
|
||
|
|
||
|
#### Closing the pull request
|
||
|
|
||
|
Once you have applied all requested changes, the reviewers will merge your request.
|
||
|
|
||
|
If the pull request becomes inactive for some days, the reviewers may or may not warn you when they are about to close it.
|
||
|
If it stays inactive further, it will be closed.
|
||
|
|
||
|
Please abstain from temporarily closing a pull request while revising the templates.
|
||
|
Instead, leave a comment on the PR describing what still needs work, add "[[WIP](https://docs.gitea.com/usage/automatically-linked-references)]" to the PR title.
|
||
|
Only close your pull request if you're sure you don't want your changes to be included.
|