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. Your work → Projects → Create new project → Create blank project on GitLab.com.Your work → Projects → Create new project → สร้าง Blank Project บน GitLab.com
  2. Visibility Level: Private เลือก Private
  3. Leave Initialize repository with a README unchecked.ไม่ต้องเลือก Initialize repository with a README
  4. Copy the HTTPS clone URL.Copy Clone URL แบบ HTTPS
  5. 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 แรก

Ask Kiro's AI to generate a README.md for the project, then use Source Control to review and save it as your first commit. ให้ AI ของ Kiro ช่วยสร้างไฟล์ README.md ให้กับโปรเจกต์ จากนั้นใช้หน้า Source Control เพื่อตรวจสอบและบันทึกเป็น Commit แรก

PROMPT → COMMIT → VERIFY

Prompt → Review → Commit

~20 min
  1. Open Kiro's AI chat and run a prompt such as Create a README.md file describing this project.เปิดหน้า AI Chat ของ Kiro แล้วรัน Prompt เช่น Create a README.md file describing this project
  2. Let Kiro generate readme.md and review the content it created.ปล่อยให้ Kiro สร้างไฟล์ readme.md แล้วอ่านตรวจสอบเนื้อหาที่ถูกสร้างขึ้น
  3. Open Source Control and confirm readme.md appears as a new, untracked file.เปิด Source Control แล้วตรวจสอบว่ามีไฟล์ readme.md ขึ้นเป็นไฟล์ใหม่ (untracked)
  4. Review the diff before committing.ดู Diff ว่าแก้อะไรไปบ้างก่อน Commit
  5. Enter a message such as Add README.md and click the plain Commit button — this is your first commit.ใส่ข้อความ เช่น Add README.md แล้วกดปุ่ม Commit ธรรมดา — นี่คือ Commit แรกของคุณ
  6. Check the project folder to confirm readme.md actually exists on disk and was included in the commit.ตรวจสอบโฟลเดอร์โปรเจกต์ว่ามีไฟล์ readme.md อยู่จริง และถูกรวมอยู่ใน Commit
git log --stat -1
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 แล้ว
NOT YETยังไม่ต้องกด The commit dropdown also offers Commit & Push and Commit & Sync, and a Sync Changes button may appear right after committing. Skip these for now — pushing to GitLab is covered next, in LAB 04. ปุ่ม Commit จะมี dropdown ให้เลือก Commit & Push หรือ Commit & Sync และหลัง Commit อาจมีปุ่ม Sync Changes ขึ้นมาด้วย ให้ข้ามไปก่อน เพราะการ Push ขึ้น GitLab จะสอนใน LAB 04
VERIFYตรวจสอบ git log --stat -1 shows the most recent commit and lists which files it includes — use it to confirm readme.md was really committed. git log --stat -1 จะแสดง Commit ล่าสุดพร้อมรายชื่อไฟล์ที่อยู่ใน Commit นั้น ใช้เพื่อยืนยันว่า readme.md ถูก Commit ไปจริง
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. In Kiro, click the branch name in the bottom-left status bar (or open Source Control → Branches).ใน Kiro คลิกชื่อ Branch ที่มุมล่างซ้าย (หรือเปิด Source Control → Branches)
  2. Choose Create new branch and name it update-homepage, created from main.เลือก Create new branch แล้วตั้งชื่อ update-homepage โดยแตกจาก main
  3. Edit a small part of index.html.แก้ไขข้อความเล็กน้อยในไฟล์ index.html
  4. Review the diff.ดู Diff ว่าแก้อะไรไปบ้าง
  5. Commit with a clear message such as Update homepage title.ใส่ข้อความ เช่น Update homepage title แล้ว Commit
git checkout -b Update homepage title
WHY A BRANCH?ทำไมต้องแยก Branch? Working on update-homepage keeps main untouched until the change is reviewed. Push and Merge Request come next. การทำงานบน update-homepage ทำให้ main ไม่ถูกแก้ไขจนกว่าจะผ่านการ Review ขั้นต่อไปคือ Push แล้วสร้าง Merge Request
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 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 คุณจะทำอะไรได้บ้าง