Commit

Remember that you must add all the files related to your solution in only one commit. We invite you to get familiar with the commit concept by reading the Gitlab documentation.

1.1 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] are required variables that must be replaced in a final commit message ([] symbols must be removed)

• {variable} are optional variables that must be replaced or removed in a final commit message ( symbols must be removed)

• // Comment are comments that must be removed in a final commit message

1.2 Rules

The following rules must be met for a commit message to be valid, the product rule only required for the integrates repository:

1. [product] variable has to be one of the following:

    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
    docs // Changes on documentation (front, back, infra)
    makes // Changes related with Makes (build, infra)

1. [type] variable has to be one of the following:

    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)
    sol // Hacking solution only for writeups and training repo

1. [scope] variable has to be one of the following:

    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

1. A Commit title must exist.

2. A Commit title must not contain the ':' character.

3. Commit title must have 60 characters or less.

4. Commit title must be lower case.

5. Commit title must not finish with a dot '.'.

6. Commit title must reference an issue.

7. Commit title must be meaningful. Avoid using things like feat(build)[integrates]: #5.1 feature.

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

9. A commit body mustn't exist.

10. Lines in commit body must have 72 characters or less.

1.3 Possible combinations

Below is a table explaining all the possible combinations between types and scopes for a commit message (Types are columns, scopes are rows):

Where:

• perf is performance.

• infra is infrastructure.

• config is configuration.

• doc is documentation.

• NA is not applicable.

1.4 Recommendations

• Try to itemize your commit body:

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

• Do not use the word 'part' for splitting commits or MRs for a single issue. Use #[issue-number]{.issue-part} instead as shown in Example

1.5 Example

Here is an example of a compliant commit message (Notice how the issue has a '.1' right after, meaning that such commit is the part 1 for solving the issue):

makes\feat(build): #13.1 add type_check
 
- Add type_check function
- Remove unnecessary print_output function

for challenges we have a hacking-ctf and code template and a hacking VbD template and this is an example for code:

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