Explore Git and GitLab through practical exercises. Java 8, Jenkins, Docker, and Container Registry are client-environment context only.
Scenario: update the approved Stacks customer-search policy document, commit locally, push to GitLab, and open a Merge Request. The simulator uses README as a simple visual example; the live exercise uses docs/CUSTOMER_SEARCH_POLICY.md.
Step 1: Update develop before branching.
GitLab lets developers review changes before they reach shared branches. In this session you practise the Merge Request lifecycle and understand branch governance.
Developer pushes work
Source: feature/*
Target: develop
Comments, changes, approval
After required checks
develop as target.develop, staging, and main.Two contributors independently change the same line of the README. Git needs you to choose the intended result. Resolve it based on the business requirement, not whose edit arrived first.
Architecture context only: GitLab and Jenkins are hosted in Docker containers. The client application uses Java 8; Jenkins may build/test it. GitLab Container Registry may optionally store built images. You do not need to operate any of these technologies in this workshop.
Commit and push changes
Git repository, MRs, approvals
Optional external build/test status
Optional container-image storage
The registry is for images, not Git commits. This diagram is a conceptual workflow, not a validated deployment or mandatory build sequence.
Select a situation to show its safer response. Discuss the scenario with participants before revealing the answer.
Reference answers for the participant knowledge check. No quiz submissions or scores are required in the trainer view.
git status, review changes before staging, use meaningful commits, create Merge Requests, respect protected branches, and never commit secrets. Keep 10 minutes for Q&A.Recommended: use GitLab.com or an existing GitLab service for the workshop. A self-managed GitLab instance may be resource-heavy for your 4-core/8-thread, 16 GB RAM Proxmox host, especially alongside Jenkins. Start with the simulator first.
jdk8, Maven maven3 and agent label maven-linux. Verify that a real Jenkins branch build runs.Run these steps in your terminal. Replace the repository URL and YOURNAME before running.
git clone <training-repo-url>
cd stacks-gitlab-training
git switch develop
git pull --ff-only origin develop
git switch -c feature/YOURNAME-normalize-id
# In CustomerService.java: uppercase trimmed IDs
# In CustomerServiceTest.java: expect Customer: C001
mvn -B test
git diff
git add src/main/java/com/stacks/training/CustomerService.java src/test/java/com/stacks/training/CustomerServiceTest.java
git commit -m "STACKS-101 Normalize customer IDs"
git push -u origin feature/YOURNAME-normalize-idLines beginning with # are instructions, not commands. Review each command before execution.
In GitLab: Code → Merge requests → New merge request; source = feature branch, target = develop. Assign reviewer, inspect changes, merge after approval/checks.
App.java title line on separate branches from the same baseline. Merge the first MR, then demonstrate resolving the second MR's conflict. Use throwaway training data only.The first simulator exercise uses README.md only as a conceptual example. The real Java 8 lab uses the project Java source and JUnit tests. Jenkins DEV/STAGING/PRODUCTION stages are echo simulations; merge blocking needs separate GitLab/Jenkins status integration.
GitLab: create Merge Requests · Protected branches · Self-managed Docker install