Gitlab - 3.2 GitLab branch setup part 2

This second part continues the GitLab branch setup. We will add a small Python file, commit it on the dev1 branch, push that branch to the server, and merge it into main through a merge request.

Adding a file and committing on dev1

From the terminal, enter the project directory and open it in Visual Studio Code with code .. If VS Code is not installed, you can install it via sudo snap install code --classic (or your preferred method). Inside the project, create a simple file hello.py with a single line:

print("hello")

Save it. Back in the terminal, git status shows hello.py as untracked. Stage it and commit:

git add hello.py
git commit -m "add hello.py"

If Git refuses with a missing identity error, configure your user globally:

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Then retry the commit. Tracking a new file does not affect the repository in a major way; it just keeps it for reference. The change is not persisted until you commit.

Pushing the dev1 branch with -u upstream

On the GitLab server we still only see main — our local dev1 branch is unknown. A bare git push fails for that reason. We push with the upstream flag so the branch is created on the server and tracked:

git push -u origin dev1

Authenticate with username and password and the push succeeds. Back in the GitLab UI, refresh: there are now two branches. The main branch has only the README, while dev1 also has hello.py.

Opening the merge request

After the push, GitLab shows a "Create merge request" button. Click it, choose dev1 as source and main as target, then "Compare branches and continue". Keep the title and description, uncheck "Delete source branch on merge" if you want to keep dev1 alive after merging, and submit. Logged in as a project Maintainer, you can click Merge to integrate the change. Refresh the project: hello.py now appears on main. That is the first CI/CD principle in action — a single shared repository where modifications are integrated regularly. See you in the next video.

Summary

This lesson demonstrates the complete GitLab branch workflow, from creating code changes to integrating them into the main branch. Students learn the essential Git commands (`git add`, `git commit`, `git push`) needed to stage changes, record them with meaningful messages, and upload branches to the remote repository. The lesson then shows how to create and merge pull requests directly through the GitLab interface, illustrating best practices for collaborative development and CI/CD-enabled code integration.

Key points

  • Use `git add <filename>` to stage changes and prepare them for commit before uploading to GitLab
  • Execute `git commit -m "message"` to save staged changes locally; configure Git user email and name globally if this is your first commit
  • Push local branches to the remote GitLab repository with `git push -u origin <branch-name>` to establish upstream tracking
  • Create merge requests through the GitLab web interface to propose code integration and enable code review before merging
  • Merge feature branches into main only after review to maintain code quality and enable CI/CD pipeline validation
  • GitLab automatically suggests creating a merge request immediately after detecting a new pushed branch

FAQ

What should I configure before making my first Git commit on a new system?

Configure your global Git identity by running `git config --global user.email "your-email@example.com"` and `git config --global user.name "Your Name"` so your commits are properly attributed to you in the repository history.

Why did my initial `git push` fail when pushing to a new GitLab branch?

The push failed because Git could not find a corresponding remote-tracking branch. Use `git push -u origin <branch-name>` with the `-u` flag to establish the upstream connection between your local branch and its remote counterpart on GitLab.

Is it safe to merge code directly without creating a merge request?

No. Creating a merge request through the GitLab interface enables code review, automated testing in your CI/CD pipeline, and collaborative feedback before integration into main. This prevents bugs and ensures code quality standards are maintained.