GIT + GITLAB FOR BEGINNERS

Why should a Manual Tester learn Git?
What is the difference between Git and GitLab?
Four places a change passes through
Prepare before working
The daily workflow
Commits and writing commit messages
Branch: work without affecting main
Syncing with GitLab
Merge Requests and review
Merge and rebase basics
Conflicts and how to handle them
Fixing common Git mistakes
Team working rules
Cheatsheet and exercises

What is it? This is a practical Git/GitLab handbook for people without a deep technical background. Why? Learning too many of Git's internal concepts at the start is easy to get tangled in, and does not help you finish everyday work. What is it for? By the end, you can join a project, manage changes and collaborate with your team safely.

The most important rule: if you do not understand what a command will delete or change, do not run it. Use git status, capture the error message and ask someone experienced. Do not run git reset --hard, git clean -fd or git push --force to try your luck.

1. Why should a Manual Tester learn Git?

What is it? Git is a tool that records a project's file-change history. Why? Test cases, checklists, documentation, configuration and automation scripts all change over time. What is it for? Knowing who changed what, comparing versions and working together without overwriting one another's files.

1.1 How does Git help QA work?

What is it? Git creates an auditable history for project files. Why? Sending files in chat or naming them test-case-final-v3 makes it very hard to know which one is actually newest. What is it for? Keeping one official source and tracing every change.

Examples of QA assets you can manage with Git:

automation tests;
test data without sensitive information;
regression checklists;
setup guides;
API collections or configuration;
Markdown test-case descriptions;
scripts that help create test data.

1.2 Git is not only for developers

What is it? Git manages files; it does not require those files to be source code. Why? QA also creates and maintains project assets. What is it for? Letting QA use the same review, history and release workflow as the development team.

You do not need to understand Git's algorithms to begin. You only need to know:

which branch you are on;
which files have changed;
which files will go into the commit;
which commits have not been sent to GitLab;
which Merge Request will review the change.

1.3 Git does not replace backups and tickets

What is it? Git stores file versions; a ticket stores the requirement and context; a backup protects the system when something goes wrong. Why? A commit does not fully explain the acceptance criteria, and an uncommitted file can still be lost. What is it for? Using the right tool for the right job and linking them together.

2. What is the difference between Git and GitLab?

What is it? Git is a version-control tool; GitLab is a website/server for storing repositories and collaborating. Why? Many people confuse “committed” with “already on GitLab”. What is it for? Knowing whether a change is only on your own machine or has been shared with the team.

2.1 What is Git?

What is it? Git runs on your machine and manages a project's history. Why? You can create branches, view changes and commit even without a GitLab connection. What is it for? Saving meaningful change points before sharing them.

These commands mainly work on your local machine:

git status
git diff
git add
git commit
git branch

2.2 What is GitLab?

What is it? GitLab is where the team keeps the shared repository and performs reviews. Why? A local repository on your machine cannot collaborate with the whole team by itself. What is it for? Pushing branches, opening Merge Requests, discussing, running pipelines and merging changes.

GitLab commonly provides:

a shared repository;
member and permission management;
Merge Requests;
issues/tickets;
reviews and approvals;
automated pipelines;
reports and artefacts.

2.3 An easy example to remember

What is it? Think of Git as the history notebook on your machine, and GitLab as the team's shared library. Why? The comparison helps separate local from remote. What is it for? Remembering that committing to “your notebook” does not mean you have handed it in to “the library”.

git commit = save a point on your local machine
git push   = send those points to GitLab

3. Four places a change passes through

What is it? A change usually passes through Working folder → Staging → Local repository → GitLab. Why? Each Git command affects one or more places in this chain. What is it for? Understanding where the data is now and what the next step is.

// Four places a change passes through

3.1 Working folder

What is it? This is the project folder you have open in VS Code. Why? Every file you edit first changes only here. What is it for? Writing test cases, fixing scripts or updating documentation.

Saving a file with Ctrl+S has not created a commit and has not sent the file to GitLab.

3.2 Staging

