Master Git Version Control with GitLab

Use the feature branch workflow to build and merge a portfolio page.

Introduction

30 Second Summary

Every developer has accidentally overwritten someone else's work or lost changes they spent hours on. Version control solves this by tracking every change you make and letting multiple people work on the same project without stepping on each other's toes.

In this project, you will build a personal portfolio webpage and track it with Git and GitLab using the professional feature branch workflow that real development teams use every day.

What You'll Build

You will run git log and see a clean commit history with branches, open a merged merge request on GitLab showing line-by-line diffs, and point to a resolved conflict as proof you can handle the trickiest part of team collaboration.

By the end of this project, you'll have:

  • A commit graph on GitLab showing your branching and merging history.
  • A merged merge request where you can see exactly what changed, line by line.
  • A resolved merge conflict in your history as proof you can handle the most common Git challenge developers face.
  • Secret Mission: Lock down your main branch so the only way code gets in is through a reviewed merge request.

Are there any prerequisites?

You need Git installed, IntelliJ IDEA Community Edition for editing files, and a free GitLab.com account. Basic familiarity with creating files and using a terminal is helpful, but no prior Git experience is required.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters to you.

Create Your GitLab Project

Git tracks changes on your local machine, but to collaborate with others and back up your work, you need a remote repository. GitLab hosts your code online and provides tools like merge requests for reviewing changes before they reach your stable branch.

In this step, you will create a private repository on GitLab, clone it to your machine, and configure your Git identity so every commit carries your name.

In this step, get ready to:
  • Create a private repository on GitLab.com.
  • Clone the repository to your local machine.
  • Configure your Git identity for commits.
Create a new blank project on GitLab

A GitLab project is the container that holds your repository, issues, and merge requests. You will create one now and initialize it with a README so there is already something to clone.

  • Open your browser and sign in to gitlab.com.
  • In the upper-right corner, select Create new and then New project/repository.
  • Select Create blank project.
  • In the Project name field, enter my-portfolio.
  • Set the Visibility Level to Private.
  • Check the box labeled Initialize repository with a README.
  • Click Create project.

GitLab redirects you to the project overview page. You should see a README.md file listed in the repository file view.

What did initializing with a README do?

Checking that box told GitLab to create an initial commit containing a README.md file. Without it, the repository would be empty and you could not clone it yet.

Don't see the Create new button?

Make sure you are signed in to GitLab.com. The button appears in the upper-right corner only when you are authenticated.

If you just created your account, refresh the page and look for the Create new icon (a plus sign) in the top navigation bar.

Help me find the Create new button in GitLab

Clone the project to your local machine

Cloning downloads a full copy of the repository to your computer and sets up a connection so you can push changes back to GitLab.

  • On your project's overview page in GitLab, click the Code button in the upper-right corner.
  • Copy the URL shown under Clone with HTTPS.
  • Switch to IntelliJ IDEA and open the built-in terminal by selecting View in the top menu bar, then Tool Windows, then Terminal.

Why the IntelliJ terminal?

IntelliJ IDEA has a built-in terminal so you can run Git commands without leaving your editor. You will use it for every terminal command in this project.

  • Move to your Desktop by running this command:
cd ~/Desktop
  • Clone the repository by running this command (paste the URL you copied from GitLab):
git clone [[GITLAB_CLONE_URL="your HTTPS clone URL from GitLab"]]

What happens when you clone?

Git creates a new folder named my-portfolio on your Desktop containing the README.md file and all the Git history from GitLab.

GitLab may prompt you for your username and password during the clone. Enter your GitLab credentials to authenticate.

  • Move into the new project folder by running:
cd my-portfolio
  • Confirm the clone worked by running:
ls

You should see README.md listed in the output.

Getting an authentication error?

If you have two-factor authentication enabled on your GitLab account, you cannot use your regular password for HTTPS cloning. Create a personal access token in GitLab under your user settings with repository read and write permissions, then use that token as your password when prompted.

Help me fix my GitLab authentication error

Configure your Git identity

Every Git commit records who made the change. You need to tell Git your name and email so your commits are properly attributed.

  • Set your name by running this command (replace the placeholder with your actual name):
git config --global user.name "[[GIT_USERNAME="Your Name"]]"
  • Set your email by running this command (replace the placeholder with your actual email):
git config --global user.email "[[GIT_EMAIL="your-email@example.com"]]"
  • Verify your configuration by running:
git config --list

You should see your user.name and user.email values in the output.

What does --global mean?

The --global flag applies the setting to every Git repository on your machine. Without it, the setting would only apply to the current repository.

Before you run the next command, what do you expect to see? Think about how many commits exist in a freshly initialized repository.

  • Check your commit history by running:
git log --oneline

You should see one commit (the initial commit created by GitLab when you initialized with a README). The terminal also confirms you are on the main branch.

Seeing 'fatal: not a git repository'?

Make sure you ran cd my-portfolio after cloning. The git log command only works inside a Git repository folder.

Run pwd to check your current location. The path should end with my-portfolio.

Help me fix the 'not a git repository' error

Your GitLab repository is live and cloned to your machine. Next up, you will make your first commits and push real code to GitLab.

Make Your First Commits on Main

Your repository is cloned and you're on the main branch with one commit. Now it's time to create your portfolio page and push it up to GitLab.

The simplest Git workflow is committing directly to main and pushing. It works for solo projects, but offers no review step and no safety net if something breaks.

In this step, get ready to:
  • Create an index.html file for your portfolio homepage.
  • Stage, commit, and push your changes directly to the main branch.
  • Verify the file appears on your GitLab project page.
Create your portfolio page

Every Git project starts with files to track. You will create a simple HTML page that serves as your portfolio homepage.

  • In IntelliJ's Project tool window (on the left), right-click the my-portfolio folder.
  • Select New, then click File.
  • Type index.html and press Enter.

The file opens in the editor. Paste the following HTML into it:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Portfolio</title>
</head>
<body>
    <h1>My Developer Portfolio</h1>
    <p>A beginner developer exploring version control.</p>
</body>
</html>

What does this code do?

This is a minimal HTML page with a heading and a short paragraph. The <h1> tag creates the main title, and the <p> tag adds a description below it.

The page content itself is intentionally simple. The real focus of this project is the Git workflow behind it, not web development.

  • Save the file with Cmd+S (macOS) or Ctrl+S (Windows).
  • Open the my-portfolio folder in Finder (macOS) or File Explorer (Windows), then double-click index.html to open it in your browser.

You should see a white page with the heading "My Developer Portfolio" and a short paragraph below it.

Don't see the heading in your browser?

  • Make sure you saved index.html before opening it. Unsaved changes won't appear.
  • Check that the file is named exactly index.html (not index.html.txt or index). The extension matters.
  • Confirm the file is inside the my-portfolio folder, not somewhere else on your machine.

Help me troubleshoot why my index.html isn't rendering in the browser.

✔️ Awesome, I've got everything!

Great. Double check you've saved index.html and move on to the next part.

ⓧ I'd like to double check the full code

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Portfolio</title>
</head>
<body>
    <h1>My Developer Portfolio</h1>
    <p>A beginner developer exploring version control.</p>
</body>
</html>
Stage and commit your changes

Git does not automatically track new files. You need to explicitly tell Git which changes to include in a commit. This two-step process is called staging and committing.

  • Stage and commit your new file by running these commands in the IntelliJ terminal:
git add index.html
git commit -m "feat: add portfolio homepage"

What do these commands do?

  • git add index.html stages the file. This tells Git "include this file in my next commit."
  • git commit -m "..." saves a snapshot of all staged changes with a descriptive message. The feat: prefix is a common convention for labelling commits that add new features.
  • Confirm your working tree is clean by running:
git status

You should see a message saying "nothing to commit, working tree clean." This means all your changes are safely saved in a commit.

Seeing "untracked files" or "changes not staged"?

  • If git status still shows index.html as untracked, your git add command may not have run. Re-run git add index.html and check for typos in the filename.
  • If you see "changes not staged for commit," you edited the file after staging but before committing. Run git add index.html again, then git commit -m "feat: add portfolio homepage".

Help me figure out why git status is not showing a clean working tree.

Push to GitLab

Your commit exists only on your machine right now. Pushing sends it to your GitLab repository so it is backed up and visible online.

  • Push your commit to GitLab by running:
git push

Why does this work without extra arguments?

When you cloned the repository, Git automatically set up a connection between your local main branch and the remote main branch on GitLab. That means git push knows exactly where to send your commits without you specifying the destination.

Before you check GitLab, predict what you expect to see in the repository file list. Will it show just the README, or something new?

  • Open your GitLab project in a browser and navigate to the repository file list.

