HUET » AKA Lab - Git Safety Foundation Before Vibe Coding

BÁO CÁO KẾT QUẢ THỰC HÀNH: GIT & GITHUB FOUNDATIONS
(Đại diện điều kiện chuyển tiếp sang khóa học Vibe Coding - AKA Lab)

1. Thông tin học viên
   Họ và tên: Huỳnh Quang Đạt
   Lớp: KHDL K6
   Mã số sinh viên: 25E1020008
   Link GitHub Repository thực hành: https://github.com/huynhquangdat826-rgb/quangdat

2. Mục tiêu thực hành & Thu hoạch cá nhân
   Qua dự án này, tôi đã hoàn thiện và làm chủ các năng lực cốt lõi bao gồm:

• Thấu hiểu tư duy quản lý phiên bản và vai trò của Git trong vòng đời phát triển phần mềm
• Thành thạo quy trình khởi tạo, cấu hình và quản lý Git Repository (Local & Remote).
• Sử dụng nhuần nhuyễn bộ lệnh cơ bản để điều phối dữ liệu: clone, add, commit, push, pull, status, log.
• Áp dụng tư duy chia để trị thông qua cấu trúc Branch nhằm cô lập và thử nghiệm tính năng.
• Làm chủ quy trình cộng tác tiêu chuẩn GitHub Flow: Quản lý công việc bằng Issues/Project board, đề xuất thay đổi qua Pull Request.
• Tự tin đối mặt và xử lý các xung đột mã nguồn (Merge Conflict) từ cơ bản đến nâng cao.
• Biết cách kích hoạt "cỗ máy thời gian" revert/reset để rollback an toàn khi hệ thống gặp sự cố.
• Thấm nhuần các nguyên tắc bảo mật, không để lộ thông tin nhạy cảm khi đưa mã nguồn lên môi trường đám mây.

3. Nội dung & Minh chứng thực hiện
   3.1 Hoàn thành lộ trình Microsoft Learn
   Tôi đã hoàn thành 100% các module học tập được giao thuộc lộ trình chuẩn GitHub Foundations:

Part 1: Làm quen với Git/GitHub cơ bản, mô hình repository, quản lý branch, cơ chế commit, quy trình pull request và luồng làm việc GitHub Flow.
Part 2: Kỹ năng cộng tác nâng cao, quản trị dự án trực quan, bảo mật an toàn repository, truy vết lịch sử thay đổi, quản trị và nhập môn sử dụng GitHub Copilot.

[Minh chứng hình ảnh đính kèm trong Issue Redmine]

3.2 Quản lý Branch (Nhánh)
Để phục vụ cho các kịch bản thử nghiệm và sửa lỗi độc lập, tôi đã khởi tạo và điều phối thành công 04 branches khác nhau trên hệ thống bao gồm:
main: Nhánh chính đóng vai trò lưu trữ mã nguồn ổn định nhất.
dat-patch-1: Nhánh thực hiện các tinh chỉnh và cập nhật tính năng nhỏ ban đầu.
conflict: Nhánh giả định dùng để tạo và kiểm thử kịch bản xung đột mã nguồn lần 1.
conflict-2: Nhánh giả định thứ hai dùng để tạo xung đột chéo trực tiếp trên cùng một phân đoạn dữ liệu.

3.3 Hoạt động Commit & Pull Request
Lịch sử Commit: Hệ thống đã ghi nhận tối thiểu 10 commits có thông điệp (message) tường minh, ghi lại rõ ràng từng bước phát triển của dự án mà không bị chồng chéo. (Chi tiết hiển thị đầy đủ qua link repo đính kèm).
Pull Request (PR): Tôi đã khởi tạo thành công ít nhất 02 Pull Requests trên GitHub nhằm tuân thủ quy trình kiểm định nghiêm ngặt trước khi gộp mã nguồn vào nhánh chính)

3.4 Thực hành xử lý Merge Conflict (Xung đột mã nguồn)
Kịch bản giả định: Từ nhánh main, tôi rẽ nhánh sang conflict, chỉnh sửa nội dung tại dòng số 30 của file README.md và tạo Pull Request để merge vào nhánh chính thành công. Ngay sau đó, tại nhánh main, một thay đổi khác cũng được thực hiện tại chính dòng số 30 này, đồng thời nhánh conflict-2 cũng can thiệp vào vị trí đó. Khi tiến hành hợp nhất nhánh conflict-2 vào main, hệ thống lập tức báo lỗi xung đột do không tự xác định được đâu là dữ liệu đích.

