| [ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
| [ < Lifecycle of a merge request ] | [ Up : Lifecycle of a merge request ] | [ Automated testing > ] |
3.3.1 Uploading a patch for review
- Any non-trivial change should be reviewed as a merge request:
- Ensure your branch differs from latest
masterby just the changes to be uploaded. - Make sure that
make,make test, andmake docsucceed. Even if the individual commits contain incomplete features, they must all pass these tests. - The names of branches pushed on the main repository should start
with
dev/. - After pushing, create a merge request to start the review cycle. There are multiple options for this as outlined in GitLab’s documentation. This will also ask you for a message that will accompany your patch.
- If you are not a member of the team and create the merge request from a fork, consider enabling the box to “Allow commits from members who can merge to the target branch”. This makes it possible for somebody with permissions to rebase your changes and merge them for you. Please refer to Merging to master for more details.
Note: When commenting on GitLab, be careful if you talk about
Texinfo markup. An ‘@’ sign starts a reference to a person
or a group. If you leave it without special markup, ‘@foo’
makes the person who has foo as a GitLab username receive
unsolicited notifications. To avoid this, enclose the markup in
backticks: `@lilypond`. For code suggestions, there is
also a dedicated feature, see
the GitLab documentation for information.
| [ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
| [ < Lifecycle of a merge request ] | [ Up : Lifecycle of a merge request ] | [ Automated testing > ] |