KIRO × GitLab
GitLab Starter Workshop GitLab Starter Workshop

Start with GitLab.
Work like a developer. เริ่มต้น GitLab
แบบที่ Developer ใช้งานจริง

A beginner-friendly hands-on workshop covering the essential GitLab workflow: repository, commit, branch, merge request, and pipeline. เวิร์กชอปสำหรับผู้เริ่มต้น เรียนรู้ workflow สำคัญของ GitLab ตั้งแต่ Repository, Commit, Branch, Merge Request ไปจนถึง Pipeline แบบลงมือทำจริง

01
Kiro / Local
→
02
Commit
→
03
Push
→
04
GitLab / Remote
someone changes the remote → pull it back
05
Web IDE Change
→
06
Pull
→
07
Branch & MR
→
08
Pipeline & Merge
→
09
GitLab Pages
START HEREเริ่มตรงนี้

Workshop Overviewภาพรวม Workshop

GitLab is more than a place to store code. It helps developers keep history, work safely in branches, review changes, and run automated checks before code is merged. GitLab ไม่ได้มีไว้แค่เก็บโค้ด แต่ช่วยให้ Developer เก็บประวัติการแก้ไข แยกงานด้วย Branch ตรวจงานผ่าน Merge Request และรันการตรวจสอบอัตโนมัติก่อน Merge

01STOREKeep code in a repositoryเก็บโค้ดใน Repository
→
02CHANGEWork safely in branchesแก้ไขงานผ่าน Branch
→
03REVIEWReview with Merge RequestsReview ผ่าน Merge Request
→
04VALIDATERun automated checksตรวจสอบด้วย Pipeline
LAB 00

GitLab 101 — What is GitLab?GitLab 101 — GitLab คืออะไร?

GitLab is a DevSecOps platform built around Git. For this starter workshop, we focus on the core development workflow you will see in real software teams. GitLab คือแพลตฟอร์ม DevSecOps ที่ทำงานร่วมกับ Git สำหรับ Starter Workshop นี้ เราจะโฟกัสเฉพาะ workflow พื้นฐานที่พบในทีมพัฒนาซอฟต์แวร์จริง

Repository

The home of your project files and complete change history.พื้นที่เก็บไฟล์ของโปรเจกต์และประวัติการเปลี่ยนแปลงทั้งหมด

Commit

A saved checkpoint describing what changed in your project.จุดบันทึกการเปลี่ยนแปลง พร้อมข้อความอธิบายว่าแก้อะไร

Branch

A separate line of work that lets you change code without immediately touching main.พื้นที่ทำงานแยกจาก main เพื่อให้แก้โค้ดได้อย่างปลอดภัย

Merge Request

A place to review a change before bringing it back into main.พื้นที่สำหรับตรวจสอบการเปลี่ยนแปลงก่อนนำกลับเข้า main

Pipeline

Automated jobs that test or validate your code after a change.ชุดงานอัตโนมัติที่ใช้ตรวจสอบโค้ดหลังมีการเปลี่ยนแปลง

main

The primary branch that should contain the stable version of your project.Branch หลักที่ควรเก็บเวอร์ชันที่เสถียรของโปรเจกต์

LAB 01

Get Readyเตรียมความพร้อม

Before starting the labs, confirm that your GitLab account and local Git environment are ready. ก่อนเริ่ม Lab ให้ตรวจสอบว่า GitLab account และ Git บนเครื่องพร้อมใช้งาน

  • GitLab.com account created and email verifiedมี GitLab.com account และ Verify email เรียบร้อย
  • Able to sign in to GitLab.comสามารถ Sign in เข้า GitLab.com ได้
  • Git installed on your laptopติดตั้ง Git บนเครื่องแล้ว
  • Terminal available: PowerShell / Terminalมี Terminal ที่ใช้งานได้ เช่น PowerShell / Terminal
  • A simple project folder containing index.htmlมีโฟลเดอร์โปรเจกต์ตัวอย่างที่มีไฟล์ index.html
