Resolve "ILT - Remove Redundant Labs from GitLab Professional Education Services Page"

- [Live Instructor-led training (ILT)](https://about.gitlab.com/services/education/)

- [GitLab Technical Certifications](/handbook/customer-success/professional-services-engineering/gitlab-technical-certifications/) as Professional Service offerings.

- [Train-the-Trainer](https://university.gitlab.com/pages/train-the-trainer-training/)

- [Certified Training Partner (CTP) Award](/handbook/customer-success/professional-services-engineering/gitlab-certified-training-partner-award/)

### Immediate Priorities

- [Professional Education Services Project Issues List](https://gitlab.com/gitlab-com/customer-success/professional-services-group/education-services/-/issues)

- EdCast LXP/Marketplace User Instructions

- [Thought Industries LMS Tech Stack Guide](/handbook/customer-success/professional-services-engineering/education-services/lms/)

### GitLab Training Certified Training Partners

Our Certified Training Partner recognition is awarded to partners who have proven themselves capable of delivering a high quality level of training on a consistent basis. The award is aimed to give partners an easy way of signposting to consumers of training a GitLab-official recognition of the quality of their delivery.

#### Benefits

Once a partner has obtained the CTP award, they will get the following benefits:

1. A GitLab-official badge to be used on Partner website / social media / customer communication channels.

1. Fast-track onboarding of new trainers.

## Who Can Apply?

We welcome applications from any existing GitLab partner, whether on the Open or Select partner track. 

## Service Offerings

CTPs can provide [GitLab Education Services](https://about.gitlab.com/services/education/) by purchasing GitLab Student Kits and then delivering instructor-led training courses using the official GitLab training materials and lab environments.

## Requirements

- Complete the CTP contract Master Service Agreement and legal exhibit

- At least 2 x GitLab-certified trainers as full-time employees.

- The training team must collectively be certified to deliver at least 4 standard GitLab training courses, with CI/CD and Security Essentials as mandatory inclusions.

## Requirement Examples

Partner X has two certified trainers. Trainer #1 is certified to deliver the GitLab Fundamentals course. Trainer #2 is certified to deliver the GitLab CI/CD, Security Essentials and Advanced CI/CD course. This **does** meet the requirements for CTP, as there are 2 certified trainers who can run 4 different courses between them.

Partner Y has four certified trainers. Trainer #1 is certified to deliver the CI/CD course. Trainer #2 is certified to deliver the Advanced CI/CD course. Trainer #3 is certified to deliver the Security Essentials course. Trainer #4 is certified to deliver the Compliance course. This **does** meet the requirements for CTP, as there are 4 certified trainers who can run 4 different courses between them. 

Partner Z has three certified trainers. Trainer #1 is certified to deliver the GitLab Fundamentals course. Trainer #2 is certified to deliver the CI/CD course and the Security Essentials course. Trainer #3 is also certified to deliver the GitLab Fundamentals course and Security Essentials course. This **does not** meet the requirements for CTP, as collectively the training team is only certified to deliver 3 of the standard courses. 

## How To Apply

Email training@gitlab.com with the names of your certified trainers, and the courses that they are GitLab-certified to deliver. 

## Ongoing Terms

- The CTP Partner must send the GitLab official feedback survey to the attendees of every training session.

- Partners are expected to achieve average CSAT scores of 8+. Dropping below this will result in a review of CTP status.

- The CTP award must be applied for and renewed each year. This takes the same form as the original application list above. 

- CTP partners must use the official GitLab training materials for all standard (non-bespoke) training courses.

---

title: "GitLab with Git Fundamentals - Hands-On Lab Overview"

description: "This Hands-On Guide walks you through the lab exercises used in the GitLab with Git Fundamentals course."

---

## GitLab with Git Fundamentals Lab Guides

| Lab Name |  Lab Link |

|-----------|------------|

| Create a project and an issue | [Lab Link](/handbook/customer-success/professional-services-engineering/education-services/gitbasicshandsonlab1/) |

| Work With Git Locally |  [Lab Link](/handbook/customer-success/professional-services-engineering/education-services/gitbasicshandsonlab2/) |

| Use GitLab To Merge Code | [Lab Link](/handbook/customer-success/professional-services-engineering/education-services/gitbasicshandsonlab3/) |

| Build a `.gitlab-ci.yml` File | [Lab Link](/handbook/customer-success/professional-services-engineering/education-services/gitbasicshandsonlab4/) |

| Auto DevOps With a Predefined Project Template | [Lab Link](/handbook/customer-success/professional-services-engineering/education-services/gitbasicshandsonlab5/) |

| Static Application Security Testing (SAST) | [Lab Link](/handbook/customer-success/professional-services-engineering/education-services/gitbasicshandsonlab6/) |

---

title: "GitLab with Git Fundamentals - Hands-On Lab: Create a project and issue"

description: "This Hands-On Guide walks you through creating projects, issues, labels, as well as using quick actions."

---

> Estimated time to complete: 30 minutes

## Objectives

A GitLab Project is a repository where you can store your code, as well as supplemental files such as configuration files. You can also use projects to track issues, plan work, collaborate on code, and continuously build, test, and use built-in CI/CD to deploy your app. You can find out more information about GitLab projects in the [documentation](https://docs.gitlab.com/ee/user/project/organize_work_with_projects.html)

GitLab provides various tools for tracking and managing projects. In this lab, you will learn how to create a project, create an issue, create labels at a project level, and apply quick actions to an issue.

## Task A. Access your Training Group

1. Navigate to [**https://gitlabdemo.com/invite**](https://gitlabdemo.com/invite) in a web browser.

1. In the **Invitation Code** field, enter the invitation code provided by your instructor or in the LevelUp LMS.

1. Select **Provision Training Environment**.

1. You will need your **GitLab.com** username. To find your username, navigate to [Gitlab](https://gitlab.com).

1. In the left sidebar, select your profile image.

1. In the resulting dropdown, you will see a value starting with `@`. This is your GitLab username.

1. After inputting your invitation code, the portal prompts you for your **GitLab.com** username. Enter your GitLab.com user (excluding the leading `@` sign) in the field provided.

1. Select **Provision Training Environment**.

1. Select **My Group** at the bottom of the page.

1. Sign in with your GitLab.com credentials.

1. You will be redirected to a **My Test Group** group that provides a sandbox for you to perform training lab steps in.

   > This group has a GitLab Ultimate license to see all of the features while your personal username namespace requires a paid subscription or a free trial to access all of the features.

   >

   > If you receive a 404 error when accessing your group, it is likely due to the username input during the lab provisioning. Double check your GitLab username to make sure it is entered correctly.

1. From your **My Test Group** training subgroup, click the **New project** button.

## Task B. Create a project

1. Select the **Create blank project** tile.

1. In the **Project name** field, enter `Top Level Project`.

   > The project slug will automatically populate. You can change this to a shorter string if desired for your own project. Leave it at the default for this lab.

1. In the **Project URL** field, click the dropdown for the second half of the URL to make sure it's pointing to a **group name** and not a **username**. You should create this project inside a group, not directly in your user's namespace.

1. Under **Visibility Level**, ensure **Private** is selected.

   > Since the parent group above your group is private, all child groups and projects below will be private. You can learn more about project visibility levels in the [documentation](https://docs.gitlab.com/ee/user/public_access.html).

1. Check **Initialize repository with a README**.

1. Select **Create project**.

## Task C. Create an issue

> Issues are a core building block in GitLab that enable collaboration, discussions, planning and tracking of work. Issues belong to **Project** and **not** a Group. When viewing issues at the group-level, you can see all of the issues that have been created across all of the projects in that group. You can read more about them [here](https://docs.gitlab.com/ee/user/project/issues/).

1. In the left-hand navigation pane, navigate to **Plan > Issues**.

1. Click the **New issue** button.

1. In the **Title** field, type in `My first issue`

1. In the **Type** dropdown, make sure that `Issue` is selected.

1. The description is an optional section, but feel free to type in your own description for this issue.

   > In the description section, there is a dropdown to select a template. It is possible to create templates to help standardize issue descriptions. To learn more about issue templates, click [here](https://docs.gitlab.com/ee/user/project/description_templates.html).

1. Using the **Assignees** dropdown, assign the issue to yourself by clicking on the dropdown, and then clicking on your username.

   > Alternatively, you can also click **Assign to me** directly beside the Assignees dropdown to assign an issue to yourself.

1. While we will leave the options as they are for now, it is important to understand what they do:

   - **[Epic](https://docs.gitlab.com/ee/user/group/epics/):** Associates the issue with an epic. An epic is a parent grouping of one or more child issues. You can think of an epic as a initiative or meta-level topic and an issue as an objective or detailed task for that initiative.

   - **[Milestone](https://docs.gitlab.com/ee/user/project/milestones/):** Milestones in GitLab are a way to track issues and merge requests created to achieve a broader goal in a certain period of time, usually associated with a release and/or version number.

   - **[Labels](https://docs.gitlab.com/ee/user/project/labels.html):** Apply labels to your issue, which are metadata tags that can be used to sort and filter your issues.

   - **[Weight](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html):** Apply a weight value to your issue to measure the time, complexity, or value a given issue has or costs.

   - **[Due date](https://docs.gitlab.com/ee/user/project/issues/due_dates.html):** Use in issues to keep track of deadlines and make sure features are shipped on time. You will receive an email reminder when an issue due date is approaching if it has not been closed yet.

   - **[Iteration](https://docs.gitlab.com/ee/user/group/iterations/):** Associate the issue with an iteration to track it over a period of time. This allows teams to track velocity and volatility metrics.

1. Click the **Create issue** button.

## Task D. Create custom labels

> Labels allow you to organize and tag your work. Using labels will make it easier for you to track issues you are interested in using features like dynamic filtering. Some examples of using labels include: categorizing epics, issues, and merge requests using colors and descriptive titles like bug, feature request, or docs. You can read more about labels in the [documentation](https://docs.gitlab.com/ee/user/project/labels.html).

1. In the left-hand navigation pane, navigate to **Manage > Labels**.

1. Click the **New label** button.

1. In the **Title** field, type `Opened`.

1. The **Description** field is an optional field used to describe a label. Feel free to enter anything in this field, or leave it blank.

1. Select any background color.

1. Click the **Create label** button.

   > When you create a label in a project, the label is created at the project level. This means that the label will not be available in any other projects. It is possible to also create a group level label, which is available to all projects in a group.

1. Using the previous three steps, create two additional labels with the titles `Completed` and `Needs documentation`. These labels can have any background colors that you desire.

1. You now have 3 labels that are now available for you to assign to any issue, merge request, or epic in your project.

## Task E. Assign labels to an issue

1. Navigate to **Plan > Issues**.

1. Click on the title of `My first issue` to open the issue.

1. In the right sidebar of **My first issue**, click **Labels > Edit**.

1. Click the **Opened** and **Needs documentation** labels you created earlier.

1. Click away from the **Labels** section. Notice that the issue now has both labels applied.

   > The labels won't apply to the issue until you click away from the labels section to close the multiselect box.

## Task F. Use a quick action

> A **quick action** is a text-based shortcut for common actions that are usually done by selecting buttons or dropdowns in the GitLab user interface. You can enter these commands in the description or comment for issues, epics, merge requests, and commits.

>

> For more information about quick actions and to see a full list of possible quick actions, see the [documentation](https://docs.gitlab.com/ee/user/project/quick_actions.html).

1. In the comment field for the issue from the previous task, type the quick action `/spend 1 hour`

2. Click the **Comment** button.

   > Notice that in the right-hand information pane, **Time tracking** now shows `Spent: 1h`. Instead of leaving a text comment, the quick action has updated the time spent working on the issue.

## Lab Guide Complete

You have completed this lab exercise. You can view the other [lab guides for this course](/handbook/customer-success/professional-services-engineering/education-services/gitbasicshandson).

---

title: "GitLab with Git Fundamentals - Hands-On Lab: Use GitLab To Merge Code"

description: "This Hands-On Guide walks you through creating projects, issues, and merge requests."

---

> Estimated time to complete: 40 minutes

## Objectives

In this lab we will use GitLab to create a project, an issue, and a merge request. We will also use the built-in GitLab Web IDE to edit files, and verify our merge request. GitLab provides a comprehensive UI that allows users to manage their repositories much easier than using Git alone. GitLab also includes a variety of features the Git language itself does not support, such as inline commenting on merge requests. You can learn more on the [GitLab features page](https://about.gitlab.com/features/).

## Task A. Create a new project

1. Navigate to your **My Test Group** by clicking it in the breadcrumb at the top of the page.

1. From your **My Test Group** in GitLab, click the **New project** button.

1. Click the **Create blank project** tile.

1. Name your project `Second Project`

1. Make sure the project visibility is set to **Private**.

1. Check the **Initialize repository with a README** checkbox.

1. Leave **Enable Static Application Security Testing (SAST)** unchecked.

1. Click the **Create project** button and wait for GitLab to redirect you to the new project's main page.

## Task B. Create a new issue

1. In the left-hand navigation pane, click **Plan > Issues**.

1. Click the **New issue** button.

1. In the **Title** field, type `new issue`

1. Next to the **Assignees** dropdown, click **Assign to me**.

1. Click the **Create issue** button.

## Task C. Create a merge request

> Merge requests are a core feature of source control with GitLab since they let you make suggestions to update documents in a repository. You can learn more about merge requests in the [documentation](https://docs.gitlab.com/ee/user/project/merge_requests/).

1. On the issue details page, click the **dropdown arrow** to the right of the **Create merge request** button. This is where you can customize the merge request.

1. Set the **Branch name** to `fix-issue`. Make sure that the **Source** is set to `main`.

   > The **Source** value defines where the changes for the merge request will be applied. In this example, you are making changes that will apply to the `main` branch.

1. Click the **Create merge request** button

1. After clicking **Create merge request**, you will be redirected to the **New merge request** page.

1. Note the merge request title is set to: `Draft: Resolve "new issue"`.

   > By default, the title of the merge request will be in the format `Draft: Resolve "<Issue Name>"`

1. Below the **Title**, there is a checkbox stating **Mark as draft**. Note that this checkbox is currently checked.

   > When a merge request is created, it is marked as a draft by default. The `Draft` keyword in the title of the merge request indicates that the merge is currently a draft. A draft merge cannot be merged until it is marked as ready. This helps to prevent accidental merges.

1. In the merge request description, note the text: **Closes #1**. This description ensures that merging the merge request will also automatically close the issue it is associated with.

   > Your description may show a different number beside the `#` character. This number will match the issue number that the merge request was opened from.

1. Leave all the merge request fields at their default values.

1. While this lab will leave all metadata values as their default value, it is still important to understand what they mean:

    - **Assignees:** Assignees are those that are responsible for creating/maintaining the changes in the merge request.

    - **Reviewers:** Reviewers are those that are responsible for reviewing and approving the changes in the merge request.

    - **Milestone:** Milestones in GitLab are a way to track issues and merge requests created to achieve a broader goal in a certain period of time, usually related to a release and/or version number.

    - **Labels:** Apply labels to your merge requests, which are metadata tags that can be used to sort and filter your requests.

    - **Merge request dependencies:** Ensures merge requests are merged in the right order to prevent commit clashes.

    - **Delete source branch when merge request is accepted:** The branch you are merging from will be deleted if this option is selected, and preserved if this option is not selected.

    - **Squash commits when merge request is accepted:** Only one commit will be seen from this branch if this option is selected that will include all of the changes made in all of the commits; otherwise, all of the commits from this branch will be added to the history.

1. Click the **Create merge request** button at the bottom of the screen.

After creating the merge request, you now have 3 linked items that all relate one piece of work that you need to do: an issue, a branch, and a merge request. An issue describes the work to be done, a branch contains the changes that address the issue, and a merge request proposes how to incorporate the changes into the `main` code branch.

## Task D. Edit files on a branch using GitLab's Web IDE

> To address the changes required in the issue, you can edit files in your code branch. There are many ways to edit files in a branch. In the last lab, you learned how to edit a file locally. In this lab, you will edit a file online through the Web IDE. The Web IDE is an advanced editor with commit staging. You can use the Web IDE to make changes to multiple files directly from the GitLab UI. You can find out more information in the [documentation](https://docs.gitlab.com/ee/user/project/web_ide/).

1. In the top right of the merge request page, click on the arrow to the right of **Code** and click **Open in Web IDE**.

1. In the left-hand file explorer, click on `README.md`.

1. On line 3 of the file, type `Edit my README.md file`

1. In the left pane of the IDE, click on the **Source control** button (it looks like a mini Git branching graph).

1. For **Commit Message**, type `Updated the README.md file`.

1. Click the **Commit** button.

1. You should see notification box that says `Success! Your changes have been committed` in the bottom right corner of the screen. Click the **Go to project** option from the notification box in the bottom right corner.

   > If this dialog box disappears, you can get back to the project by clicking the GitLab icon on the bottom left of the screen. When you click this button a dialog will appear in the middle of the screen with various options. Click `Go to Second Project project on GitLab`.

1. From the project landing page, click **Code > Merge requests**. Click the name of your merge request.

## Task E. Verify changes in a merge request

1. On the merge request page, locate the **Assignee** section in the upper right-hand corner (you might have to click the double arrow at the top right of

the screen to expand the pane). Ensure the merge request is assigned to yourself. If it is not, click **Assignees > Edit** and click your username from the resulting list. Click away from the list to apply the change.

1. Click the **Changes** tab directly below the merge request title.

1. Hover over line 3 of the left side of the table (which contains the changes in your commit) and click the **comment icon**.

1. In the comment field, type `This is a comment` and click **Start a review**.

   > When you start a review, your comments will only be visible to you until you submit the review.

1. You'd normally add more comments to your review before submitting them all at once, but for this lab just click the **Finish review** button.

1. In the resulting dialog, you will see a **Summary comment** textbox. This is an optional field that allows you to add a summary to your review. For this review, add the comment **Added comment to README.md**

1. Below the **Summary comment**, there are three radio buttons. Since your review only contains general feedback, click **Comment**.

   - **Comment:** Indicates that the review contains some general feedback. This option will not approve the merge request.

   - **Approve:** Many projects will require a reviewer to approve a merge request before it is merged. This option will submit your feedback, and approve the merge request.

   - **Request changes:** Indicates that the review contains feedback that should be addressed before merging the request.

1. Click the **Submit review** button.

1. Pretend that someone has seen your comment and added another commit to address it. Click the **Resolve thread** button to show that the comment has been dealt with.

## Task F. Merge the branch and close the merge request

1. Click the **Overview** tab under the MR title.

1. To mark the merge request as ready to merge, click **Mark as ready**. This removes `Draft:` from your MR's title.

   > For this lab, you haven't specified any approvers for this project. If you had, an **Approve** button would appear in the **View eligible approvers** section.

1. Ensure the **Delete source branch** checkbox is enabled, and click the **Merge** button.

1. Navigate back to your project's repository by clicking **Code > Repository** in the left-hand navigation pane.

1. Check what branch you're on by looking at the dropdown at the top left of the page. Switch to **main** if you're not already on it by clicking on the branch name, and clicking the `main` branch.

1. Since the default view of the repository displays the contents of the `README.md` file, it's easy to verify that the merge added `Edit my README.md file` to the contents of `README.md`.

## Lab Guide Complete

You have completed this lab exercise. You can view the other [lab guides for this course](/handbook/customer-success/professional-services-engineering/education-services/gitbasicshandson).