What is it? Staging is the list of changes you have selected for the next commit. Why? You can edit several files but commit only part of them. What is it for? Controlling the exact contents of the commit.

git add path/to/file
git diff --staged

3.3 Local commit

What is it? A commit is a saved point in the history of the repository on your machine. Why? It tells the team what a complete change contains and why. What is it for? Reviewing, comparing, undoing or finding the source of a problem.

3.4 GitLab remote

What is it? The remote is the shared repository on GitLab. Why? The team cannot see a local commit. What is it for? Pushing a branch to GitLab for the organisation's system-level backup, running pipelines and opening a Merge Request.

3.5 `git status` is the command you should run most

What is it? git status describes the current branch and file state. Why? It helps you avoid committing the wrong file or working on the wrong branch. What is it for? Checking before and after every important step.

git status

4. Prepare before working

What is it? Setup means Git is installed, your identity is correct and you have GitLab access. Why? Bad setup can put the wrong name on commits or prevent the machine from cloning/pushing. What is it for? Creating a ready environment before editing the project.

4.1 Check Git

What is it? The version command confirms that the machine recognises Git. Why? VS Code needs the Git executable for Source Control. What is it for? Telling an installation problem from a repository problem.

git --version

In a company environment, install Git only from an IT-approved source. Do not download an installer at random or turn off antivirus to install it.

4.2 Configure your name and email

What is it? Your name/email is recorded in every commit. Why? The team needs to know who made a change, and GitLab needs to associate the commit with an account. What is it for? Creating an accurately attributed history.

git config --global user.name "Nguyen Van A"
git config --global user.email "nguyen.van.a@example.internal"

git config --global --get user.name
git config --global --get user.email

Use the email required by your company. Do not use someone else's email or account.

4.3 Clone the project

What is it? Clone creates a project copy with its Git history on your machine. Why? A ZIP download gives you current files but not the full branch/remote history. What is it for? Joining the repository the team is actually using.

git clone <repository-url>
Set-Location <repository-folder>
git status

Get the URL from the correct GitLab project. Do not clone a repository from an unclear source and then run scripts inside it.

4.4 Open the project in VS Code

What is it? VS Code displays the files and Source Control for the repository you opened. Why? Opening the wrong parent or child folder can stop VS Code recognising the right repository. What is it for? Viewing changes and handling staging, commits and conflicts through the interface.

code .

In VS Code:

Explorer: view files;
Source Control: view changed files;
Terminal: run Git commands;
the status bar at the bottom: view the current branch.

4.5 Check before editing a file

What is it? This confirms the repository, branch and starting state. Why? Editing while on main, or with old changes still around, easily creates confusion. What is it for? A clean, clear starting point.

git status
git branch --show-current
git remote -v

5. The daily workflow

What is it? The daily workflow is a sequence repeated whenever you handle a ticket. Why? A stable order reduces mistakes and makes it easier to ask for help. What is it for? Taking a change from your machine to a Merge Request.

// A simple workflow for one ticket

5.1 Step 1 — update `main`

What is it? main is usually the main branch containing the version accepted by the team. Why? Creating a branch from an old main increases the chance of conflicts. What is it for? Starting work from the latest version.

git switch main
git pull --ff-only

If the command reports an error, do not add --force. Run git status and ask for help if you do not understand the message.

5.2 Step 2 — create a branch for the ticket

What is it? A branch is a separate workspace for a change. Why? You should not edit main directly. What is it for? Keeping the ticket's changes separate until review.

git switch -c test/PROJ-123-update-regression-checklist

5.3 Step 3 — edit files and check the diff

What is it? A diff is the content that differs between the current file and the version stored by Git. Why? A formatter or a mistaken operation may change more than you expected. What is it for? Reviewing your own work before committing.

git status
git diff

In VS Code, select each file in Source Control to see the changed green and red sections.

5.4 Step 4 — choose files for the commit

What is it? Staging means selecting the changes that will go into the commit. Why? Not every modified file belongs to the ticket. What is it for? Avoiding logs, temporary files and unrelated changes in the commit.