You see index.html alongside the README.md. Click index.html and confirm it shows your HTML content.

Don't see index.html on GitLab?

  • Make sure your git push command completed without errors. If it asked for credentials, enter your GitLab username and a personal access token (not your password).
  • Refresh the GitLab page. Sometimes the browser shows a cached version of the file list.
  • Run git log --oneline locally. You should see two commits. If you only see one, your commit did not go through.

Help me troubleshoot why my pushed file is not showing up on GitLab.

You just pushed code directly to main with no review gate. That worked, but notice how there was nothing stopping you from pushing broken code. Next up, you will learn the feature branch workflow that adds a safety net before changes reach main.

Create a Feature Branch

Your portfolio page is live on GitLab and you can see it in your repository. Now you want to add styling, but here is the problem: if you edit directly on main and introduce a bug, the stable version of your project is immediately broken.

Feature branches solve this. They let you develop new changes in an isolated copy of your code, keeping main stable. In this step, you will create a feature branch, build a stylesheet, and practice making atomic commits.

In this step, get ready to:
  • Create a feature branch and switch to it.
  • Build a CSS stylesheet and update your HTML structure.
  • Commit each file separately as atomic commits.
Create and switch to a new branch

On a real team, main must always stay stable. If someone pushes broken code directly to main, everyone on the team is affected.

  • Create and switch to a new feature branch by running this command in your IntelliJ terminal:
git switch -c feature/add-styling

You should see the message Switched to a new branch 'feature/add-styling'.

  • Verify you are on the new branch by running:
git branch

You should see two branches listed. The asterisk * marks your current branch, which should be feature/add-styling.

What is a feature branch?

A feature branch is a separate line of development that starts from main. You can make as many changes as you want on it without affecting the stable code on main.

When your feature is complete and reviewed, you merge the branch back. This pattern is called the feature branch workflow and it is how professional development teams collaborate safely.

Seeing 'not a git repository'?

Make sure your terminal is inside the my-portfolio folder. Run cd my-portfolio to move into it, then try the command again.

Help me debug this

Build the stylesheet and update your HTML

Your portfolio page currently has no styling. You will create a CSS file for layout and typography, then restructure the HTML to use semantic elements that the CSS can target.

  • In IntelliJ, right-click the my-portfolio folder in the Project panel, select New then File, and name it style.css.
  • Add the reset and base layout styles by pasting this code into style.css:
/* Reset default browser margins and padding */
* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

/* Base page layout and typography */
body {
    font-family: Arial, sans-serif;
    line-height: 1.6;
    max-width: 800px;
    margin: 0 auto;
    padding: 20px;
    background-color: #f4f4f4;
    color: #333;
}

What does this code do?

The * selector removes all default margins and padding from every element so you start from a clean slate.

The body rule sets a readable font, limits the page width to 800px, and centers the content with margin: 0 auto.

  • Confirm style.css appears in your Project panel alongside index.html and README.md.
  • Add the component styles below the body rule in style.css:
/* Dark header banner */
header {
    background-color: #2c3e50;
    color: white;
    padding: 30px;
    border-radius: 8px;
    margin-bottom: 20px;
}

header h1 {
    margin-bottom: 10px;
}

/* White card for content sections */
section {
    background-color: white;
    padding: 20px;
    border-radius: 8px;
    margin-bottom: 20px;
}

/* Centered footer text */
footer {
    text-align: center;
    padding: 20px;
    color: #666;
}

What does this code do?

Each rule targets a semantic HTML element you will add next. The header gets a dark banner look. The section becomes a white card. The footer centers its text.

  • Save style.css with Cmd+S (macOS) or Ctrl+S (Windows).

✔️ Awesome, I've got everything!

Great. Your style.css is complete. Move on to update your HTML.

ⓧ I'd like to double check the full code

Your style.css should contain both chunks you pasted above, in order. Scroll up and confirm you have:

  • The reset (*) and body rules at the top.
  • The header, header h1, section, and footer rules below them.

Now update your HTML to use semantic elements that match the CSS selectors.

  • Open index.html in IntelliJ.
  • Select all the existing content (Cmd+A on macOS or Ctrl+A on Windows) and replace it with the following:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Portfolio</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <header>
        <h1>My Developer Portfolio</h1>
        <p>A beginner developer exploring version control.</p>
    </header>
    <section>
        <h2>About Me</h2>
        <p>I am learning Git and GitLab to collaborate on software projects.</p>
    </section>
    <footer>
        <p>Built while learning Git!</p>
    </footer>
