Commit and merge request

You must add all the files of your solution in only one commit. Read the GitLab documentation to learn the commit concept.

Commit message

Syntax

Valid commit messages have the structure:

[product]\[type]([scope]): #[issue-number]{.issue-part} [title] // This is the commit title
// This blank line separates the commit title from the commit body
[body] // - This is the commit body. It CAN have multiple lines

• [variable] is a required variable. Replace it in the final commit message, and remove the [] symbols.
• {variable} is an optional variable. Replace it or remove it in the final commit message, and remove the {} symbols.
• // Comment is a comment. Remove all the comments from the final commit message.

Rules

A commit message must obey all these rules.

1. [product] variable must be one of these:

   all // Transversal changes that affect several products,
   // this label will run all existent pipelines
   app // Changes related with app (front, back, infra)
   chall // Changes related with challenges solutions files
   common // Repo-wide registration commits not tied to a single product
   docs // Changes on documentation (front, back, infra)
   nix // Changes related with Nix (build, infra)

2. [type] variable must be one of these:

   rever // Revert to a previous commit in history
   feat // New feature
   perf // Improves performance
   fix // Bug fix
   refac // Neither fixes a bug or adds a feature
   test // Adding missing tests or correcting existing tests
   style // Do not affect the meaning of the code (formatting, etc)
   chore // Routine task or registration commit
   sol // Hacking solution only for writeups and training repo

3. [scope] variable must be one of these:

   front // Front-End change
   back // Back-End change
   infra // Infrastructure change
   conf // Configuration files change
   build // Build system, CI, compilers, etc (scons, webpack...)
   job // asynchronous or scheduled tasks (backups, maintenance...)
   cross // Mix of two or more scopes
   doc // Documentation only changes
   vbd // Vulnerable by design hacking solution only for writeups repo
   code // Programming challenge solution only for training repo
   hack // CTF-hacking challenge solution only for training repo

4. A commit title must exist.

5. A commit title must not contain the : character.

6. A commit title must have 80 characters or less.

7. A commit title must be lower case.

8. A commit title must not finish with a dot ..

9. A commit title must reference an issue.

10. A commit title must give information. Do not write a title such as app\feat(build): #5.1 feature.

11. If a commit title has sol type, it must reference issue #0.

12. If a commit title has sol type, the part after #0 must have one of these two shapes:

    • <site-name>, <chall-code> (<complexity>) for a code scope or for a hack scope.
    • <site-name>, <chall-code> for a vbd scope.

    A comma and one space separate the two names, and one space precedes the parenthesis. Each name accepts only lowercase letters, digits and hyphens.

13. A commit body must exist. One blank line, and only one, separates the body from the title. The body tells what the commit changes.

14. A commit body must have 15 characters or more.

15. Each line in the commit body must start with - , a dash and a space, for a new item. To continue the previous item, start the line with a space. The commit body does not accept a paragraph of prose.

16. Lines in the commit body must have 72 characters or less.

17. Your branch must be ahead of master by exactly one commit. If you made more than one, squash them into one before you push.

Possible combinations

This table gives all the possible combinations of type and scope for a commit message. The columns are the types, and the rows are the scopes.

Where:

• perf is performance.
• infra is infrastructure.
• conf is configuration.
• doc is documentation.
• NA is not applicable.

Recommendations

• Write your commit body as a list of items:

  - Add feature X in file Y
  - Run script Z
  - Remove file A with B purpose

• Do not use the word part when you divide the commits or the merge requests of one issue. Use #[issue-number]{.issue-part}. The example below shows it.

Example

This is an example of a correct commit message. The issue number has .1 after it, because this commit is part 1 of the solution of the issue:

nix\feat(build): #13.1 add type_check

- Add type_check function
- Remove unnecessary print_output function

The repository has two templates for challenges: the hacking-ctf and code template and the hacking VbD template. This is an example for code:

chall\sol(code): #0 codeabbey, 001 (1.00)

- Dart solution

The first contribution of a talent to the repository is the registration commit. That commit contains the .mailmap entry and the users/<assigned-nickname>.yml file. This is its commit message:

common\chore(conf): #0 first commit

- register <assigned-nickname>

See First commit for the full flow.

Merge request

When your commit passes all the pipelines, you can open a merge request to the master branch. A complete and correct pipeline shows the color green. If a reviewer rejects the merge request, do not open it again. Correct the errors and send the new solution in a new merge request.

Differences from commit messages

A merge request message is the same as a commit message, with two differences:

1. The [type] of the merge request must be the most relevant type of all its commits. This is the relevance list:

   rever
   feat
   perf
   fix
   refac
   test
   style
   sol

   rever has the highest relevance, and sol has the lowest. For example, your merge request has one feat commit, one test commit and one style commit. Then its [type] must be feat.

2. The merge request message can have a Closes #{issue-number} line in its footer. This line is not necessary. When a reviewer accepts the merge request, GitLab closes the issue automatically.

Merge request example

This is an example of a correct merge request message:

app\feat(build): #13.3 new checks to the pipeline

- Add type_check
- Add deltas_check
- Add commit_number check

Closes #13

The Closes #13 footer closes issue 13 automatically, when a reviewer accepts this merge request.