git add path/to/file
git diff --staged

As a beginner, stage files one at a time instead of always using git add ..

5.5 Step 5 — commit

What is it? Commit saves the staged part as a local point. Why? The message tells the team what the change is for. What is it for? Preparing a clear history before pushing.

git commit -m "test(login): update invalid password scenarios"
git status

5.6 Step 6 — push

What is it? Push sends local commits on your branch to GitLab. Why? The team cannot review a branch that exists only on your machine. What is it for? Creating the remote branch and opening a Merge Request.

git push -u origin test/PROJ-123-update-regression-checklist

Later, on the same branch, you usually only need:

git push

5.7 Step 7 — open a Merge Request

What is it? A Merge Request proposes bringing your branch into main. Why? The team needs review and a pipeline before merging. What is it for? Receiving feedback and integrating the change under control.

6. Commits and writing commit messages

What is it? A commit is a historical point with content, an author, a time and a message. Why? A good commit helps others understand and undo a change. What is it for? Splitting work into small, complete and reviewable parts.

6.1 What should one commit contain?

What is it? One commit should serve one clear goal. Why? Mixing goals makes review and undoing harder. What is it for? Keeping the history simple.

Good examples:

update invalid-password login test cases;
fix a broken locator;
add setup instructions;
add test data for one specific rule.

Examples to split apart:

fix the login test and format 30 other files at the same time;
update documentation and upgrade an unrelated dependency;
fix bug A and add feature B at the same time.

6.2 A commit is a “meaningful point”, not every press of Save

What is it? Save only saves a file; commit records a state that people can understand and review. Why? Commits named save, wip or try again do not help the history. What is it for? Commit only when one piece of work has a clear meaning.

6.3 A simple convention

What is it? A convention is a shared pattern for commit messages. Why? If everyone writes differently, the log is hard to read. What is it for? Telling the type and scope of a change at a glance.

<type>(<scope>): <short description>

Examples:

test(login): add locked account scenarios
fix(checkout): update submit button locator
docs(setup): clarify GitLab access steps
chore(data): remove obsolete test account

This convention is based on Conventional Commits but shortened for beginners.

6.4 The `type` values to remember

What is it? type says which group the change belongs to. Why? Beginners do not need to memorise a huge list of types. What is it for? Classifying changes QA sees often.

Type	When to use it	Example
`test`	Add or change a test	`test(order): cover cancellation rule`
`fix`	Fix a code/test problem	`fix(login): use stable locator`
`docs`	Change documentation	`docs(git): add conflict guide`
`feat`	Add a new capability	`feat(report): add CSV export`
`chore`	Small cleanup/maintenance	`chore(data): remove old fixture`

6.5 What is `scope`?

What is it? Scope is the area changed, such as login, order or setup. Why? It tells readers which part of the project a commit concerns. What is it for? Making the message more specific.

If the team already has a scope list, use it. If not, choose a short, understandable name.

6.6 Good and not-so-good descriptions

What is it? The description summarises the commit's result. Why? Phrases such as update file or fix issue do not say what actually changed. What is it for? Making the log understandable without opening every diff.

Not so good	Better
`update test`	`test(login): add expired password scenario`
`fix bug`	`fix(order): correct total amount assertion`
`PROJ-123`	`docs(regression): update PROJ-123 checklist`
`changes`	`chore(data): remove inactive test users`

7. Branch: work without affecting `main`

What is it? A branch is a separate working line started from one version of the project. Why? If everyone edits main directly, unreviewed changes can affect the whole team. What is it for? Giving every ticket its own space before merging.

// A feature branch leaves main and returns through a Merge Request

7.1 Check the current branch

What is it? The current branch is where the next commit will be created. Why? Committing to main by mistake is a common beginner error. What is it for? Confirming before editing or committing.

git branch --show-current
git status

7.2 Create a branch

What is it? git switch -c creates a new branch and switches to it. Why? Each ticket should be separate from other work. What is it for? Keeping the Merge Request small and clear.

git switch -c test/PROJ-123-login-regression

7.3 How to name a branch

