stage | group | info |
---|---|---|
none |
unassigned |
Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review. |
We welcome merge requests from everyone, with fixes and improvements
to GitLab code, tests, and documentation. The issues that are specifically suitable
for community contributions have the
Seeking community contributions
label, but you are free to contribute to any issue you want.
If you find an issue, submit a merge request with a fix or improvement, if you can, and include tests.
If you want to add a new feature that is not labeled, it is best to first create
an issue (if there isn't one already) and leave a comment asking for it
to be labeled as Seeking community contributions
. See the feature proposals
section.
If you don't know how to fix the issue but can write a test that exposes the issue, we will accept that as well. In general, bug fixes that include a regression test are merged quickly. New features without proper tests might be slower to receive feedback.
If you are new to GitLab development (or web development in general), see the how to contribute section to get started with some potentially easy issues.
If an issue is marked for the current milestone at any time, even when you are working on it, a GitLab team member may take over the merge request to ensure the work is finished before the release date.
If a contributor is no longer actively working on a submitted merge request, we can:
We make this decision based on how important the change is for our product vision. If a merge
request coach is going to finish the merge request, we assign the
~coach will finish
label.
When a team member picks up a community contribution, we credit the original author by adding a changelog entry crediting the author and optionally include the original author on at least one of the commits within the MR.
For a walkthrough of the contribution process, see Tutorial: Make a GitLab contribution.
If the change is non-trivial, we encourage you to start a discussion with a product manager or a member of the team. You can do this by tagging them in an MR before submitting the code for review. Talking to team members can be helpful when making design decisions. Communicating the intent behind your changes can also help expedite merge request reviews.
Consider placing your code behind a feature flag if you think it might affect production availability. Not sure? Read When to use feature flags.
If you would like quick feedback on your merge request feel free to mention someone from the core team or one of the merge request coaches. When having your code reviewed and when reviewing merge requests, keep the code review guidelines in mind. And if your code also makes changes to the database, or does expensive queries, check the database review guidelines.
Live by smaller iterations. Keep the amount of changes in a single MR as small as possible. If you want to contribute a large feature, think very carefully about what the minimum viable change is. Can you split the functionality into two smaller MRs? Can you submit only the backend/API code? Can you start with a very simple UI? Can you do just a part of the refactor?
Small MRs which are more easily reviewed, lead to higher code quality which is more important to GitLab than having a minimal commit log. The smaller an MR is, the more likely it will be merged quickly. After that you can send more MRs to enhance and expand the feature. The How to get faster PR reviews document from the Kubernetes team also has some great points regarding this.
Commit messages should follow the guidelines below, for reasons explained by Chris Beams in How to Write a Git Commit Message:
Important notes:
[prefix]
and prefix:
are allowed (they can be all lowercase, as long
as the message itself is capitalized). For instance, danger: Improve Danger behavior
and
[API] Improve the labels endpoint
are valid commit messages.Example commit message template that can be used on your machine that embodies the above (guide for how to apply template):
# (If applied, this commit will...) <subject> (Max 72 characters)
# |<---- Using a Maximum Of 72 Characters ---->|
# Explain why this change is being made
# |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->|
# Provide links or keys to any relevant tickets, articles or other resources
# Use issues and merge requests' full URLs instead of short references,
# as they are displayed as plain text outside of GitLab
# --- COMMIT END ---
# --------------------
# Remember to
# Capitalize the subject line
# Use the imperative mood in the subject line
# Do not end the subject line with a period
# Subject must contain at least 3 words
# Separate subject from body with a blank line
# Commits that change 30 or more lines across at least 3 files should
# describe these changes in the commit body
# Do not use Emojis
# Use the body to explain what and why vs. how
# Can use multiple lines with "-" for bullet points in body
# For more information: https://cbea.ms/git-commit/
# --------------------
To make sure that your merge request can be approved, ensure that it meets the contribution acceptance criteria below:
QueryRecorder
.Dependencies that need approval
error. Also, make the reviewer aware of the new
library and explain why you need it.If you contribute to GitLab, know that changes involve more than just code. We use the following definition of done. To reach the definition of done, the merge request must create no regressions and meet all these criteria:
If a regression occurs, we prefer you revert the change. Your contribution is incomplete until you have made sure it meets all of these requirements.
Working and clean code that is commented where needed.
The change is evaluated to limit the impact of far-reaching work.
Performance guidelines have been followed.
Secure coding guidelines have been followed.
Application and rate limit guidelines have been followed.
Documented in the /doc
directory.
If your MR touches code that executes shell commands, reads or opens files, or handles paths to files on disk, make sure it adheres to the shell command guidelines
If your code needs to handle file storage, see the uploads documentation.
If your merge request adds one or more migrations, make sure to execute all migrations on a fresh database before the MR is reviewed. If the review leads to large changes in the MR, execute the migrations again after the review is complete.
If your merge request adds new validations to existing models, to make sure the data processing is backwards compatible:
#database
Slack channel
for assistance to execute the database query that checks the existing rows to
ensure existing rows aren't impacted by the change.If this merge request is urgent, the code owners should make the final call on whether reviewing existing rows should be included as an immediate follow-up task to the merge request.
NOTE: There isn't a way to know anything about our customers' data on their self-managed instances, so keep that in mind for any data implications with your merge request.
Consider self-managed functionality and upgrade paths. The change should consider both:
Upgrade stops are sometimes requested when a GitLab code change is dependent upon a background migration being already complete. Ideally, changes causing required upgrade stops should be held for the next major release, or at least a 3 milestones notice in advance if unavoidable.
grep css-class ./app -R
.doc/install/installation.md
in
the same merge request.doc/update/upgrading_from_source.md
in the same merge request. If these
instructions are specific to a version, add them to the "Version specific
upgrading instructions" section.The following items are checked after the merge request has been merged:
Contributions do not require approval from the Product team.
If you add a dependency in GitLab (such as an operating system package), consider updating the following, and note the applicability of each in your merge request:
We allow engineering time to fix small problems (with or without an issue) that are incremental improvements, such as:
Tag a merge request with ~"Stuff that should Just Work" to track work in this area.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。