LAB 02

Connect Kiro to GitLabเชื่อม Kiro กับ GitLab

Start with the project already open in Kiro, create an empty GitLab project, then connect your local folder to the remote repository. เริ่มจากโปรเจกต์ที่เปิดอยู่ใน Kiro สร้าง GitLab Project แบบว่าง แล้วเชื่อมโฟลเดอร์บนเครื่องเข้ากับ Remote Repository

LOCAL → REMOTE

Create and connect the repositoryสร้างและเชื่อม Repository

~20 min
  1. Create a blank project on GitLab.com.สร้าง Blank Project บน GitLab.com
  2. Leave Initialize repository with a README unchecked.ไม่ต้องเลือก Initialize repository with a README
  3. Copy the HTTPS clone URL.Copy Clone URL แบบ HTTPS
  4. Open Terminal in the Kiro project folder and connect it to GitLab.เปิด Terminal ในโฟลเดอร์ Kiro แล้วเชื่อมเข้ากับ GitLab
git init
git branch -M main
git remote add origin <your GitLab HTTPS URL>
WHAT JUST HAPPENED?เมื่อกี้เราเชื่อมอะไร? git remote add origin ... connects the local Git repository in your Kiro project to the remote repository on GitLab. origin is the name Git uses for that remote location. git remote add origin ... คือการเชื่อม Local Git Repository ที่อยู่ใน Project ของ Kiro เข้ากับ Remote Repository บน GitLab โดย origin คือชื่อที่ Git ใช้เรียก Remote นี้
CONNECTION CHECK

Verify the Kiro ↔ GitLab connectionตรวจสอบว่า Kiro ↔ GitLab เชื่อมกันแล้ว

CHECKPOINT

Before committing or pushing anything, confirm that the correct GitLab remote has been configured. ก่อน Commit หรือ Push ให้ตรวจสอบก่อนว่า Local Project ชี้ไปยัง GitLab Repository ที่ถูกต้องแล้ว 

git remote -v

You should see something similar to: ควรเห็นผลลัพธ์ประมาณนี้: 

origin  https://gitlab.com/username/project.git (fetch)
origin  https://gitlab.com/username/project.git (push)
SUCCESSเชื่อมสำเร็จ If origin shows your GitLab project URL for both fetch and push, the local project is connected to the correct GitLab remote. Next: Commit → Push. ถ้าเห็น origin เป็น URL ของ GitLab Project ของเรา ทั้งฝั่ง fetch และ push แสดงว่า Local Project เชื่อมกับ GitLab Remote ถูกต้องแล้ว ขั้นต่อไปคือ Commit → Push
CONCEPT Local = the project on your laptop. Remote = the project stored on GitLab. Local = โปรเจกต์บนเครื่องเรา ส่วน Remote = โปรเจกต์ที่อยู่บน GitLab
LAB 03

Make Your First Commitสร้าง Commit แรก

Use Kiro's Source Control view so participants can see exactly which files changed before saving a checkpoint. ใช้หน้า Source Control ใน Kiro เพื่อให้เห็นว่าไฟล์ไหนเปลี่ยน ก่อนบันทึกการเปลี่ยนแปลงเป็น Commit

SAVE HISTORY

Change → Review → Commit

~20 min
  1. Edit a small part of your HTML file in Kiro.แก้ข้อความเล็กน้อยในไฟล์ HTML ผ่าน Kiro
  2. Open Source Control and look at the changed file.เปิด Source Control แล้วดูไฟล์ที่มีการเปลี่ยนแปลง
  3. Review the diff before committing.ดู Diff ว่าแก้อะไรไปบ้างก่อน Commit
  4. Enter a message such as Update homepage title and commit.ใส่ข้อความ เช่น Update homepage title แล้ว Commit