What is it? A branch name should show the work type, ticket and short description. Why? Names such as test1 or my-branch have no context. What is it for? Finding and linking a branch to its ticket easily.

test/PROJ-123-login-regression
fix/PROJ-456-broken-locator
docs/PROJ-789-update-handbook
feature/PROJ-321-export-report

7.4 Switch branches

What is it? git switch changes the working folder to match the selected branch. Why? Git may refuse if a file with local changes would be overwritten. What is it for? Moving between tasks in a controlled way.

git status
git switch main

If Git says local changes would be overwritten, stop. Commit, stash or ask your guide; do not delete changes just to switch branches.

7.5 Delete a branch after merging

What is it? A ticket branch often does not need to remain after its change is merged. Why? Too many old branches make the list difficult to read. What is it for? Keeping the repository tidy.

GitLab often offers Delete source branch when merging. For a local branch:

git switch main
git branch -d test/PROJ-123-login-regression

Do not use -D until you have confirmed the branch was merged or contains no data you still need.

8. Syncing with GitLab

What is it? Syncing means bringing the team's changes to your machine and sending your commits to GitLab. Why? Local and GitLab do not update each other automatically. What is it for? Working on the current version and sharing your branch.

8.1 What is `origin`?

What is it? origin is usually the name Git gives the GitLab repository when you clone it. Why? Push/fetch commands need to know which server is being used. What is it for? Calling the remote by a short name.

git remote -v

8.2 `git pull`

What is it? Pull gets new changes from GitLab and updates the current branch. Why? The team may have merged new changes. What is it for? Keeping local main close to main on GitLab.

git switch main
git pull --ff-only

As a beginner, pull only after checking the right branch and confirming the working folder has no unresolved changes.

8.3 `git push`

What is it? Push sends local commits to the corresponding branch on GitLab. Why? The team cannot see or review a local commit. What is it for? Updating the Merge Request.

git push

8.4 Push is rejected

What is it? GitLab may reject a push because the remote changed, the branch is protected or you do not have permission. Why? This is a guardrail, not a reason to force. What is it for? Reading the error and choosing the correct response.

When this happens:

git status
git branch --show-current
git remote -v

Capture the complete message and ask the team if you do not understand it. Do not use git push --force.

9. Merge Requests and review

What is it? A Merge Request (MR) asks to bring changes from your branch into the main branch. Why? The team needs to inspect, discuss and check them before merging. What is it for? Making sure the change meets the requirement without breaking the project.

9.1 What should an MR contain?

What is it? An MR includes a title, description, source branch, target branch, reviewer, diff and pipeline. Why? A branch link alone gives the reviewer too little context. What is it for? Helping the reviewer understand the change quickly and check the right things.

A simple template:

## Goal
Update the regression checklist for the login flow.

## Changes
- Add a locked-account case.
- Update the expected result for an expired password.

## Checked
- Reviewed the diff.
- Ran the login smoke test.

## Ticket
PROJ-123

9.2 Source and target branches

What is it? Source is the branch with the change; target is the branch that will receive it. Why? Choosing the wrong target can send code into the wrong version. What is it for? Confirming the merge direction before creating an MR.

Usually:

source: test/PROJ-123-login-regression
target: main

If the project uses another target, follow the team's rule.

9.3 What does a review check?

What is it? Review means reading the change and confirming that it is correct, complete, safe and maintainable. Why? A pipeline does not understand the whole business context. What is it for? Finding scope problems, missing tests or sensitive data before merging.

Reviewers should check:

does the change match the ticket?
are there unfamiliar files or secrets?
does the test case have a clear expected result?
does the automation contain a real assertion?
did the change remove an existing case?
are file and commit names understandable?
did the pipeline pass?

9.4 Replying to review comments

What is it? A discussion records a question or requested change on the MR. Why? Important decisions need to stay with the change. What is it for? Helping the author and reviewer agree before merging.

The process:

read the comment carefully;
ask if you do not understand it;
edit the file on the same branch;
commit and push;
reply with what you changed;
let the reviewer confirm before resolving if the team requires it.

