Gitlab - 3.1 GitLab branch setup part 1

Now that we are comfortable with the GitLab UI and we created our first project, we can start using the GitLab CI/CD feature and learn how to write pipelines to tell GitLab what to do. We will mimic a compressed version of how development actually happens on real projects, and how the whole CI/CD pipeline fits in.

Why nobody develops directly on the server

On a real project, developers do not write code directly on the GitLab server. You write your code on your local system, and once a significant amount has been written, you push it from local to the server. Once GitLab notices new commits, the build, test and deploy processes start.

We start by cloning the project locally. From the GitLab project page, we copy the HTTPS clone URL. Back in the terminal, after installing Git and creating a working folder for this course (named gitlab), we clone the project:

git clone <https-url>

GitLab asks for username and password the first time. Cloning a repository copies all files, folders and the full Git history to the local machine. The operating system does not really matter once you are using a cloud environment because it is mostly accessible through the browser, but for this course we need a few local tools — Python, Docker, a GitLab Runner, etc. — to run examples.

Creating a feature branch instead of working on main

Once cloned locally, the project has only one branch — main. Check this with:

git branch

Working directly on main would be disastrous: it is a shared branch, and every other developer in the organization pulls from it. If a bad change lands on main, every subsequent verification done by the team works against broken code. Good practice is to create a new branch from the original code, do your changes there, then merge into main only after testing and approval. In practice, you also need the main branch's owner — usually a senior team member — to approve the merge request.

We create and switch to a new feature branch:

git branch dev1
git checkout dev1

A new git branch confirms dev1 is now the active branch (highlighted in green). An ls shows the project content is exactly the same as on main — we just have a safe playground to make modifications. We will continue building on this branch in the next video.

Summary

This lesson introduces Git and GitLab branching fundamentals for real-world development workflows. You learn how to clone a GitLab project locally via HTTPS, create feature branches, and navigate between branches using Git commands. The core principle is working on isolated branches instead of the main branch to prevent breaking shared code, and understanding that changes require testing and approval before merging back into production.

Key points

  • Git clone HTTPS URL to create a local copy of a GitLab project on your system
  • Always create a feature branch (e.g., dev_1) instead of working directly on the main branch to avoid breaking shared code for other developers
  • Use 'git branch' to list branches and 'git checkout [branch-name]' to switch between branches
  • The main branch is shared by all developers, so faulty code committed there affects the entire team's pipeline (builds, tests, deployments)
  • Feature branches are merged back to main only after testing and receiving approval from a maintainer or branch owner via a merge request
  • Operating system choice is less critical when using cloud-based GitLab since the service is browser-accessible, though local tools like Docker and Python are needed for full development workflows

FAQ

Why should I never work directly on the main branch?

The main branch is shared by all developers. If faulty code is pushed directly, it breaks the entire CI/CD pipeline for the team—builds, tests, and deployments will fail on broken code. Creating a feature branch isolates your changes until they are tested and approved.

What is the process for getting my changes into the main branch?

After creating a feature branch, making changes, and testing locally, you push your branch to GitLab and create a merge request. A maintainer (senior team member) reviews your code, and only after approval will your branch be merged into main.

How do I switch between Git branches locally?

Use 'git branch' to see all branches, then run 'git checkout [branch-name]' to switch to the branch you want to work on. Verify you're on the correct branch by checking the branch indicator in your terminal or running 'git branch' again.