mirror of
https://codeberg.org/Codeberg/Documentation.git
synced 2026-08-15 14:53:29 -07:00
Organize docs
This commit is contained in:
n
parent
241300bd54
commit
eb83b8745d
21 changed files with 518 additions and 33 deletions
22
Overview.md
22
Overview.md
|
|
@ -1,22 +0,0 @@
|
|||
# Basic topics
|
||||
## Start with Codeberg...
|
||||
[Create a repository](https://codeberg.org/Codeberg/Documentation/wiki/Create-repository)
|
||||
|
||||
[SSH key for Codeberg](https://codeberg.org/Codeberg/Documentation/wiki/SSH-key-for-Codeberg)
|
||||
|
||||
## Work with Codeberg...
|
||||
[Clone & commit via HTTP (username & password)](https://codeberg.org/Codeberg/Documentation/wiki/Clone-%26-commit-via-HTTP-%28username-%26-password%29)
|
||||
|
||||
[Clone & commit via SSH (key file)](https://codeberg.org/Codeberg/Documentation/wiki/Clone-%26-commit-via-SSH)
|
||||
|
||||
# Advanced topics
|
||||
[Pull requests and GIT flow](https://codeberg.org/Codeberg/Documentation/wiki/Pull-requests-and-GIT-flow)
|
||||
|
||||
[Merge multiple commits into one](https://codeberg.org/Codeberg/Documentation/wiki/Merge-multiple-commits-into-one)
|
||||
# Wiki related topics
|
||||
[Including images in wiki pages](https://codeberg.org/Codeberg/Documentation/wiki/Including-images-in-wiki-pages)
|
||||
|
||||
# Other Codeberg related topics
|
||||
[Terms of use](https://codeberg.org/codeberg/org/src/branch/master/TermsOfUse.md)
|
||||
|
||||
[All Codeberg Wiki Pages](https://codeberg.org/Codeberg/Documentation/wiki/_pages)
|
||||
BIN
codeberg.png
BIN
codeberg.png
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
61
doc/advanced/features/template-repositories.md
Normal file
61
doc/advanced/features/template-repositories.md
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
---
|
||||
title: "Template Repositories"
|
||||
---
|
||||
|
||||
## Template Repositories
|
||||
Gitea `1.11.0` and above includes template repositories, and one feature implemented with them is auto-expansion of specific variables within your template files.
|
||||
To tell Gitea which files to expand, you must include a `template` file inside the `.gitea` directory of the template repository.
|
||||
Gitea uses [gobwas/glob](https://github.com/gobwas/glob) for its glob syntax. It closely resembles a traditional `.gitignore`, however there may be slight differences.
|
||||
|
||||
### Example `.gitea/template` file
|
||||
All paths are relative to the base of the repository
|
||||
```gitignore
|
||||
# All .go files, anywhere in the repository
|
||||
**.go
|
||||
|
||||
# All text files in the text directory
|
||||
text/*.txt
|
||||
|
||||
# A specific file
|
||||
a/b/c/d.json
|
||||
|
||||
# Batch files in both upper or lower case can be matched
|
||||
**.[bB][aA][tT]
|
||||
```
|
||||
**NOTE:** The `template` file will be removed from the `.gitea` directory when a repository is generated from the template.
|
||||
|
||||
### Variable Expansion
|
||||
In any file matched by the above globs, certain variables will be expanded.
|
||||
All variables must be of the form `$VAR` or `${VAR}`. To escape an expansion, use a double `$$`, such as `$$VAR` or `$${VAR}`
|
||||
|
||||
| Variable | Expands To | Transformable |
|
||||
|----------------------|-----------------------------------------------------|---------------|
|
||||
| REPO_NAME | The name of the generated repository | ✓ |
|
||||
| TEMPLATE_NAME | The name of the template repository | ✓ |
|
||||
| REPO_DESCRIPTION | The description of the generated repository | ✘ |
|
||||
| TEMPLATE_DESCRIPTION | The description of the template repository | ✘ |
|
||||
| REPO_OWNER | The owner of the generated repository | ✓ |
|
||||
| TEMPLATE_OWNER | The owner of the template repository | ✓ |
|
||||
| REPO_LINK | The URL to the generated repository | ✘ |
|
||||
| TEMPLATE_LINK | The URL to the template repository | ✘ |
|
||||
| REPO_HTTPS_URL | The HTTP(S) clone link for the generated repository | ✘ |
|
||||
| TEMPLATE_HTTPS_URL | The HTTP(S) clone link for the template repository | ✘ |
|
||||
| REPO_SSH_URL | The SSH clone link for the generated repository | ✘ |
|
||||
| TEMPLATE_SSH_URL | The SSH clone link for the template repository | ✘ |
|
||||
|
||||
### Transformers :robot:
|
||||
Gitea `1.12.0` adds a few transformers to some of the applicable variables above.
|
||||
For example, to get `REPO_NAME` in `PASCAL`-case, your template would use `${REPO_NAME_PASCAL}`
|
||||
|
||||
Feeding `go-sdk` to the available transformers yields...
|
||||
|
||||
| Transformer | Effect |
|
||||
|-------------|------------|
|
||||
| SNAKE | go_sdk |
|
||||
| KEBAB | go-sdk |
|
||||
| CAMEL | goSdk |
|
||||
| PASCAL | GoSdk |
|
||||
| LOWER | go-sdk |
|
||||
| UPPER | GO-SDK |
|
||||
| TITLE | Go-Sdk |
|
||||
|
||||
175
doc/advanced/features/webhooks.md
Normal file
175
doc/advanced/features/webhooks.md
Normal file
|
|
@ -0,0 +1,175 @@
|
|||
---
|
||||
title: "Webhooks"
|
||||
---
|
||||
|
||||
# Webhooks
|
||||
|
||||
Gitea supports web hooks for repository events. This can be configured in the settings
|
||||
page `/:username/:reponame/settings/hooks` by a repository admin. Webhooks can also be configured on a per-organization and whole system basis.
|
||||
All event pushes are POST requests. The methods currently supported are:
|
||||
|
||||
- Gitea (can also be a GET request)
|
||||
- Gogs
|
||||
- Slack
|
||||
- Discord
|
||||
- Dingtalk
|
||||
- Telegram
|
||||
- Microsoft Teams
|
||||
- Feishu
|
||||
|
||||
### Event information
|
||||
|
||||
The following is an example of event information that will be sent by Gitea to
|
||||
a Payload URL:
|
||||
|
||||
```
|
||||
X-GitHub-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
|
||||
X-GitHub-Event: push
|
||||
X-Gogs-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
|
||||
X-Gogs-Event: push
|
||||
X-Gitea-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
|
||||
X-Gitea-Event: push
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"secret": "3gEsCfjlV2ugRwgpU#w1*WaW*wa4NXgGmpCfkbG3",
|
||||
"ref": "refs/heads/develop",
|
||||
"before": "28e1879d029cb852e4844d9c718537df08844e03",
|
||||
"after": "bffeb74224043ba2feb48d137756c8a9331c449a",
|
||||
"compare_url": "http://localhost:3000/gitea/webhooks/compare/28e1879d029cb852e4844d9c718537df08844e03...bffeb74224043ba2feb48d137756c8a9331c449a",
|
||||
"commits": [
|
||||
{
|
||||
"id": "bffeb74224043ba2feb48d137756c8a9331c449a",
|
||||
"message": "Webhooks Yay!",
|
||||
"url": "http://localhost:3000/gitea/webhooks/commit/bffeb74224043ba2feb48d137756c8a9331c449a",
|
||||
"author": {
|
||||
"name": "Gitea",
|
||||
"email": "someone@gitea.io",
|
||||
"username": "gitea"
|
||||
},
|
||||
"committer": {
|
||||
"name": "Gitea",
|
||||
"email": "someone@gitea.io",
|
||||
"username": "gitea"
|
||||
},
|
||||
"timestamp": "2017-03-13T13:52:11-04:00"
|
||||
}
|
||||
],
|
||||
"repository": {
|
||||
"id": 140,
|
||||
"owner": {
|
||||
"id": 1,
|
||||
"login": "gitea",
|
||||
"full_name": "Gitea",
|
||||
"email": "someone@gitea.io",
|
||||
"avatar_url": "https://localhost:3000/avatars/1",
|
||||
"username": "gitea"
|
||||
},
|
||||
"name": "webhooks",
|
||||
"full_name": "gitea/webhooks",
|
||||
"description": "",
|
||||
"private": false,
|
||||
"fork": false,
|
||||
"html_url": "http://localhost:3000/gitea/webhooks",
|
||||
"ssh_url": "ssh://gitea@localhost:2222/gitea/webhooks.git",
|
||||
"clone_url": "http://localhost:3000/gitea/webhooks.git",
|
||||
"website": "",
|
||||
"stars_count": 0,
|
||||
"forks_count": 1,
|
||||
"watchers_count": 1,
|
||||
"open_issues_count": 7,
|
||||
"default_branch": "master",
|
||||
"created_at": "2017-02-26T04:29:06-05:00",
|
||||
"updated_at": "2017-03-13T13:51:58-04:00"
|
||||
},
|
||||
"pusher": {
|
||||
"id": 1,
|
||||
"login": "gitea",
|
||||
"full_name": "Gitea",
|
||||
"email": "someone@gitea.io",
|
||||
"avatar_url": "https://localhost:3000/avatars/1",
|
||||
"username": "gitea"
|
||||
},
|
||||
"sender": {
|
||||
"id": 1,
|
||||
"login": "gitea",
|
||||
"full_name": "Gitea",
|
||||
"email": "someone@gitea.io",
|
||||
"avatar_url": "https://localhost:3000/avatars/1",
|
||||
"username": "gitea"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Example
|
||||
|
||||
This is an example of how to use webhooks to run a php script upon push requests to the repository.
|
||||
In your repository Settings, under Webhooks, Setup a Gitea webhook as follows:
|
||||
|
||||
- Target URL: http://mydomain.com/webhook.php
|
||||
- HTTP Method: POST
|
||||
- POST Content Type: application/json
|
||||
- Secret: 123
|
||||
- Trigger On: Push Events
|
||||
- Active: Checked
|
||||
|
||||
Now on your server create the php file webhook.php
|
||||
|
||||
```
|
||||
<?php
|
||||
|
||||
$secret_key = '123';
|
||||
|
||||
// check for POST request
|
||||
if ($_SERVER['REQUEST_METHOD'] != 'POST') {
|
||||
error_log('FAILED - not POST - '. $_SERVER['REQUEST_METHOD']);
|
||||
exit();
|
||||
}
|
||||
|
||||
// get content type
|
||||
$content_type = isset($_SERVER['CONTENT_TYPE']) ? strtolower(trim($_SERVER['CONTENT_TYPE'])) : '';
|
||||
|
||||
if ($content_type != 'application/json') {
|
||||
error_log('FAILED - not application/json - '. $content_type);
|
||||
exit();
|
||||
}
|
||||
|
||||
// get payload
|
||||
$payload = trim(file_get_contents("php://input"));
|
||||
|
||||
if (empty($payload)) {
|
||||
error_log('FAILED - no payload');
|
||||
exit();
|
||||
}
|
||||
|
||||
// get header signature
|
||||
$header_signature = isset($_SERVER['HTTP_X_GITEA_SIGNATURE']) ? $_SERVER['HTTP_X_GITEA_SIGNATURE'] : '';
|
||||
|
||||
if (empty($header_signature)) {
|
||||
error_log('FAILED - header signature missing');
|
||||
exit();
|
||||
}
|
||||
|
||||
// calculate payload signature
|
||||
$payload_signature = hash_hmac('sha256', $payload, $secret_key, false);
|
||||
|
||||
// check payload signature against header signature
|
||||
if ($header_signature != $payload_signature) {
|
||||
error_log('FAILED - payload signature');
|
||||
exit();
|
||||
}
|
||||
|
||||
// convert json to array
|
||||
$decoded = json_decode($payload, true);
|
||||
|
||||
// check for json decode errors
|
||||
if (json_last_error() !== JSON_ERROR_NONE) {
|
||||
error_log('FAILED - json decode - '. json_last_error());
|
||||
exit();
|
||||
}
|
||||
|
||||
// success, do something
|
||||
```
|
||||
|
||||
There is a Test Delivery button in the webhook settings that allows to test the configuration as well as a list of the most Recent Deliveries.
|
||||
6
doc/advanced/third-party-tools.md
Normal file
6
doc/advanced/third-party-tools.md
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: "Third Party Tools"
|
||||
---
|
||||
|
||||
# Third-party tools
|
||||
Check out [awesome-gitea](https://gitea.com/gitea/awesome-gitea/src/branch/master/README.md) for a comprehensive list of tools that work with Codeberg!
|
||||
|
Before Width: | Height: | Size: 61 KiB After Width: | Height: | Size: 61 KiB |
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
title: "Clone & commit via HTTP (username & password)"
|
||||
---
|
||||
|
||||
# Clone & commit via HTTP (username & password)
|
||||
The user in this examples is `JohnDoe` and it's repository is `foobar`. The repository was created via the Codeberg.org website including a `README.md` file.
|
||||
|
||||
|
|
@ -1,4 +1,8 @@
|
|||
# Clone
|
||||
---
|
||||
title: "Clone & commit via SSH"
|
||||
---
|
||||
|
||||
# Clone & commit via SSH
|
||||
The user in this examples is `JohnDoe` and it's repository is `foobar`. The repository was [created](https://codeberg.org/Codeberg/Documentation/wiki/Create-repository---Local-and-on-Codeberg) via the Codeberg.org website including a `README.md` file.
|
||||
|
||||
```bash
|
||||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
title: "SSH key for Codeberg"
|
||||
---
|
||||
|
||||
# Introduction
|
||||
It is recommanded to use one key per client. It means if you access your Codeberg repository from your home PC, your laptop and your office PC you should generate spearate keys for each machine.
|
||||
It is reccomended to use one key per client. It means if you access your Codeberg repository from your home PC, your laptop and your office PC you should generate spearate keys for each machine.
|
||||
|
||||
In the context of Codeberg you should decide yourself if you add a pasphrase to your SSH key or not. Read the on-going discussion about that topic in this [Codeberg-Issue](https://codeberg.org/Codeberg/Documentation/issues/2).
|
||||
|
||||
|
Before Width: | Height: | Size: 66 KiB After Width: | Height: | Size: 66 KiB |
|
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
|
|
@ -1,11 +1,15 @@
|
|||
---
|
||||
title: "Create a repository"
|
||||
---
|
||||
|
||||
# Create a Codeberg repository
|
||||
To create a new repository you need to login into your account on Codeberg.org.
|
||||
|
||||
After login you can use one of the two buttons shown in the two following pictures.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Note it is not possible to use your git on your local machine to push a fresh repository on Codeberg.
|
||||
# Connect a local repository to Codeberg
|
||||
|
Before Width: | Height: | Size: 2.2 KiB After Width: | Height: | Size: 2.2 KiB |
33
doc/getting-started/usage/issue-pull-request-templates.md
Normal file
33
doc/getting-started/usage/issue-pull-request-templates.md
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
title: "Issue and Pull Request templates"
|
||||
---
|
||||
|
||||
# Issue and Pull Request Templates
|
||||
|
||||
Some projects have a standard list of questions that users need to answer
|
||||
when creating an issue or pull request. Gitea supports adding templates to the
|
||||
main branch of the repository so that they can autopopulate the form when users are
|
||||
creating issues and pull requests. This will cut down on the initial back and forth
|
||||
of getting some clarifying details.
|
||||
|
||||
Possible file names for issue templates:
|
||||
|
||||
* ISSUE_TEMPLATE.md
|
||||
* issue_template.md
|
||||
* .gitea/ISSUE_TEMPLATE.md
|
||||
* .gitea/issue_template.md
|
||||
* .github/ISSUE_TEMPLATE.md
|
||||
* .github/issue_template.md
|
||||
|
||||
|
||||
Possible file names for PR templates:
|
||||
|
||||
* PULL_REQUEST_TEMPLATE.md
|
||||
* pull_request_template.md
|
||||
* .gitea/PULL_REQUEST_TEMPLATE.md
|
||||
* .gitea/pull_request_template.md
|
||||
* .github/PULL_REQUEST_TEMPLATE.md
|
||||
* .github/pull_request_template.md
|
||||
|
||||
|
||||
Additionally, the New Issue page URL can be suffixed with `?body=Issue+Text` and the form will be populated with that string. This string will be used instead of the template if there is one.
|
||||
162
doc/getting-started/usage/linked-references.md
Normal file
162
doc/getting-started/usage/linked-references.md
Normal file
|
|
@ -0,0 +1,162 @@
|
|||
---
|
||||
title: "Automatically Linked References"
|
||||
---
|
||||
|
||||
# Automatically Linked References in Issues, Pull Requests and Commit Messages
|
||||
|
||||
When an issue, pull request or comment is posted, the text description is parsed
|
||||
in search for references. These references will be shown as links in the Issue View
|
||||
and, in some cases, produce certain _actions_.
|
||||
|
||||
Likewise, commit messages are parsed when they are listed, and _actions_
|
||||
are can be triggered when they are pushed to the main branch.
|
||||
|
||||
To prevent the creation of unintended references, there are certain rules
|
||||
for them to be recognized. For example, they should not be included inside code
|
||||
text. They should also be reasonably cleared from their surrounding text
|
||||
(for example, using spaces).
|
||||
|
||||
## User, Team and Organization Mentions
|
||||
|
||||
When a text in the form `@username` is found and `username` matches the name
|
||||
of an existing user, a _mention_ reference is created. This will be shown
|
||||
by changing the text into a link to said user's profile, and possibly create
|
||||
a notification for the mentioned user depending on whether they have
|
||||
the necessary permission to access the contents.
|
||||
|
||||
Example:
|
||||
|
||||
> [@John](#), can you give this a look?
|
||||
|
||||
This is also valid for teams and organizations:
|
||||
|
||||
> [@Documenters](#), we need to plan for this.
|
||||
|
||||
> [@CoolCompanyInc](#), this issue concerns us all!
|
||||
|
||||
Teams will receive mail notifications when appropriate, but whole organizations won't.
|
||||
|
||||
Commit messages do not produce user notifications.
|
||||
|
||||
## Commits
|
||||
|
||||
Commits can be referenced using their SHA1 hash, or a portion of it of
|
||||
at least seven characters. They will be shown as a link to the corresponding
|
||||
commit.
|
||||
|
||||
Example:
|
||||
|
||||
> This bug was introduced in [e59ff077](#)
|
||||
|
||||
## Issues and Pull Requests
|
||||
|
||||
A reference to another issue or pull request can be created using the simple
|
||||
notation `#1234`, where _1234_ is the number of an issue or pull request
|
||||
in the same repository. These references will be shown as links to the
|
||||
referenced content.
|
||||
|
||||
The effect of creating this type of reference is that a _notice_ will be
|
||||
created in the referenced document, provided the creator of the reference
|
||||
has reading permissions on it.
|
||||
|
||||
Example:
|
||||
|
||||
> This seems related to [#1234](#)
|
||||
|
||||
Issues and pull requests in other repositories can be referred to as well
|
||||
using the form `owner/repository#1234`:
|
||||
|
||||
> This seems related to [mike/compiler#1234](#)
|
||||
|
||||
Alternatively, the `!1234` notation can be used as well. Even when in Gitea
|
||||
a pull request is a form of issue, the `#1234` form will always link to
|
||||
an issue; if the linked entry happens to be a pull request instead, Gitea
|
||||
will redirect as appropriate. With the `!1234` notation, a pull request
|
||||
link will be created, which will be redirected to an issue if required.
|
||||
However, this distinction could be important if an external tracker is
|
||||
used, where links to issues and pull requests are not interchangeable.
|
||||
|
||||
## Actionable References in Pull Requests and Commit Messages
|
||||
|
||||
Sometimes a commit or pull request may fix or bring back a problem documented
|
||||
in a particular issue. Gitea supports closing and reopening the referenced
|
||||
issues by preceding the reference with a particular _keyword_. Common keywords
|
||||
include "closes", "fixes", "reopens", etc. This list can be customized by the
|
||||
site administrator.
|
||||
|
||||
Example:
|
||||
|
||||
> This PR _closes_ [#1234](#)
|
||||
|
||||
If the actionable reference is accepted, this will create a notice on the
|
||||
referenced issue announcing that it will be closed when the referencing PR
|
||||
is merged.
|
||||
|
||||
For an actionable reference to be accepted, _at least one_ of the following
|
||||
conditions must be met:
|
||||
|
||||
* The commenter has permissions to close or reopen the issue at the moment
|
||||
of creating the reference.
|
||||
* The reference is inside a commit message.
|
||||
* The reference is posted as part of the pull request description.
|
||||
|
||||
In the last case, the issue will be closed or reopened only if the merger
|
||||
of the pull request has permissions to do so.
|
||||
|
||||
Additionally, only pull requests and commit messages can create an action,
|
||||
and only issues can be closed or reopened this way.
|
||||
|
||||
The default _keywords_ are:
|
||||
|
||||
* **Closing**: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved
|
||||
* **Reopening**: reopen, reopens, reopened
|
||||
|
||||
## External Trackers
|
||||
|
||||
Gitea supports the use of external issue trackers, and references to issues
|
||||
hosted externally can be created in pull requests. However, if the external
|
||||
tracker uses numbers to identify issues, they will be indistinguishable from
|
||||
the pull requests hosted in Gitea. To address this, Gitea allows the use of
|
||||
the `!` marker to identify pull requests. For example:
|
||||
|
||||
> This is issue [#1234](#), and links to the external tracker.
|
||||
|
||||
> This is pull request [!1234](#), and links to a pull request in Gitea.
|
||||
|
||||
The `!` and `#` can be used interchangeably for issues and pull request _except_
|
||||
for this case, where a distinction is required. If the repository uses external
|
||||
tracker, commit message for squash merge will use `!` as reference by default.
|
||||
|
||||
## Issues and Pull Requests References Summary
|
||||
|
||||
This table illustrates the different kinds of cross-reference for issues and pull requests.
|
||||
In the examples, `User1/Repo1` refers to the repository where the reference is used, while
|
||||
`UserZ/RepoZ` indicates a different repository.
|
||||
|
||||
| Reference in User1/Repo1 | Repo1 issues are external | RepoZ issues are external | Should render |
|
||||
|---------------------------|:-------------------------:|:-------------------------:|----------------------------------|
|
||||
| `#1234` | no | N/A | A link to issue/pull 1234 in `User1/Repo1` |
|
||||
| `!1234` | no | N/A | A link to issue/pull 1234 in `User1/Repo1` |
|
||||
| `#1234` | yes | N/A | A link to _external issue_ 1234 for `User1/Repo1` |
|
||||
| `!1234` | yes | N/A | A link to _PR_ 1234 for `User1/Repo1` |
|
||||
| `User1/Repo1#1234` | no | N/A | A link to issue/pull 1234 in `User1/Repo1` |
|
||||
| `User1/Repo1!1234` | no | N/A | A link to issue/pull 1234 in `User1/Repo1` |
|
||||
| `User1/Repo1#1234` | yes | N/A | A link to _external issue_ 1234 for `User1/Repo1` |
|
||||
| `User1/Repo1!1234` | yes | N/A | A link to _PR_ 1234 for `User1/Repo1` |
|
||||
| `UserZ/RepoZ#1234` | N/A | no | A link to issue/pull 1234 in `UserZ/RepoZ` |
|
||||
| `UserZ/RepoZ!1234` | N/A | no | A link to issue/pull 1234 in `UserZ/RepoZ` |
|
||||
| `UserZ/RepoZ#1234` | N/A | yes | A link to _external issue_ 1234 for `UserZ/RepoZ` |
|
||||
| `UserZ/RepoZ!1234` | N/A | yes | A link to _PR_ 1234 for `UserZ/RepoZ` |
|
||||
| **Alphanumeric issue IDs:** | - | - | - |
|
||||
| `AAA-1234` | yes | N/A | A link to _external issue_ `AAA-1234` for `User1/Repo1` |
|
||||
| `!1234` | yes | N/A | A link to _PR_ 1234 for `User1/Repo1` |
|
||||
| `User1/Repo1!1234` | yes | N/A | A link to _PR_ 1234 for `User1/Repo1` |
|
||||
| _Not supported_ | N/A | yes | A link to _external issue_ `AAA-1234` for `UserZ/RepoZ` |
|
||||
| `UserZ/RepoZ!1234` | N/A | yes | A link to _PR_ 1234 in `UserZ/RepoZ` |
|
||||
|
||||
_The last section is for repositories with external issue trackers that use alphanumeric format._
|
||||
|
||||
_**N/A**: not applicable._
|
||||
|
||||
Note: automatic references between repositories with different types of issues (external vs. internal) are not fully supported
|
||||
and may render invalid links.
|
||||
|
Before Width: | Height: | Size: 8.3 KiB After Width: | Height: | Size: 8.3 KiB |
|
|
@ -1,8 +1,14 @@
|
|||
---
|
||||
title: "Pull requests and Git flow"
|
||||
---
|
||||
|
||||
# Pull requests and Git flow
|
||||
|
||||
## Benefits of a pull-request based workflow
|
||||
|
||||
> ***&TLDR;*** *Keep an eye on your repository and org permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners need full access to the repo to merge them.*
|
||||
> ***TLDR:*** *Keep an eye on your repository and org permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners need full access to the repo to merge them.*
|
||||
|
||||
Although it is perfectly possible to use a GIT project on Codeberg just as single shared central repository for individuals and teams, a collaborative workflow based on pull requests provides many benefits:
|
||||
Although it is perfectly possible to use a Git project on Codeberg just as single shared central repository for individuals and teams, a collaborative workflow based on pull requests provides many benefits:
|
||||
|
||||
- The "hot" project repository requires only very few maintainers with full rights to sign off pull requests. Contributors can easily work on forked repositories.
|
||||
- Each pull request collects the full edit history for a fix or feature branch. Contributors can squash this, or keep it, just as they prefer.
|
||||
|
|
@ -13,7 +19,7 @@ Let's say, you would like to contribute to project [https://codeberg.org/Codeber
|
|||
|
||||
First, fork the project you would like to work on, by clicking the `fork` button on the top-right corner of the project page:
|
||||
|
||||
|
||||
|
||||
|
||||
Then clone it onto your local machine. We assume that you have set up your SSH keys as described in [SSH-key-for-Codeberg](https://codeberg.org/Codeberg/Documentation/wiki/SSH-key-for-Codeberg). This has to be done only once:
|
||||
|
||||
|
|
@ -39,7 +45,7 @@ git push
|
|||
|
||||
Now you can create the pull request by selecting your feature branch, and clicking on the pull request button:
|
||||
|
||||
|
||||
|
||||
|
||||
### Keep it up-to-date: rebase pull requests to upstream
|
||||
|
||||
|
|
@ -60,6 +66,10 @@ git pull
|
|||
|
||||
That's it. You can now push your changes, and create the pull request as usual by clicking on the "pull request" button.
|
||||
|
||||
## "Work In Progress" pull requests
|
||||
|
||||
Marking a pull request as being a work in progress will prevent that pull request from being accidentally merged. To mark a pull request as being a work in progress, you must prefix its title by `WIP:` or `[WIP]` (case insensitive).
|
||||
|
||||
## A friendly note on owner rights, and forced push permissions
|
||||
|
||||
Please keep in mind that project owners can do *everything*, including editing and rewriting the history using `force-push`. In some cases this is a useful feature (for example to undo accidental commits that, say, leaked credentials), but in most cases a transparent history based on a pull-request based workflow is surely preferable.
|
||||
|
|
@ -1,3 +1,8 @@
|
|||
---
|
||||
title: "Merge multiple commits into one"
|
||||
---
|
||||
|
||||
# Merge multiple commits into one
|
||||
Sometimes you will merge multiple commits into one. Maybe the commits are "dirty" full with not working code or embarrasing commit messages. This solution is only one of mutliple possible solutions. See this [stackoverflow question](https://stackoverflow.com/q/2563632/4865723) for more details and variants.
|
||||
|
||||
Here is an example.
|
||||
|
|
@ -1,3 +1,9 @@
|
|||
---
|
||||
title: "Including images in wiki pages"
|
||||
---
|
||||
|
||||
# Including images in wiki pages
|
||||
|
||||
### Upload images via git
|
||||
|
||||
Currently, gitea supports only images in the base directory of the wiki git. (Gitea wiki pages are stored in a separate wiki right beside the project, wiki pages themselves are markdown files).
|
||||
|
|
@ -19,8 +25,6 @@ Now, you can reference the image in markdown, like this:
|
|||
|
||||
```
|
||||
|
||||
After saving your changes, the image should be visible like this:
|
||||
After saving your changes, the image should be visible.
|
||||
|
||||
*NOTE: In contrast to embedding external images, images in git are only rendered after saving the wiki or markdown file changes.*
|
||||
|
||||
|
||||
28
doc/help/faq.md
Normal file
28
doc/help/faq.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
---
|
||||
title: "FAQ"
|
||||
---
|
||||
|
||||
# Frequently Asked Questions
|
||||
|
||||
This page contains some common questions and answers.
|
||||
|
||||
* [How to migrate from GitHub/etc. to Codeberg](#how-to-migrate-from-gogs-github-etc-to-codeberg)
|
||||
* [Translation is incorrect/how to add more translations](#translation-is-incorrect-how-to-add-more-translations)
|
||||
* [Hooks aren't running](#hooks-aren-t-running)
|
||||
* [Why is my markdown broken](#why-is-my-markdown-broken)
|
||||
|
||||
## How to migrate from GitHub/etc. to Codeberg
|
||||
To migrate from GitHub to Codeberg, you can use the built-in migration form.
|
||||
In order to migrate items such as issues, pull requests, etc. you will need to input at least your username.
|
||||
[Try it out!](https://codeberg.org/repo/migrate)
|
||||
|
||||
To migrate from Gitlab to Codeberg, you can use this non-affiliated tool:
|
||||
https://github.com/loganinak/MigrateGitlabToGogs
|
||||
|
||||
## Translation is incorrect/how to add more translations
|
||||
Our translations are currently crowd-sourced from the Gitea [Crowdin project](https://crowdin.com/project/gitea).
|
||||
|
||||
## Why is my markdown broken
|
||||
Gitea version `1.11` moved to using [goldmark](https://github.com/yuin/goldmark) for markdown rendering, which is [CommonMark](https://commonmark.org/) compliant.
|
||||
If you have markdown that worked as you expected prior to version `1.11` and after upgrading it's not working anymore, please look through the CommonMark spec to see whether the problem is due to a bug or non-compliant syntax.
|
||||
If it is the latter, _usually_ there is a compliant alternative listed in the spec.
|
||||
7
doc/help/issues.md
Normal file
7
doc/help/issues.md
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
title: "Issue"
|
||||
---
|
||||
|
||||
# Issues
|
||||
|
||||
If you found any issues with Codeberg, please create an [issue on Codeberg/Community](https://codeberg.org/Codeberg/Community/issues).
|
||||
Loading…
Reference in a new issue