9.5 When is an MR ready to merge?

What is it? An MR is ready when its content, review and automated checks meet the rules. Why? Seeing a Merge button does not mean every risk has been handled. What is it for? Putting only confirmed changes into the main branch.

source/target are correct;
there are no remaining conflicts;
required pipeline passes;
a reviewer has approved;
important comments have been handled;
there are no secrets or temporary files;
the MR description reflects the final change.

Official documentation: GitLab Merge Requests.

10. Merge and rebase basics

What is it? Merge and rebase are two ways to bring branch histories onto a common base. Why? A project may require a branch to be updated with main before merging. What is it for? Reducing conflicts and helping GitLab combine the changes.

10.1 What is merge?

What is it? Merge combines changes from two branches. Why? Two branches can develop in parallel. What is it for? Bringing a feature branch into main, or updating a branch according to policy.

For beginners, merge into main through GitLab's Merge button after review; do not push directly to main.

10.2 What is rebase?

What is it? Rebase places your branch's commits on top of a newer version of main. Picture Git lifting your changes up and setting them down after the team's new changes. Why? A branch created from an old main may no longer be current. What is it for? Preparing a branch before merge when the project requires it.

// Rebase places your changes on the latest main

10.3 When does a beginner need rebase?

What is it? Rebase is often needed when GitLab says the branch is behind the target or the project uses a linear history. Why? Rebase changes commit IDs and can create conflicts. What is it for? Only doing it when the team workflow or a guide requires it.

The basic process on your own branch:

git status
git branch --show-current
git fetch origin
git rebase origin/main

Conditions:

do not be on main;
the working folder is clean;
you are the only person using the branch;
you understand how to abort if something goes wrong.

10.4 Rebase stops because of a conflict

What is it? Git does not know how to replay a commit when main changed the same area. Why? Rebase needs a human decision. What is it for? Resolving and continuing, or returning to the state before the rebase.

# After you have fixed and staged all conflicts
git rebase --continue

# Cancel the entire rebase and return to before it began
git rebase --abort

Do not use git rebase --skip just to get past an error; it can also discard a needed change.

10.5 Push after rebase

What is it? Because rebase changes branch history, Git may reject an ordinary push. Why? An incorrect force-push can overwrite someone else's commits. What is it for? This is where a beginner should stop and ask for guidance.

Do not run git push --force on your own. If the team permits --force-with-lease, have a guide confirm the branch and history before you use it for the first time.

More detail: git-rebase.

11. Conflicts and how to handle them

What is it? A conflict occurs when Git cannot combine two changes automatically. Why? Two people may edit the same line, or one may delete a file while the other edits it. What is it for? Asking a person to decide the final content.

11.1 A conflict does not mean somebody is wrong

What is it? A conflict only says that Git needs help. Why? Both changes may be correct when made separately. What is it for? Discussing the business context instead of habitually choosing your own side.

11.2 Conflict markers

What is it? Git inserts three markers to show the two conflicting pieces of content. Why? A file with markers left in it usually cannot run correctly. What is it for? Showing which area needs editing.

<<<<<<< HEAD
Expected: Login succeeds
=======
Expected: User is redirected to dashboard
>>>>>>> test/update-login-case

The final result can choose one side, combine both or write new content. What matters is that it matches the current requirement.

11.3 Resolve with VS Code

What is it? VS Code's Merge Editor displays the conflicting parts and a Result area. Why? The interface is easier to read than raw markers. What is it for? Editing the final result and staging the file.

Steps:

run git status to see the conflict files;
open Source Control in VS Code;
select a file in the Merge Changes group;
read both sides;
edit Result into the correct content;
save the file;
stage the file;
check again and continue the operation.

11.4 Do not click “Accept All” without reading

What is it? Accept Current/Incoming quickly selects one side. Why? One file may need the logic of both sides combined. What is it for? Reminding the resolver that they own the result, not merely the disappearance of the conflict.

If you do not understand the content, ask the authors of both changes. A Manual Tester does not need to decide code logic without context.