</body>
</html>

What changed in the HTML?

The <link> tag in the <head> connects your stylesheet. The content in <body> is now wrapped in semantic tags: <header>, <section>, and <footer>.

These tags match the CSS selectors you just wrote, so the styles apply automatically.

  • Save index.html.
  • Open index.html in your browser (right-click the file in IntelliJ's Project panel, select Open In then Browser).

You should see a styled page with a dark blue header banner, a white "About Me" card, and centered footer text on a light grey background.

Page looks unstyled?

Make sure style.css is saved in the same folder as index.html. The filename must match the href value in your <link> tag exactly, including lowercase letters.

Help me figure out why my CSS is not loading

✔️ Awesome, I've got everything!

Great. Double check you have saved index.html before moving on.

ⓧ I'd like to double check the full code

Your index.html should look exactly like this:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Portfolio</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <header>
        <h1>My Developer Portfolio</h1>
        <p>A beginner developer exploring version control.</p>
    </header>
    <section>
        <h2>About Me</h2>
        <p>I am learning Git and GitLab to collaborate on software projects.</p>
    </section>
    <footer>
        <p>Built while learning Git!</p>
    </footer>
</body>
</html>
Commit your changes as atomic commits

You have two distinct changes: a brand new stylesheet and an updated HTML file. Committing them separately is called making atomic commits. Each commit captures one logical change, which makes your history easier to read and revert if needed.

  • Stage and commit the CSS file first by running these commands:
git add style.css
git commit -m "feat: add stylesheet with base layout"

Why commit files separately?

Atomic commits make your Git history tell a story. If you ever need to undo the styling without losing the HTML restructuring, you can revert just the CSS commit. Bundling everything into one commit removes that option.

  • Now stage and commit the HTML changes by running:
git add index.html
git commit -m "feat: update HTML structure and link stylesheet"
  • Confirm your working tree is clean by running:
git status

You should see the message nothing to commit, working tree clean.

Seeing 'Changes not staged for commit'?

This means you have unsaved edits or forgot to git add a file before committing. Save both files in IntelliJ, then run git add . followed by git status to check what is left.

Help me understand what went wrong

Before you run the next command, predict: how many commits do you think your feature branch has that main does not?

  • View the commit history across all branches by running:
git log --oneline --all

You should see two new commits on feature/add-styling that do not appear on main. Your feature branch is ahead of main by exactly two commits.

Your feature branch has two clean commits and your working tree is spotless. Next up, you will push this branch to GitLab and open your first merge request so the changes can be reviewed before reaching main.

Push and Create a Merge Request

Your feature branch has two clean commits that transform your portfolio page with structure and styling. Right now, that work lives only on your machine.

To get your changes reviewed and eventually merged into main, you need to push the branch to GitLab and open a merge request. A merge request is how you propose changes for review before they reach the stable branch.

In this step, get ready to:
  • Push your feature branch to GitLab so it exists remotely.
  • Create a merge request proposing your changes to main.
  • Review the line-by-line diff to confirm exactly what changed.
Push the feature branch to GitLab

Your branch currently exists only in your local my-portfolio folder. Pushing uploads it to GitLab so you can create a merge request from it.

  • Push your feature branch and set up tracking by running this command in the IntelliJ terminal:
git push -u origin feature/add-styling

What does this command do?

  • git push uploads your local commits to the remote repository on GitLab.
  • -u origin feature/add-styling sets origin as the upstream remote for this branch. Future pushes from this branch only need git push with no extra arguments.

After the push completes, look at the terminal output. GitLab prints a direct link you can use to create a merge request, starting with remote:.

Seeing an authentication error?

If GitLab asks for a username and password, enter your GitLab username and a personal access token (not your GitLab password). GitLab requires a token for HTTPS Git operations.

You can create a token under your GitLab avatar menu, then Edit profile, then Access Tokens. Give it read_repository and write_repository scopes.

help me fix a GitLab authentication error when pushing

Create the merge request on GitLab

Now that the branch is on GitLab, you can create a merge request to formally propose merging your styling work into main.

  • Open your my-portfolio project page on GitLab in your browser.
  • In the left sidebar, select Code, then Merge requests.
  • In the upper-right corner, click New merge request.
  • Set the source branch dropdown to feature/add-styling.
  • Set the target branch dropdown to main.
  • Click Compare branches and continue.
  • Enter Add styling to portfolio page in the Title field.
  • Click Create merge request.

GitLab opens your new merge request page. You should see the title "Add styling to portfolio page" at the top with an Open status badge.

What is a merge request?

A merge request is a proposal to merge one branch into another. It gives your team a place to review the changes, leave comments on specific lines, and approve the work before it reaches the stable branch.

On GitHub, the equivalent is called a "pull request." The concept is the same.

Don't see your branch in the dropdown?

Make sure your git push -u origin feature/add-styling command completed successfully in the previous substep. The branch must exist on GitLab (not just locally) before it appears in the merge request form.

help me figure out why my branch isn't showing up in GitLab's merge request form

Review the diff on the Changes tab

Before you predict what the diff looks like, think about what files you changed on your feature branch compared to main. What should appear as additions?

  • Below the merge request title, click the Changes tab.

You should see two files in the diff. style.css appears as a brand new file with all lines highlighted in green (additions). index.html shows your modifications: removed lines in red and new lines in green.

What do the colors mean?

Green lines with a + sign are additions. Red lines with a - sign are deletions. This is the standard diff format used across all Git platforms.

You can also leave comments on specific lines by hovering over the line number and clicking the comment icon. This is where code review happens on real teams.

  • Do NOT click Merge yet. You will leave this merge request open for the next step.

You now have an open merge request showing exactly what your feature branch adds to the project. In the next step, you will experience what happens when someone else changes the same file while your merge request is open.

Resolve a Merge Conflict

Your merge request is open on GitLab and ready for review. In a real team, work does not stop while your changes wait to be merged. Other developers keep pushing code to main.

If someone else edits the same lines you changed, Git cannot automatically combine the two versions. This is called a merge conflict. In this step, you will create one on purpose and learn how to resolve it.

In this step, get ready to:
  • Simulate a teammate's conflicting change on main.
  • Resolve the merge conflict locally in your terminal.
  • Push the resolution and merge your merge request.
Simulate a teammate's change on main

To experience a real merge conflict, you need two people editing the same line. You will play both roles: you already changed the <h1> on your feature branch, and now you will change the same line directly on main using GitLab's web editor.

  • In your GitLab project, navigate to the repository file list. Make sure you are viewing the main branch (check the branch dropdown at the top left of the file list).
  • Click index.html to open the file.
  • Click Edit then select Edit single file.
  • Find the <h1> line that currently says My Developer Portfolio.
  • Change the text to My Personal Website.
  • Scroll down to the commit section. Leave the branch set to main.
  • Enter the commit message docs: update page title and click Commit changes.

What did you just do?

You simulated a teammate committing directly to main while your merge request was open. The <h1> on main now says "My Personal Website", but your feature branch still has "My Developer Portfolio".

Git cannot merge both because they change the same line. This is exactly how real merge conflicts happen on teams.

Now go see the damage. Navigate to your open merge request.

  • In the left sidebar, select Code then Merge requests.
  • Click your Add styling to portfolio page merge request.

GitLab now shows a conflict warning on the merge request page. The Merge button is blocked. You cannot merge until the conflict is resolved.

Why does GitLab block the merge?

Both branches changed the same line in index.html. GitLab does not know which version you want to keep. It forces you to decide before allowing the merge.

Resolve the conflict locally

You will pull the latest main into your feature branch. Git will flag the conflicting lines, and you will choose which version to keep.

  • Switch back to your terminal in IntelliJ.
  • Make sure you are on your feature branch by running:
git switch feature/add-styling
  • Pull the latest changes from main into your feature branch by running:
git pull origin main

Git reports a merge conflict in index.html. You will see a message that says automatic merge failed and that you need to fix the conflicts.

  • Open index.html in the IntelliJ editor. Look for the conflict markers that Git inserted:
<<<<<<< HEAD
        <h1>My Developer Portfolio</h1>
=======
        <h1>My Personal Website</h1>
>>>>>>> origin/main

What do the conflict markers mean?

The section between <<<<<<< HEAD and ======= is what your current branch (the feature branch) has. The section between ======= and >>>>>>> is what came from main.

Your job is to pick the version you want, delete everything else (including all the marker lines), and save.

  • Keep your feature branch's heading. Delete the conflict markers and the main version so the line reads:
        <h1>My Developer Portfolio</h1>
  • Make sure no <<<<<<<, =======, or >>>>>>> lines remain anywhere in the file.
  • Save index.html.

Now stage and commit the resolved file.

  • Stage the resolved file by running:
git add index.html
  • Commit the resolution by running:
git commit -m "fix: resolve merge conflict in page title"

Your terminal confirms the merge commit was created. The conflict is resolved locally.

Still seeing conflict markers in the file?

Make sure you deleted all three marker lines (<<<<<<<, =======, and >>>>>>>) and kept only one version of the <h1> line. If git commit complains about unresolved conflicts, reopen the file and search for <<<< to find any remaining markers.

Help me find remaining conflict markers.

Push and merge your merge request

The conflict is resolved on your machine. Now push the resolution to GitLab so the merge request can proceed.

  • Push your resolved branch by running:
git push

Before you refresh the merge request page, think about what you expect to see. Do you think the conflict warning will still be there, or will GitLab now allow the merge?

  • Switch back to your browser and refresh the merge request page.

The conflict warning is gone. The Merge button is now enabled.

  • Click Merge to merge the feature branch into main.
  • Optionally check Delete source branch to clean up the feature branch.

The merge request status changes to Merged. Your feature branch's code is now part of main.

  • In the left sidebar, select Code then Repository graph.

You can see the branch and merge visually. The graph shows your feature branch splitting off from main, running in parallel, and merging back in.

What does the repository graph show?

The graph is a visual timeline of your repository. Each dot is a commit. Lines that split and rejoin represent branches being created and merged.

This is proof that you followed the professional workflow: isolated work on a branch, then merged it back safely.

Merge button still disabled?

If GitLab still shows a conflict after you pushed, your push may not have gone through. Run git status to confirm your working tree is clean. Then run git log --oneline -3 to verify your conflict resolution commit appears. Push again if needed.

Help me troubleshoot my push.

You just resolved your first merge conflict and completed a full merge request cycle. This is the most common challenge developers face with Git, and you handled it. Next up, you will lock down your main branch so that the only way code gets in is through a reviewed merge request.

Secret mission

Protect Your Main Branch

You proved the feature branch workflow works. But nothing actually stops someone from pushing directly to main and skipping the whole process. In this mission, you will lock down your main branch with protection rules so that the only way code gets in is through a reviewed merge request.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on GitLab's Free tier, so there are no ongoing costs. Decide whether to keep your repository as a foundation for future projects or delete it to start fresh.

Resources you used:

  • A private GitLab repository (my-portfolio). Free, no ongoing cost.
  • A local my-portfolio folder on your Desktop containing index.html, style.css, and README.md.

Keep everything running

No action needed. Choose this if you plan to continue building on this repository or use it as the starting point for a CI/CD project.

  • Your GitLab repository stays available at no cost on the Free tier.
  • Your local my-portfolio folder remains on your Desktop ready for future work.
  • Your Git identity configuration (user.name and user.email) remains set globally for future Git projects.

Pause - I'll come back to this later

No running processes to stop. Your repository and local files will be waiting for you whenever you return.

  • Your GitLab repository remains on the Free tier with no charges.
  • Your local files stay on your Desktop. Git has no background processes, so no memory or CPU is consumed.

Delete - I don't want to use this again

Remove all project resources to start completely fresh.

  • Delete the GitLab repository: open your my-portfolio project on GitLab, then in the left sidebar select Settings > General.
  • Expand Advanced.
  • In the Delete project section, select Delete.
  • In the confirmation dialog, enter the project name and select Yes, delete project.
  • Delete your local project folder. On macOS or Linux, run the command below. On Windows, run rmdir /s /q my-portfolio from your Desktop in Command Prompt.
cd ~/Desktop
rm -rf my-portfolio

Your GitLab account is free and useful for future projects. There is no reason to delete it unless you are certain you will never use GitLab again.

Nice Work!

Nice Work!

You just completed a full professional Git workflow using GitLab. You have a real repository with branching history, merged merge requests, and a resolved conflict to prove it.

You've learned how to:

  • Use the feature branch workflow to develop in isolation, push changes, and create a merge request for review before merging into main.
  • Resolve a real merge conflict by identifying conflict markers, choosing the correct version, and completing the merge.
  • Read a commit graph on GitLab showing your branching and merging history across multiple merge requests.
  • Secret Mission: protected your main branch with branch protection rules so the only way code gets in is through a reviewed merge request.

Ready to quiz yourself?