Giải pháp xử lý: Tôi đã kích hoạt trình chỉnh sửa trực quan Resolve conflicts trên giao diện Web của GitHub. Tại đây, tôi tiến hành rà soát kỹ lưỡng, bóc tách và xóa bỏ hoàn toàn các thẻ đánh dấu xung đột (<<<<<<<, =======, >>>>>>>). Sau khi chọn lọc và giữ lại nội dung đồng nhất chính xác nhất, tôi thực hiện commit xác nhận để hoàn tất quá trình gộp nhánh an toàn.

3.5 Thực hành Rollback / Revert (Khôi phục dữ liệu)
Tình huống thực tế: Sau khi vô tình thực hiện một commit chứa nội dung sai sót lên hệ thống, tôi cần đưa dự án về trạng thái an toàn trước đó mà không làm xáo trộn hay mất đi lịch sử làm việc của các thành viên khác.

Giải pháp xử lý:

Tôi sử dụng lệnh git log --oneline để truy vết nhanh danh sách lịch sử và trích xuất chính xác mã định danh Commit ID lỗi

Kết quả: Git tự động tạo ra một commit mới có nhiệm vụ đảo ngược hoàn toàn các thay đổi sai lầm của commit cũ. Dự án quay về trạng thái mong muốn một cách an toàn và lịch sử commit vẫn được bảo toàn tính minh bạch.

4. Hệ thống hóa bộ lệnh Git đã làm chủ
   Khởi tạo & Đồng bộ ban đầu
   git init: Khởi tạo một Git repository hoàn toàn mới tại thư mục cục bộ.
   git clone : Sao chép toàn bộ mã nguồn và lịch sử của một repo từ GitHub về máy tính cá nhân.
   Kiểm soát trạng thái & Truy vết
   git status: Kiểm tra trạng thái hiện tại của các file (xem file nào đã sửa, chưa stage hoặc sẵn sàng commit).
   git log: Xem lại toàn bộ nhật ký lịch sử các commit trong dự án.
   git log --oneline: Rút gọn nhật ký commit hiển thị dưới dạng một dòng, tối ưu cho việc tra cứu nhanh Commit ID.

Quản lý khu vực đệm & Ghi nhận thay đổi
git add : Đưa một file cụ thể vào khu vực đệm (Staging Area).
git add .: Đưa toàn bộ các file có thay đổi vào khu vực đệm cùng một lúc.
git restore : Loại bỏ các thay đổi vừa chỉnh sửa của file, đưa file quay về trạng thái của commit gần nhất.
git commit -m "message": Đóng gói và lưu vĩnh viễn các thay đổi từ khu vực đệm vào lịch sử kèm thông điệp ý nghĩa.
git commit --amend: Chỉnh sửa nhanh thông điệp hoặc bổ sung file vào commit gần nhất vừa tạo.

Quản trị nhánh và Hợp nhất (Branching & Merging)
git branch: Liệt kê toàn bộ các nhánh hiện có trong repo nội bộ.
git branch <tên_nhánh>: Tạo ra một nhánh mới từ vị trí hiện tại.
git checkout <tên_nhánh>: Di chuyển vị trí làm việc sang nhánh được chỉ định.
git checkout -b <tên_nhánh>: Phím tắt để vừa khởi tạo vừa di chuyển ngay sang nhánh mới đó.
git merge <tên_nhánh>: Tích hợp và hợp nhất mã nguồn của nhánh chỉ định vào nhánh hiện hành.
git branch -d <tên_nhánh>: Xóa bỏ an toàn một nhánh sau khi đã hoàn thành việc gộp dữ liệu.
Tương tác dữ liệu từ xa (Remote Cloud)
git remote -v: Kiểm tra danh sách và đường link của các remote repository đang kết nối.
git remote add origin : Thiết lập liên kết repo cục bộ với repo từ xa trên GitHub.
git push: Đẩy toàn bộ các commit mới từ máy cục bộ lên nhánh tương ứng trên GitHub.
git push origin <tên_nhánh>: Đẩy đích danh một nhánh cụ thể lên hệ thống mã nguồn đám mây.
git pull: Chủ động kéo toàn bộ cập nhật mới nhất từ GitHub về và tự động gộp vào repo dưới máy.

Sửa sai & Phục hồi hệ thống
git revert <commit_id>: Tạo ra một commit mới để đảo ngược thay đổi của một commit lỗi, đảm bảo an toàn cho lịch sử dự án.

git reset --soft <commit_id>: Di chuyển con trỏ về commit cũ được chỉ định, tuy nhiên toàn bộ code đã viết ở các commit sau đó vẫn được giữ nguyên ở khu vực đệm để chỉnh sửa tiếp.