11.5 Finish a conflict

What is it? After editing the file, you need to stage it and tell Git to continue the merge/rebase. Why? Saving the file alone does not tell Git that the conflict is handled. What is it for? Completing the operation.

git status
git add path/to/resolved-file

# If you are rebasing
git rebase --continue

Then:

look for leftover markers;
run the related test;
read the diff;
confirm that no necessary content was lost.

11.6 When unsure: abort

What is it? Abort cancels the operation in progress and usually returns to the state before it began. Why? A bad resolution can be more dangerous than pausing. What is it for? Returning to a safe point to ask for help.

git rebase --abort
git merge --abort

Run only the command for the operation reported by git status.

12. Fixing common Git mistakes

What is it? Git has different ways to correct a mistake depending on whether a change is unstaged, staged, committed or pushed. Why? The wrong command can lose files. What is it for? Choosing the safest approach for each situation.

12.1 The wrong file was staged

What is it? A file was selected for the commit but has not been committed. Why? You may have clicked stage all or used git add .. What is it for? Removing the file from staging while keeping its edited content.

git restore --staged path/to/file

12.2 You want to discard uncommitted changes

What is it? git restore <file> returns a tracked file to the content stored by Git. Why? Uncommitted changes may not be recoverable after being overwritten. What is it for? Discarding changes only when you are certain you do not need them.

git diff -- path/to/file

# WARNING: the next command discards uncommitted changes in the file
git restore path/to/file

If you are still unsure, copy the content somewhere safe or ask your guide first.

12.3 A commit is missing a file or has the wrong message

What is it? Amend replaces the latest commit with a new version. Why? It is suitable while the commit is still only on your machine. What is it for? Adding a forgotten file or correcting the message.

git add path/to/missed-file
git commit --amend

Do not amend a pushed commit unless you understand history rewriting and have coordinated with the team.

12.4 You want to undo a commit already on GitLab

What is it? Revert creates a new commit that reverses an old commit's changes. Why? Removing a shared commit can affect other people. What is it for? Undoing a change with a clear history on a shared branch.

git revert <commit-id>

For main or production, follow the team's MR/incident process. Do not revert and push on your own without permission.

12.5 A commit went onto the wrong branch

What is it? The commit is on an unexpected branch. Why? The user forgot to check the branch first. What is it for? Preserving the commit first, then asking an experienced person to move it to the right branch.

First:

git status
git branch --show-current
git log -3 --oneline

Do not reset or delete the branch immediately. Send those three outputs to the person helping you.

12.6 A branch was deleted or a commit was lost

What is it? Git has reflog, which records some recent positions on your machine. Why? A commit may still exist even when its branch pointer was deleted. What is it for? Giving an experienced person clues for recovery.

git reflog

Do not try lots of reset commands after noticing a missing commit. The fewer additional changes, the easier it is to help.

12.7 Commands beginners should not use on their own

What is it? These commands can delete files or rewrite history. Why? Their effects are not always recoverable. What is it for? Recognising the danger zone and stopping to ask first.

git reset --hard
git clean -fd
git push --force
git branch -D
git rebase -i

13. Team working rules

What is it? Team rules agree on branch naming, commits, review and data protection. Why? Git is flexible, so everyone doing things differently creates a history nobody can use comfortably. What is it for? Reducing confusion and telling beginners exactly which rule to follow.

13.1 Do not edit `main` directly

What is it? Every change goes through a branch and Merge Request. Why? main is shared and usually protected. What is it for? Requiring review and a pipeline before merging.

13.2 One branch per ticket

What is it? Each branch handles one goal. Why? Mixing tickets makes a large MR that is difficult to undo. What is it for? Keeping review quick and clear.

13.3 Small but complete commits

What is it? A commit should not be huge, while still containing everything needed for the change. Why? Tiny save commits create noise; huge commits are hard to review. What is it for? Creating a meaningful history.

13.4 Never commit secrets or real data

What is it? Secrets include passwords, tokens, cookies, private keys and credentials. Why? Deleting them in a later commit does not remove them from the old history. What is it for? Protecting systems and user data.

