Submit a change

You have a change finished and want to give it back.

There are two ways, and which applies depends on the scope. A single text file can be created or edited and committed directly in the repository screen. Anything touching several files, binary, or needing a local build and check goes back through the Git endpoint.

The two ways do not need the same permission, and that is the commonest reason why one works and the other does not:

Viewing and obtaining suffice for neither. Which level a mount grants to whom is at Clone a repository; the level propose is granted by none of the templates there, it arises only from a rule written specially.

Way 1 — a single text file in the browser

1. Open the repository from Repositories.
2. Check in the header which branch you are on — that is where the commit goes. Another can be chosen there.
3. An existing file: open it in the tree, change the content, commit with a description. See Edit a file.
4. A new file: New file in the header, enter path and content, commit. Where something already lies under that path it is refused and nothing is written. See Create a new file (German).
5. Where your permission does not suffice, these options do not appear.

Binary files — images, archives, fonts — do not go this way. Way 2 applies for those.

Way 2 — locally, through Git

1. Check your change against the five acceptance steps from Set up a development environment.
2. Run the style check and fix the mechanically fixable findings:

composer cs
composer cbf

1. Bring the changed package's manifest date up to date. It is the signal by which an update is recognised at all; left standing, the package reports itself as the previous revision.
2. Write the commit text so that it names its work item on a closing line of its own. Without that line no link arises between work item and code, and there is no warning about it.
3. Give it back:

git push

On the level propose the endpoint accepts only branches under your own prefix and refuses everything else with push refused: outside_own_prefix. The branch name and the two commands needed for it are named at Clone a repository.

A refused push is usually a permission question, not a fault. Where the section Dieses Repository beziehen carries the note about read-only access, a push is refused; the way onward is then Request access. Where the note does not appear and it is refused all the same, it is the branch name and not the permission — the endpoint's message tells the two cases apart.

Not settled: branch, review, merge. For this undertaking there is no binding branching model, no review procedure and no merge rule. This guide invents none; it describes what the platform does. Which branch applies in a given case and who reviews, settle with the project's leadership. The full state is at State of the contribution rules.

No changelog as an obligation. Of the own packages, one keeps a changelog; a consistent convention does not exist.

Do not forget the languages. Where a change touches interface texts, they belong in all five language files. A missing entry does not show an error but the bare key name.

• Set up a development environment
• State of the contribution rules
• Clone a repository
• Edit a file in the browser — the first way in detail
• Create a new file in the browser (German) — the same way for a file that does not exist yet