git reset --hard <commit_id>: Lệnh "xóa sổ" mạnh mẽ, đưa dự án quay thẳng về commit được chỉ định và xóa sạch mọi thay đổi chưa lưu sau thời điểm đó.

So sánh & Đối chiếu
git diff: So sánh sự khác biệt của các file vừa sửa đổi so với trạng thái chưa đưa vào Staging Area.

git diff --staged: So sánh sự khác biệt của các file đã nằm trong Staging Area so với commit gần nhất.

5. Tư duy hành động: Tôi sẽ dùng Git như thế nào khi Vibe Code với AI?
   Khi bước vào kỷ nguyên "Vibe Coding" — nơi tốc độ sinh mã nguồn của AI nhanh hơn rất nhiều so với tốc độ gõ phím truyền thống — tôi nhận thức sâu sắc rằng Git không chỉ đơn thuần là công cụ lưu trữ, mà chính là "Hệ thống bảo hiểm tối cao" giữ cho tôi thế chủ động. Để kiểm soát AI một cách thông minh, tôi sẽ tuân thủ nghiêm ngặt các nguyên tắc hành động sau:

Sử dụng Git làm "Phanh an toàn" trước sự "nhiệt tình" của AI: AI có thể tạo ra hàng trăm dòng code phức tạp chỉ trong vài giây, nhưng tính chính xác và độ tương thích cần phải được kiểm chứng. Tôi sẽ luôn duy trì thói quen dùng lệnh git diff để rà soát, mổ xẻ tỉ mỉ từng dòng code do AI gợi ý trước khi gõ lệnh git add. Việc này giúp tôi luôn giữ vai trò là người tổng chỉ huy kiểm duyệt mã nguồn, tuyệt đối không phó mặc dự án cho AI.

Tách nhánh (Branching) cô lập cho mọi thử nghiệm Prompt: Mỗi khi giao tiếp với AI để triển khai một tính năng mới, tối ưu thuật toán (Refactor) hay sửa lỗi, tôi sẽ không bao giờ can thiệp trực tiếp trên nhánh main. Quy tắc bất di bất dịch là tạo riêng các nhánh độc lập như feature/ai-prompt hoặc test/ai-refactor. Nếu AI hiểu sai "vibe" và sinh code làm hỏng cấu trúc, thiệt hại sẽ hoàn toàn bị cô lập trong nhánh thử nghiệm đó, bảo vệ tuyệt đối sự ổn định của lõi hệ thống.

Kích hoạt "Cỗ máy thời gian" để kiểm soát rủi ro: Trong trường hợp đoạn code do AI tạo ra gây ra lỗi logic nghiêm trọng hoặc làm sập hệ thống, tôi sẽ không hoang mang. Bằng việc phối hợp linh hoạt giữa lệnh git log --oneline để định vị và git revert/git reset, tôi có thể dễ dàng quay ngược thời gian, đưa toàn bộ dự án trở về trạng thái ổn định gần nhất trước khi sự cố xảy ra.

Đóng gói commit nhỏ, rõ ràng và có tần suất cao: Thay vì để AI viết một mạch từ đầu đến cuối rồi mới commit, tôi sẽ chủ động chia nhỏ quá trình. Cứ mỗi khi AI hỗ trợ giải quyết xong một module hoặc một hàm chức năng chạy tốt, tôi sẽ thực hiện commit ngay với thông điệp tường minh. Lịch sử commit chi tiết này không chỉ giúp tôi dễ theo dõi tiến độ, mà còn cung cấp một ngữ cảnh (context) sạch sẽ, rõ ràng để tôi cung cấp ngược lại cho AI đọc khi cần tiếp tục phát triển hệ thống.

Dùng Pull Request làm "Chốt chặn kiểm định cuối cùng": Mọi mã nguồn do AI tạo ra, dù có chạy thử nghiệm thành công dưới máy cục bộ, đều chỉ được phép tích hợp vào nhánh chính thông qua Pull Request trên GitHub. Giao diện PR sẽ là nơi tôi tự review lại bản thân một lần nữa dưới góc nhìn khách quan, đồng thời mở ra không gian để các Mentor kiểm định chất lượng, đảm bảo mã nguồn đạt chuẩn trước khi đóng dự án.

Lời kết: Khi bước vào thế giới Vibe Coding, AI sẽ là "trợ lý tăng tốc" giúp tôi hiện thực hóa ý tưởng với tốc độ tối đa, còn Git chính là "bộ não kiểm soát" giúp tôi đi nhanh nhưng luôn đi đúng hướng và an toàn.