COMMIT A commit is a saved checkpoint in your project's history. It does not automatically mean the change is already on GitLab. Commit คือการบันทึก Checkpoint ลงในประวัติของโปรเจกต์ แต่ยังไม่ได้หมายความว่างานถูกส่งขึ้น GitLab แล้ว
LAB 04

Push & Pull — Local Meets RemotePush & Pull — เมื่อ Local ทำงานร่วมกับ Remote

First push your local commit to GitLab. Then use GitLab Web IDE to simulate another developer changing the remote project, and pull that change back into Kiro. เริ่มจาก Push Commit จากเครื่องขึ้น GitLab จากนั้นใช้ GitLab Web IDE จำลองว่า Developer อีกคนเข้ามาแก้งานบน Remote แล้ว Pull การเปลี่ยนแปลงนั้นกลับลงมาใน Kiro

PART A · PUSH

Send your commit to GitLabส่ง Commit ขึ้น GitLab

~10 min
LKiro / LocalCommit
→
↑PushLocal → Remote
→
RGitLabRemote
git push --set-upstream origin main
CHECKPOINT Refresh GitLab. Your file and commit should now appear in the remote repository. Refresh หน้า GitLab แล้วตรวจว่าไฟล์และ Commit ปรากฏบน Remote Repository แล้ว
PART B · REMOTE CHANGE

Simulate another developerจำลองว่ามี Developer อีกคนแก้งาน

~15 min
  1. Open the same project in GitLab Web IDE.เปิด Project เดิมผ่าน GitLab Web IDE
  2. Pretend this browser session is Developer B.สมมติว่า Web IDE นี้คือ Developer B
  3. Change one obvious text value, for example a heading or footer.แก้ข้อความที่สังเกตเห็นง่าย เช่น Heading หรือ Footer
  4. Commit the change directly in Web IDE.Commit การเปลี่ยนแปลงผ่าน Web IDE
SCENARIO GitLab now has a newer commit, but the copy in Kiro is still old. This is the moment that makes Pull meaningful. ตอนนี้ GitLab มี Commit ใหม่กว่า แต่ Code ใน Kiro ยังเป็นเวอร์ชันเก่า นี่คือสถานการณ์ที่ทำให้เห็นว่า Pull ใช้ทำอะไร
PART C · PULL

Bring the remote change back to Kiroดึง Change จาก GitLab กลับเข้า Kiro

~10 min
RGitLabNew remote commit
→
↓PullRemote → Local
→
LKiroUpdated local code
git pull
  1. Return to Kiro.กลับมาที่ Kiro
  2. Run git pull.รัน git pull
  3. Open the HTML file again and find the text changed in Web IDE.เปิดไฟล์ HTML แล้วหา Text ที่เพิ่งแก้จาก Web IDE
REMEMBER Push = Local → Remote    |    Pull = Remote → Local
LAB 05

BranchBranch

Learn why developers avoid changing main directly and how a branch creates a safe workspace.เรียนรู้ว่าทำไม Developer ไม่ควรแก้ main โดยตรง และ Branch ช่วยแยกพื้นที่ทำงานอย่างไร

STEP 01

Create a feature branchสร้าง Feature Branch

~20 min
  1. Open Code → Web IDE.
  2. Create branch feature/update-homepage from main.
  3. Edit a small part of index.html.
  4. Review the diff.
  5. Commit with a clear message such as Update homepage title.
LAB 06

Merge RequestMerge Request

A Merge Request lets you compare, discuss, and review a branch before merging it into main.Merge Request ใช้สำหรับเปรียบเทียบ ตรวจสอบ และ Review การเปลี่ยนแปลงก่อน Merge เข้า main

BRBranchYour changeงานที่แก้
→
MRMerge RequestReview the diffReview Diff
→
MNmainStable branchBranch หลัก
  1. Create a Merge Request from feature/update-homepage to main.
  2. Open the Changes tab.
  3. Check exactly what lines were added or removed.
  4. Confirm the change is what you intended.
LAB 07

Your First PipelinePipeline แรกของคุณ