Do not commit:

.env files containing secrets;
passwords or API tokens;
authentication state/cookies;
customer data;
screenshots with sensitive information;
private certificates/keys;
files downloaded from a real environment.

If a secret has been committed, tell the lead/security team immediately so it can be revoked or rotated. Do not merely delete the file and declare it safe.

13.5 `.gitignore`

What is it? .gitignore lists files/directories Git should ignore. Why? Projects generate logs, reports, dependencies and local secrets that should not be committed. What is it for? Keeping the repository clean.

node_modules/
dist/
coverage/
.env
.auth/
*.log
test-results/

.gitignore does not remove a file that was committed earlier.

13.6 Do not resolve a review comment just to make it disappear

What is it? Resolving a discussion means the issue has been handled or agreed. Why? Clicking resolve before fixing it hides a review signal. What is it for? Keeping the MR's status accurate.

13.7 Read the project's `CONTRIBUTING.md` and README

What is it? These are where a project records its own rules. Why? The conventions in this handbook are only general defaults. What is it for? Following the actual project rules for branches, commits, rebases and reviews.

14. Cheatsheet and exercises

What is it? A cheatsheet is for quick reference; a lab is for practising on a safe repository. Why? Looking at commands is not enough to build the reflex. What is it for? Knowing what to do—and knowing when to stop if the state is not what you expected.

14.1 Safe observation commands

git status
git branch --show-current
git diff
git diff --staged
git log -5 --oneline
git remote -v

14.2 Workflow for one ticket

git switch main
git pull --ff-only
git switch -c test/PROJ-123-description

# edit a file
git status
git diff
git add path/to/file
git diff --staged
git commit -m "test(scope): meaningful description"
git push -u origin test/PROJ-123-description

14.3 When there is feedback

# edit a file
git status
git diff
git add path/to/file
git commit -m "fix(scope): address review feedback"
git push

14.4 When a conflict happens during rebase

git status
# edit the file in VS Code
git add path/to/resolved-file
git rebase --continue

# Or cancel the rebase
git rebase --abort

14.5 “What do I want to do?” table

Goal	First command/step
See which files changed	`git status`
See unstaged content	`git diff`
See content about to be committed	`git diff --staged`
Create a branch	`git switch -c <branch>`
Select a file for a commit	`git add <file>`
Create a commit	`git commit -m "..."`
Send a branch to GitLab	`git push -u origin <branch>`
Unstage while keeping the file	`git restore --staged <file>`
Cancel a rebase	`git rebase --abort`
Do not understand the state	`git status`, stop and ask

14.6 Lab 1 — clone and observe

What is it? The first lab only clones and reads the status. Why? Beginners should get used to observing before changing anything. What is it for? Recognising the repository, branch and remote.

Criteria:

clone the correct sandbox project;
open the right folder in VS Code;
identify the current branch;
read the git status output;
confirm that the remote URL contains no credentials.

14.7 Lab 2 — branch, commit and push

What is it? This lab performs a complete workflow with one Markdown file. Why? Text files make diffs easy to view and do not need code to run. What is it for? Creating your first branch and commit safely.

update main;
create a branch for a fake ticket;
edit one piece of documentation;
view the diff;
stage the right file;
write a commit message using the convention;
push the branch;
open a Draft MR.

14.8 Lab 3 — review

What is it? Two learners review each other's MR. Why? A GitLab workflow does not end at push. What is it for? Practising reading diffs and giving clear feedback.

The reviewer must find:

one thing that is correct;
one question about scope;
one check for a secret/unneeded file;
one confirmation of the commit message;
a reasoned approve or request for changes.

14.9 Lab 4 — a guided conflict

What is it? The instructor creates a conflict in a sandbox Markdown file. Why? A first conflict should not happen in a real project. What is it for? Practising reading both sides, editing Result and aborting when needed.

14.10 Completion checklist

14.11 References

The sentence to remember: before committing, look at the diff; before pushing, check the branch; before running a delete or force command, stop and ask.