A pipeline runs automated jobs. For this starter lab, we only check whether index.html exists.Pipeline ใช้รันงานแบบอัตโนมัติ ใน Lab นี้เราจะเริ่มง่าย ๆ ด้วยการตรวจว่าไฟล์ index.html มีอยู่จริง

CI/CD STARTER

.gitlab-ci.yml

~25 min 
stages:
  - test

check-html:
  stage: test
  script:
    - test -f index.html
    - echo "index.html found"
  1. Create .gitlab-ci.yml.
  2. Commit the file to your feature branch.
  3. Open the Merge Request and watch the pipeline run.
  4. Wait for the pipeline to show Passed.
  5. Merge the Merge Request into main.
Key ideaแนวคิดสำคัญ The pipeline gives the team automated evidence that a change passes the checks before it reaches main. Pipeline ช่วยให้ทีมมีหลักฐานจากระบบอัตโนมัติว่า Change ผ่านการตรวจสอบก่อนเข้าสู่ main
LAB 08

Deploy with GitLab PagesDeploy เว็บด้วย GitLab Pages

After the CI checks pass and the change is merged into main, publish the static website with GitLab Pages. หลังจาก CI ตรวจสอบผ่านและ Merge Change เข้า main แล้ว ให้ Publish Static Website ด้วย GitLab Pages

CI → CD

From repository to live websiteจาก Repository สู่เว็บไซต์ที่เปิดใช้งานได้

~20 min
CIPipelineValidate
→
MNmainMerge
→
CDGitLab PagesDeploy
→
URLWebsiteLive
stages:
  - test
  - deploy

check-html:
  stage: test
  script:
    - test -f index.html
    - echo "index.html found"

deploy-pages:
  stage: deploy
  script:
    - mkdir -p public
    - cp index.html public/index.html
  pages: true
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  1. Update .gitlab-ci.yml with the deploy job above.ปรับ .gitlab-ci.yml โดยเพิ่ม Deploy Job ด้านบน
  2. Commit the change to the feature branch and update the Merge Request.Commit Change ลง Feature Branch และ Update Merge Request
  3. Wait for the CI check to pass, then merge into main.รอ CI Check ผ่าน แล้ว Merge เข้า main
  4. The pipeline on main runs the GitLab Pages deployment.Pipeline บน main จะรัน GitLab Pages Deployment
  5. Open Deploy → Pages and open the generated website URL.ไปที่ Deploy → Pages แล้วเปิด Website URL ที่ระบบสร้างให้
FINAL OUTPUTผลลัพธ์สุดท้าย The project has passed CI and is now deployed as a real website through GitLab Pages. Project ผ่าน CI และถูก Deploy ออกมาเป็นเว็บไซต์จริงผ่าน GitLab Pages แล้ว
WORKSHOP FLOW Kiro / Local → GitLab Connection → Commit → Push → GitLab → Web IDE Change → Pull → Branch → Merge Request → Pipeline → Merge main → GitLab Pages

Starter Troubleshootingแก้ปัญหาเบื้องต้น

Common errors you may see during your first GitLab workflow.Error ที่มักพบเมื่อเริ่มใช้งาน GitLab ครั้งแรก

remote origin already exists

git remote set-url origin <your GitLab HTTPS URL>

Permission denied (publickey)

You copied an SSH URL. Use the HTTPS clone URL instead.คุณ Copy URL แบบ SSH มา ให้เปลี่ยนไปใช้ Clone URL แบบ HTTPS

nothing to commit, working tree clean

There is no new change to commit. You can continue to the next step.ไม่มี Change ใหม่ให้ Commit สามารถไปขั้นตอนถัดไปได้

Browser sign-in does not appear

Check the taskbar, confirm your default browser, then retry git push.ตรวจ taskbar และ default browser แล้วลอง git push ใหม่

What You Will Learnเมื่อจบ Workshop คุณจะทำอะไรได้บ้าง