Mục lục

Tại sao Manual Tester nên học Git?
Git và GitLab khác nhau thế nào?
Bốn nơi một thay đổi đi qua
Chuẩn bị trước khi làm việc
Workflow hằng ngày
Commit và cách viết commit message
Branch: làm việc mà không ảnh hưởng main
Đồng bộ với GitLab
Merge Request và review
Merge và rebase ở mức căn bản
Conflict và cách xử lý
Sửa những lỗi Git thường gặp
Quy tắc làm việc nhóm
Cheatsheet và bài thực hành

Là gì? Đây là handbook thực hành Git/GitLab cho người chưa có nền tảng kỹ thuật sâu. Tại sao? Học quá nhiều khái niệm nội bộ của Git ngay từ đầu dễ gây rối và không giúp hoàn thành công việc hằng ngày. Để làm gì? Sau tài liệu này, bạn có thể tham gia một project, quản lý thay đổi và cộng tác với team một cách an toàn.

Nguyên tắc quan trọng nhất: nếu chưa hiểu một lệnh sẽ xóa hoặc thay đổi thứ gì, đừng chạy lệnh đó. Hãy dùng git status, chụp lại thông báo lỗi và hỏi người có kinh nghiệm. Không dùng git reset --hard, git clean -fd hoặc git push --force để thử vận may.

1. Tại sao Manual Tester nên học Git?

Là gì? Git là công cụ ghi lại lịch sử thay đổi của file trong project. Tại sao? Test case, checklist, tài liệu, cấu hình và automation script đều thay đổi theo thời gian. Để làm gì? Biết ai đã sửa gì, so sánh phiên bản và làm việc chung mà không ghi đè file của nhau.

1.1 Git giúp gì cho công việc QA?

Là gì? Git tạo một lịch sử có thể kiểm tra cho các file của project. Tại sao? Gửi file qua chat hoặc đặt tên test-case-final-v3 rất khó biết đâu là bản mới nhất. Để làm gì? Giữ một nguồn chính thức và truy lại được từng thay đổi.

Ví dụ QA có thể quản lý bằng Git:

automation test;
test data không chứa thông tin nhạy cảm;
checklist regression;
tài liệu hướng dẫn setup;
API collection hoặc configuration;
file mô tả test case dạng Markdown;
script hỗ trợ tạo dữ liệu test.

1.2 Git không chỉ dành cho developer

Là gì? Git quản lý file, không giới hạn file đó phải là source code. Tại sao? QA cũng tạo và bảo trì tài sản của project. Để làm gì? Cho phép QA dùng cùng quy trình review, lịch sử và phát hành với team phát triển.

Bạn không cần hiểu thuật toán bên trong Git để bắt đầu. Bạn chỉ cần hiểu:

mình đang ở branch nào;
file nào đã thay đổi;
file nào sẽ được đưa vào commit;
commit nào chưa được gửi lên GitLab;
thay đổi sẽ được review ở Merge Request nào.

1.3 Git không thay thế backup và ticket

Là gì? Git lưu phiên bản file; ticket lưu yêu cầu/ngữ cảnh; backup bảo vệ hệ thống khi có sự cố. Tại sao? Một commit không giải thích đầy đủ acceptance criteria và file chưa commit vẫn có thể mất. Để làm gì? Dùng đúng công cụ cho đúng mục đích và liên kết chúng với nhau.

2. Git và GitLab khác nhau thế nào?

Là gì? Git là công cụ quản lý phiên bản; GitLab là website/server để lưu repository và cộng tác. Tại sao? Nhiều người nhầm “đã commit” nghĩa là “đã lên GitLab”. Để làm gì? Biết thay đổi đang chỉ ở máy cá nhân hay đã được chia sẻ với team.

2.1 Git là gì?

Là gì? Git chạy trên máy của bạn và quản lý lịch sử của project. Tại sao? Bạn có thể tạo branch, xem thay đổi và commit ngay cả khi chưa kết nối GitLab. Để làm gì? Lưu các mốc thay đổi có ý nghĩa trước khi chia sẻ.

Các lệnh như sau chủ yếu làm việc trên máy cá nhân:

git status
git diff
git add
git commit
git branch

2.2 GitLab là gì?

Là gì? GitLab là nơi team lưu bản repository dùng chung và thực hiện review. Tại sao? Local repository trên máy bạn không thể tự cộng tác với cả team. Để làm gì? Push branch, mở Merge Request, thảo luận, chạy pipeline và merge thay đổi.

GitLab thường cung cấp:

repository dùng chung;
quản lý thành viên và quyền;
Merge Request;
issue/ticket;
review và approval;
pipeline tự động;
report và artifact.

2.3 Ví dụ dễ nhớ

Là gì? Có thể xem Git như cuốn sổ lịch sử trên máy, còn GitLab như thư viện chung của team. Tại sao? Phép so sánh giúp phân biệt local và remote. Để làm gì? Nhớ rằng commit vào “sổ của mình” chưa đồng nghĩa đã nộp lên “thư viện”.

git commit = lưu một mốc ở máy cá nhân
git push   = gửi các mốc đó lên GitLab

3. Bốn nơi một thay đổi đi qua

Là gì? Một thay đổi thường đi qua Working folder → Staging → Local repository → GitLab. Tại sao? Mỗi lệnh Git chỉ tác động lên một hoặc vài nơi trong chuỗi này. Để làm gì? Hiểu dữ liệu hiện đang ở đâu và bước tiếp theo là gì.

// Bốn nơi một thay đổi đi qua

3.1 Working folder

Là gì? Đây là thư mục project bạn đang mở trong VS Code. Tại sao? Mọi file bạn sửa trước tiên chỉ thay đổi tại đây. Để làm gì? Viết test case, sửa script hoặc cập nhật tài liệu.

Lưu file bằng Ctrl+S chưa tạo commit và chưa gửi file lên GitLab.

3.2 Staging

Là gì? Staging là danh sách những thay đổi bạn đã chọn cho commit tiếp theo. Tại sao? Bạn có thể sửa nhiều file nhưng chỉ muốn commit một phần. Để làm gì? Kiểm soát chính xác nội dung của commit.

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

3.3 Local commit

Là gì? Commit là một mốc lịch sử đã lưu trong repository trên máy bạn. Tại sao? Commit giúp nhóm biết một thay đổi hoàn chỉnh gồm những gì và vì sao. Để làm gì? Cho phép review, so sánh, hoàn tác hoặc tìm nguồn lỗi.

3.4 GitLab remote

Là gì? Remote là repository dùng chung trên GitLab. Tại sao? Commit local chưa được team nhìn thấy. Để làm gì? Push branch lên GitLab để backup theo hệ thống của tổ chức, chạy pipeline và mở Merge Request.

3.5 `git status` là lệnh nên chạy nhiều nhất

Là gì? git status mô tả branch hiện tại và trạng thái file. Tại sao? Nó giúp tránh commit nhầm file hoặc thao tác trên sai branch. Để làm gì? Kiểm tra trước và sau mỗi bước quan trọng.

git status

4. Chuẩn bị trước khi làm việc

Là gì? Setup gồm Git đã được cài, danh tính đúng và quyền truy cập GitLab. Tại sao? Nếu setup sai, commit có thể mang sai tên hoặc máy không thể clone/push. Để làm gì? Tạo môi trường sẵn sàng trước khi sửa project.

4.1 Kiểm tra Git

Là gì? Lệnh version xác nhận máy đã nhận Git. Tại sao? VS Code cần Git executable để sử dụng Source Control. Để làm gì? Phân biệt lỗi chưa cài Git với lỗi repository.

git --version

Trong môi trường công ty, chỉ cài Git bằng nguồn được IT phê duyệt. Không tự tải installer hoặc tắt antivirus để cài.

4.2 Cấu hình tên và email

Là gì? Tên/email được ghi vào mỗi commit. Tại sao? Team cần biết ai thực hiện thay đổi và GitLab cần liên kết commit với tài khoản. Để làm gì? Tạo lịch sử đúng danh tính.

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

Sử dụng email theo quy định công ty. Không dùng email hoặc account của người khác.

4.3 Clone project

Là gì? Clone tạo bản project cùng lịch sử Git trên máy. Tại sao? Tải ZIP chỉ cung cấp file hiện tại và không có branch/remote history đầy đủ. Để làm gì? Tham gia đúng repository đang được team sử dụng.

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

Lấy URL từ đúng GitLab project. Không clone repository không rõ nguồn rồi chạy script bên trong.

4.4 Mở project trong VS Code

Là gì? VS Code hiển thị file và Source Control của repository đang mở. Tại sao? Mở nhầm thư mục cha/con có thể khiến VS Code không nhận đúng repository. Để làm gì? Xem thay đổi, stage, commit và conflict qua giao diện.

code .

Trong VS Code:

Explorer: xem file;
Source Control: xem file thay đổi;
Terminal: chạy lệnh Git;
status bar phía dưới: xem branch hiện tại.

4.5 Kiểm tra trước khi sửa file

Là gì? Đây là bước xác nhận repository, branch và trạng thái ban đầu. Tại sao? Sửa file khi đang ở main hoặc còn thay đổi cũ dễ gây nhầm lẫn. Để làm gì? Tạo điểm xuất phát sạch và rõ ràng.

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

5. Workflow hằng ngày

Là gì? Workflow hằng ngày là chuỗi thao tác lặp lại mỗi khi xử lý một ticket. Tại sao? Thứ tự ổn định giúp giảm lỗi và dễ nhờ hỗ trợ. Để làm gì? Hoàn thành thay đổi từ máy cá nhân đến Merge Request.

// Workflow đơn giản cho một ticket

5.1 Bước 1 — cập nhật `main`

Là gì? main thường là branch chính chứa phiên bản được team chấp nhận. Tại sao? Tạo branch từ main cũ làm tăng nguy cơ conflict. Để làm gì? Bắt đầu công việc từ phiên bản mới nhất.

git switch main
git pull --ff-only

Nếu lệnh báo lỗi, không thêm --force. Chạy git status và nhờ hỗ trợ nếu không hiểu thông báo.

5.2 Bước 2 — tạo branch cho ticket

Là gì? Branch là không gian làm việc riêng cho một thay đổi. Tại sao? Không nên sửa trực tiếp trên main. Để làm gì? Giữ thay đổi của ticket tách biệt cho đến khi được review.

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

5.3 Bước 3 — sửa file và kiểm tra diff

Là gì? Diff là phần nội dung khác nhau giữa file hiện tại và phiên bản Git đang lưu. Tại sao? Tool format hoặc thao tác nhầm có thể sửa nhiều hơn dự kiến. Để làm gì? Tự review trước khi commit.

git status
git diff

Trong VS Code, chọn từng file ở Source Control để xem phần màu xanh/đỏ đã thay đổi.

5.4 Bước 4 — chọn file cho commit

Là gì? Stage nghĩa là chọn thay đổi sẽ đi vào commit. Tại sao? Không phải mọi file đang modified đều thuộc ticket. Để làm gì? Tránh commit log, file tạm hoặc thay đổi không liên quan.

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

Người mới nên stage từng file thay vì luôn dùng git add ..

5.5 Bước 5 — commit

Là gì? Commit lưu phần staged thành một mốc local. Tại sao? Message giúp team hiểu mục đích thay đổi. Để làm gì? Chuẩn bị lịch sử rõ ràng trước khi push.

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

5.6 Bước 6 — push

Là gì? Push gửi commit local trên branch lên GitLab. Tại sao? Team chưa thể review branch chỉ tồn tại trên máy bạn. Để làm gì? Tạo branch remote và mở Merge Request.

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

Những lần sau trên cùng branch thường chỉ cần:

git push

5.7 Bước 7 — mở Merge Request

Là gì? Merge Request đề nghị đưa branch của bạn vào main. Tại sao? Team cần review và pipeline trước khi merge. Để làm gì? Nhận phản hồi và tích hợp thay đổi có kiểm soát.

6. Commit và cách viết commit message

Là gì? Commit là một mốc lịch sử có nội dung, người tạo, thời gian và message. Tại sao? Commit tốt giúp người khác hiểu và hoàn tác thay đổi. Để làm gì? Chia công việc thành những phần nhỏ, hoàn chỉnh và dễ review.

6.1 Một commit nên chứa gì?

Là gì? Một commit nên phục vụ một mục tiêu rõ. Tại sao? Trộn nhiều mục tiêu làm review và hoàn tác khó hơn. Để làm gì? Giữ lịch sử đơn giản.

Ví dụ tốt:

cập nhật test case đăng nhập sai mật khẩu;
sửa một locator bị hỏng;
bổ sung hướng dẫn cài đặt;
thêm test data cho một rule cụ thể.

Ví dụ nên tách:

vừa sửa test login, vừa format 30 file khác;
vừa cập nhật tài liệu, vừa nâng dependency không liên quan;
vừa sửa bug A, vừa thêm feature B.

6.2 Commit là “mốc có ý nghĩa”, không phải mỗi lần bấm Save

Là gì? Save chỉ lưu file; commit ghi lại một trạng thái có thể hiểu và review. Tại sao? Commit kiểu save, wip, try again không giúp history. Để làm gì? Chỉ commit khi một phần công việc đã có ý nghĩa rõ.

6.3 Convention đơn giản

Là gì? Convention là mẫu chung cho commit message. Tại sao? Mỗi người viết một kiểu làm log khó đọc. Để làm gì? Nhìn message là biết loại và phạm vi thay đổi.

<type>(<scope>): <mô tả ngắn>

Ví dụ:

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

Convention này dựa trên Conventional Commits nhưng đã được rút gọn cho người mới.

6.4 Các `type` cần nhớ

Là gì? type nói thay đổi thuộc nhóm nào. Tại sao? Người mới không cần ghi nhớ quá nhiều type. Để làm gì? Phân loại những thay đổi QA gặp thường xuyên.

Type	Khi nào dùng?	Ví dụ
`test`	Thêm hoặc sửa test	`test(order): cover cancellation rule`
`fix`	Sửa lỗi trong code/test	`fix(login): use stable locator`
`docs`	Sửa tài liệu	`docs(git): add conflict guide`
`feat`	Thêm khả năng mới	`feat(report): add CSV export`
`chore`	Dọn dẹp/bảo trì nhỏ	`chore(data): remove old fixture`

6.5 `scope` là gì?

Là gì? Scope là khu vực bị thay đổi, ví dụ login, order, setup. Tại sao? Nó giúp người đọc biết commit liên quan phần nào của project. Để làm gì? Làm message cụ thể hơn.

Nếu team đã có danh sách scope, dùng đúng danh sách đó. Nếu chưa có, chọn một tên ngắn và dễ hiểu.

6.6 Mô tả tốt và chưa tốt

Là gì? Phần mô tả tóm tắt kết quả của commit. Tại sao? Các câu như update file hoặc fix issue không cho biết điều gì thật sự thay đổi. Để làm gì? Giúp log có thể hiểu mà không mở từng diff.

Chưa tốt	Tốt hơn
`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: làm việc mà không ảnh hưởng `main`

Là gì? Branch là một nhánh làm việc riêng bắt đầu từ một phiên bản của project. Tại sao? Nếu mọi người cùng sửa trực tiếp main, thay đổi chưa review có thể ảnh hưởng cả team. Để làm gì? Mỗi ticket có khu vực riêng trước khi merge.

// Feature branch tách khỏi main rồi quay lại qua Merge Request

7.1 Kiểm tra branch hiện tại

Là gì? Branch hiện tại là nơi commit mới sẽ được tạo. Tại sao? Commit nhầm vào main là lỗi phổ biến của người mới. Để làm gì? Xác nhận trước khi sửa hoặc commit.

git branch --show-current
git status

7.2 Tạo branch

Là gì? git switch -c tạo branch mới và chuyển sang branch đó. Tại sao? Mỗi ticket cần tách khỏi công việc khác. Để làm gì? Giữ phạm vi Merge Request nhỏ và rõ.

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

7.3 Cách đặt tên branch

Là gì? Tên branch nên cho biết loại công việc, ticket và mô tả ngắn. Tại sao? Tên test1 hoặc my-branch không có ngữ cảnh. Để làm gì? Dễ tìm và liên kết branch với ticket.

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

7.4 Chuyển branch

Là gì? git switch thay nội dung working folder theo branch được chọn. Tại sao? Git có thể từ chối nếu file đang sửa sẽ bị ghi đè. Để làm gì? Chuyển giữa các công việc một cách có kiểm soát.

git status
git switch main

Nếu Git báo local changes would be overwritten, dừng lại. Hãy commit, stash hoặc hỏi người hướng dẫn; không xóa thay đổi chỉ để chuyển branch.

7.5 Xóa branch sau khi merge

Là gì? Branch ticket thường không cần giữ sau khi thay đổi đã merge. Tại sao? Quá nhiều branch cũ làm danh sách khó đọc. Để làm gì? Giữ repository gọn.

GitLab thường có tùy chọn Delete source branch khi merge. Với branch local:

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

Không dùng -D nếu chưa xác nhận branch đã merge hoặc không còn dữ liệu cần giữ.

8. Đồng bộ với GitLab

Là gì? Đồng bộ là lấy thay đổi của team về máy và gửi commit của bạn lên GitLab. Tại sao? Local và GitLab không tự cập nhật cho nhau. Để làm gì? Làm việc trên phiên bản mới và chia sẻ branch.

8.1 `origin` là gì?

Là gì? origin thường là tên Git đặt cho GitLab repository khi clone. Tại sao? Lệnh push/fetch cần biết server nào được sử dụng. Để làm gì? Gọi remote bằng một tên ngắn.

git remote -v

8.2 `git pull`

Là gì? Pull lấy thay đổi mới từ GitLab và cập nhật branch hiện tại. Tại sao? Team có thể đã merge thay đổi mới. Để làm gì? Giữ main local gần với main trên GitLab.

git switch main
git pull --ff-only

Người mới chỉ nên pull khi đã kiểm tra đúng branch và working folder không có thay đổi chưa xử lý.

8.3 `git push`

Là gì? Push gửi commit local lên branch tương ứng trên GitLab. Tại sao? Commit local chưa được team thấy hoặc review. Để làm gì? Cập nhật Merge Request.

git push

8.4 Push bị từ chối

Là gì? GitLab có thể từ chối khi remote đã thay đổi, branch được bảo vệ hoặc bạn không có quyền. Tại sao? Đây là hàng rào bảo vệ, không phải lý do để force. Để làm gì? Đọc lỗi và chọn cách xử lý đúng.

Khi gặp lỗi:

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

Chụp toàn bộ thông báo và hỏi team nếu chưa hiểu. Không dùng git push --force.

9. Merge Request và review

Là gì? Merge Request (MR) là yêu cầu đưa thay đổi từ branch của bạn vào branch chính. Tại sao? Team cần xem, thảo luận và kiểm tra trước khi merge. Để làm gì? Bảo đảm thay đổi đúng yêu cầu và không làm hỏng project.

9.1 Một MR cần có gì?

Là gì? MR gồm title, description, source branch, target branch, reviewer, diff và pipeline. Tại sao? Chỉ đưa link branch không đủ ngữ cảnh cho reviewer. Để làm gì? Giúp reviewer hiểu nhanh và kiểm tra đúng trọng tâm.

Mẫu đơn giản:

## Mục tiêu
Cập nhật regression checklist cho luồng đăng nhập.

## Thay đổi
- Thêm case tài khoản bị khóa.
- Cập nhật expected result cho mật khẩu hết hạn.

## Đã kiểm tra
- Review diff.
- Chạy smoke test login.

## Ticket
PROJ-123

9.2 Source và target branch

Là gì? Source là branch có thay đổi; target là branch sẽ nhận thay đổi. Tại sao? Chọn sai target có thể đưa code vào sai phiên bản. Để làm gì? Xác nhận hướng merge trước khi tạo MR.

Thông thường:

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

Nếu project dùng target khác, làm theo quy định team.

9.3 Review là kiểm tra gì?

Là gì? Review là đọc thay đổi và xác nhận nó đúng, đủ, an toàn và dễ bảo trì. Tại sao? Pipeline không hiểu toàn bộ nghiệp vụ. Để làm gì? Phát hiện sai phạm vi, thiếu test hoặc dữ liệu nhạy cảm trước merge.

Reviewer nên kiểm tra:

thay đổi có đúng ticket không;
có file lạ hoặc secret không;
test case có expected result rõ không;
automation có assertion thật sự không;
thay đổi có làm mất case cũ không;
tên file/commit có dễ hiểu không;
pipeline có pass không.

9.4 Trả lời comment review

Là gì? Discussion ghi lại câu hỏi và đề nghị sửa trên MR. Tại sao? Quyết định quan trọng cần được lưu cùng thay đổi. Để làm gì? Giúp tác giả và reviewer thống nhất trước merge.

Quy trình:

đọc kỹ comment;
hỏi lại nếu chưa hiểu;
sửa file trên cùng branch;
commit và push;
trả lời đã sửa gì;
để reviewer xác nhận trước khi resolve nếu team yêu cầu.

9.5 Khi nào MR sẵn sàng merge?

Là gì? MR sẵn sàng khi nội dung, review và kiểm tra tự động đều đạt quy định. Tại sao? Nút Merge xuất hiện không có nghĩa mọi rủi ro đã được xử lý. Để làm gì? Chỉ đưa thay đổi đã được xác nhận vào branch chính.

đúng source/target;
không còn conflict;
pipeline required pass;
reviewer đã approve;
comment quan trọng đã xử lý;
không có secret hoặc file tạm;
MR description phản ánh đúng thay đổi cuối.

Tài liệu chính thức: GitLab Merge Requests.

10. Merge và rebase ở mức căn bản

Là gì? Merge và rebase là hai cách đưa lịch sử từ các branch về cùng một nền. Tại sao? Project có thể yêu cầu branch phải cập nhật với main trước khi merge. Để làm gì? Giảm conflict và giúp GitLab hợp nhất thay đổi.

10.1 Merge là gì?

Là gì? Merge kết hợp thay đổi của hai branch. Tại sao? Hai nhánh có thể phát triển song song. Để làm gì? Đưa feature branch vào main hoặc cập nhật branch theo policy.

Với người mới, merge vào main nên thực hiện qua nút Merge của GitLab sau review, không tự push trực tiếp vào main.

10.2 Rebase là gì?

Là gì? Rebase đặt lại các commit của branch bạn lên phiên bản main mới hơn. Có thể hình dung Git “nhấc” thay đổi của bạn lên rồi đặt lại sau thay đổi mới của team. Tại sao? Branch tạo từ main cũ có thể không còn cập nhật. Để làm gì? Chuẩn bị branch trước merge theo quy định của project.

// Rebase đưa thay đổi của bạn lên main mới nhất

10.3 Khi nào người mới cần rebase?

Là gì? Rebase thường cần khi GitLab báo branch behind target hoặc project dùng lịch sử tuyến tính. Tại sao? Rebase thay đổi mã commit và có thể phát sinh conflict. Để làm gì? Chỉ thực hiện khi workflow team yêu cầu hoặc có người hướng dẫn.

Quy trình cơ bản trên branch của riêng bạn:

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

Điều kiện:

không ở main;
working folder sạch;
branch chỉ do bạn sử dụng;
đã hiểu cách abort nếu lỗi.

10.4 Rebase dừng vì conflict

Là gì? Git không biết cách đặt lại một commit khi main đã sửa cùng vùng. Tại sao? Rebase cần quyết định của con người. Để làm gì? Resolve rồi tiếp tục hoặc quay lại trạng thái trước rebase.

# Sau khi đã sửa và stage toàn bộ conflict
git rebase --continue

# Hủy toàn bộ rebase và quay lại trước khi bắt đầu
git rebase --abort

Không dùng git rebase --skip chỉ để bỏ qua lỗi; nó có thể bỏ luôn thay đổi cần thiết.

10.5 Push sau rebase

Là gì? Vì rebase thay đổi lịch sử branch, Git có thể từ chối push bình thường. Tại sao? Force-push sai có thể ghi đè commit của người khác. Để làm gì? Đây là điểm người mới nên dừng và nhờ hướng dẫn.

Không tự chạy git push --force. Nếu team cho phép --force-with-lease, hãy để người hướng dẫn xác nhận đúng branch và lịch sử trước lần đầu thực hiện.

Tài liệu chi tiết hơn: git-rebase.

11. Conflict và cách xử lý

Là gì? Conflict xảy ra khi Git không thể tự kết hợp hai thay đổi. Tại sao? Hai người có thể sửa cùng một dòng hoặc một bên xóa file mà bên kia đang sửa. Để làm gì? Yêu cầu con người quyết định nội dung cuối cùng.

11.1 Conflict không có nghĩa ai làm sai

Là gì? Conflict chỉ nói rằng Git cần trợ giúp. Tại sao? Hai thay đổi đều có thể đúng khi thực hiện riêng. Để làm gì? Trao đổi dựa trên nghiệp vụ thay vì chọn bên của mình theo thói quen.

11.2 Conflict markers

Là gì? Git chèn ba marker để hiển thị hai phần nội dung đang xung đột. Tại sao? File còn marker thường không thể chạy đúng. Để làm gì? Chỉ ra vùng cần chỉnh sửa.

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

Kết quả cuối có thể chọn một bên, kết hợp cả hai hoặc viết nội dung mới. Quan trọng là nó phải đúng yêu cầu hiện tại.

11.3 Resolve bằng VS Code

Là gì? VS Code Merge Editor hiển thị các phần xung đột và vùng Result. Tại sao? Giao diện dễ đọc hơn marker thô. Để làm gì? Chỉnh kết quả cuối và stage file.

Các bước:

chạy git status để xem file conflict;
mở Source Control trong VS Code;
chọn file trong nhóm Merge Changes;
đọc cả hai phía;
chỉnh Result thành nội dung đúng;
lưu file;
stage file;
kiểm tra lại và tiếp tục operation.

11.4 Không bấm “Accept All” khi chưa đọc

Là gì? Accept Current/Incoming chọn nhanh một phía. Tại sao? Một file có thể cần kết hợp logic của cả hai phía. Để làm gì? Nhắc người resolve chịu trách nhiệm về kết quả, không chỉ làm conflict biến mất.

Nếu không hiểu nội dung, hỏi tác giả của hai thay đổi. Manual tester không cần tự quyết định logic code mà không có context.

11.5 Hoàn tất conflict

Là gì? Sau khi chỉnh file, cần stage và yêu cầu Git tiếp tục merge/rebase. Tại sao? Chỉ lưu file chưa báo cho Git biết conflict đã được xử lý. Để làm gì? Hoàn tất operation.

git status
git add path/to/resolved-file

# Nếu đang rebase
git rebase --continue

Sau đó:

tìm marker còn sót;
chạy test liên quan;
đọc diff;
xác nhận không mất nội dung cần thiết.

11.6 Khi không chắc chắn: abort

Là gì? Abort hủy operation đang diễn ra và thường quay lại trạng thái trước khi bắt đầu. Tại sao? Resolve sai có thể nguy hiểm hơn việc tạm dừng. Để làm gì? Quay lại điểm an toàn để nhờ hỗ trợ.

git rebase --abort
git merge --abort

Chỉ chạy lệnh đúng với operation mà git status đang báo.

12. Sửa những lỗi Git thường gặp

Là gì? Git có nhiều cách sửa sai tùy thay đổi chưa stage, đã stage, đã commit hay đã push. Tại sao? Dùng sai lệnh có thể làm mất file. Để làm gì? Chọn cách an toàn nhất cho từng trường hợp.

12.1 Stage nhầm file

Là gì? File đã được chọn cho commit nhưng chưa commit. Tại sao? Có thể bạn bấm stage all hoặc dùng git add .. Để làm gì? Bỏ file khỏi staging nhưng giữ nguyên nội dung đang sửa.

git restore --staged path/to/file

12.2 Muốn bỏ thay đổi chưa commit

Là gì? git restore <file> đưa file tracked về nội dung Git đang lưu. Tại sao? Thay đổi chưa commit có thể không khôi phục được sau khi bị ghi đè. Để làm gì? Chỉ bỏ thay đổi khi chắc chắn không còn cần.

git diff -- path/to/file

# CẢNH BÁO: lệnh sau bỏ thay đổi chưa commit của file
git restore path/to/file

Nếu còn phân vân, copy nội dung ra nơi an toàn hoặc hỏi người hướng dẫn trước.

12.3 Commit thiếu file hoặc sai message

Là gì? Amend thay commit cuối bằng phiên bản mới. Tại sao? Nó phù hợp khi commit vẫn chỉ ở máy bạn. Để làm gì? Bổ sung file quên stage hoặc sửa message.

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

Không amend commit đã push nếu chưa hiểu history rewrite và chưa phối hợp với team.

12.4 Muốn hoàn tác commit đã lên GitLab

Là gì? Revert tạo commit mới đảo ngược thay đổi của commit cũ. Tại sao? Xóa commit đã chia sẻ có thể ảnh hưởng người khác. Để làm gì? Hoàn tác có lịch sử rõ trên branch chung.

git revert <commit-id>

Với main hoặc production, thực hiện qua quy trình MR/incident của team, không tự revert và push nếu không có quyền.

12.5 Commit nhầm branch

Là gì? Commit nằm trên branch không mong muốn. Tại sao? Người dùng quên kiểm tra branch trước khi làm. Để làm gì? Bảo toàn commit trước, rồi nhờ người có kinh nghiệm đưa nó về đúng branch.

Việc đầu tiên:

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

Không reset hoặc xóa branch ngay. Gửi ba output trên cho người hỗ trợ.

12.6 Lỡ xóa branch hoặc mất commit

Là gì? Git có reflog ghi lại một số vị trí gần đây trên máy. Tại sao? Commit đôi khi vẫn còn dù branch pointer bị xóa. Để làm gì? Cung cấp manh mối để người có kinh nghiệm khôi phục.

git reflog

Không thử nhiều lệnh reset sau khi phát hiện mất commit. Càng ít thay đổi thêm, việc hỗ trợ càng dễ.

12.7 Các lệnh người mới không nên tự dùng

Là gì? Đây là các lệnh có thể xóa file hoặc viết lại lịch sử. Tại sao? Tác động không phải lúc nào cũng khôi phục được. Để làm gì? Nhận diện vùng nguy hiểm và dừng lại hỏi trước.

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

13. Quy tắc làm việc nhóm

Là gì? Quy tắc nhóm thống nhất cách đặt branch, commit, review và bảo vệ dữ liệu. Tại sao? Git linh hoạt nên mỗi người làm một kiểu sẽ tạo history khó dùng. Để làm gì? Giảm nhầm lẫn và giúp người mới biết chính xác phải làm theo đâu.

13.1 Không sửa trực tiếp `main`

Là gì? Mọi thay đổi đi qua branch và Merge Request. Tại sao? main là nguồn chung và thường được bảo vệ. Để làm gì? Bắt buộc review/pipeline trước merge.

13.2 Một branch cho một ticket

Là gì? Mỗi branch chỉ xử lý một mục tiêu. Tại sao? Trộn nhiều ticket làm MR lớn và khó hoàn tác. Để làm gì? Giữ review nhanh và rõ.

13.3 Commit nhỏ nhưng hoàn chỉnh

Là gì? Commit không quá lớn nhưng vẫn chứa đủ thay đổi cần thiết. Tại sao? Commit quá nhỏ kiểu save gây nhiễu, commit quá lớn khó review. Để làm gì? Tạo lịch sử có ý nghĩa.

13.4 Không commit secret hoặc dữ liệu thật

Là gì? Secret gồm password, token, cookie, private key và credential. Tại sao? Xóa ở commit sau không làm chúng biến mất khỏi lịch sử cũ. Để làm gì? Bảo vệ hệ thống và dữ liệu người dùng.

Không commit:

.env có secret;
password hoặc API token;
authentication state/cookie;
dữ liệu khách hàng;
screenshot có thông tin nhạy cảm;
private certificate/key;
file download từ môi trường thật.

Nếu secret đã bị commit, báo ngay cho lead/security để thu hồi hoặc rotate. Không chỉ xóa file rồi coi như đã an toàn.

13.5 `.gitignore`

Là gì? .gitignore liệt kê file/thư mục Git nên bỏ qua. Tại sao? Project thường sinh log, report, dependency và secret local không nên commit. Để làm gì? Giữ repository sạch.

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

.gitignore không xóa file đã được commit trước đó.

13.6 Không resolve comment review cho có

Là gì? Resolve discussion nghĩa là vấn đề đã được xử lý hoặc thống nhất. Tại sao? Bấm resolve khi chưa sửa làm mất tín hiệu review. Để làm gì? Giữ MR phản ánh đúng trạng thái.

13.7 Đọc `CONTRIBUTING.md` và README của project

Là gì? Đây là nơi project ghi quy tắc riêng. Tại sao? Convention trong handbook chỉ là mặc định chung. Để làm gì? Ưu tiên quy định thật của project về branch, commit, rebase và review.

14. Cheatsheet và bài thực hành

Là gì? Cheatsheet giúp tra nhanh; lab giúp luyện thao tác trên repository an toàn. Tại sao? Nhìn lệnh không đủ để tạo phản xạ. Để làm gì? Biết làm và biết dừng khi trạng thái khác dự kiến.

14.1 Lệnh quan sát an toàn

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

14.2 Workflow một ticket

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

# sử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 Khi có feedback

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

14.4 Khi có conflict lúc rebase

git status
# sửa file bằng VS Code
git add path/to/resolved-file
git rebase --continue

# Hoặc hủy rebase
git rebase --abort

14.5 Bảng “tôi muốn làm gì?”

Mong muốn	Lệnh/bước đầu tiên
Xem file nào đã đổi	`git status`
Xem nội dung chưa stage	`git diff`
Xem nội dung sắp commit	`git diff --staged`
Tạo branch	`git switch -c <branch>`
Chọn file cho commit	`git add <file>`
Tạo commit	`git commit -m "..."`
Gửi branch lên GitLab	`git push -u origin <branch>`
Unstage nhưng giữ file	`git restore --staged <file>`
Hủy rebase	`git rebase --abort`
Không hiểu trạng thái	`git status`, dừng và hỏi

14.6 Lab 1 — clone và quan sát

Là gì? Lab đầu tiên chỉ clone và đọc trạng thái. Tại sao? Người mới nên quen quan sát trước khi thay đổi. Để làm gì? Nhận diện repository, branch và remote.

Tiêu chí:

clone đúng sandbox project;
mở đúng folder trong VS Code;
chỉ ra branch hiện tại;
đọc được output git status;
xác nhận URL remote không chứa credential.

14.7 Lab 2 — branch, commit và push

Là gì? Lab thực hiện workflow hoàn chỉnh với một file Markdown. Tại sao? File text dễ xem diff và không cần chạy code. Để làm gì? Tạo branch/commit đầu tiên an toàn.

cập nhật main;
tạo branch theo ticket giả;
sửa một đoạn tài liệu;
xem diff;
stage đúng file;
viết commit message đúng convention;
push branch;
mở MR dạng Draft.

14.8 Lab 3 — review

Là gì? Hai học viên review MR của nhau. Tại sao? GitLab workflow không kết thúc ở push. Để làm gì? Luyện đọc diff và phản hồi rõ ràng.

Reviewer phải tìm:

một điểm đúng;
một câu hỏi về phạm vi;
một kiểm tra secret/file thừa;
một xác nhận commit message;
kết luận approve hoặc yêu cầu sửa có lý do.

14.9 Lab 4 — conflict có hướng dẫn

Là gì? Giảng viên tạo conflict trong file Markdown sandbox. Tại sao? Lần đầu conflict không nên diễn ra trên project thật. Để làm gì? Luyện đọc hai phía, sửa Result và abort khi cần.

14.10 Checklist hoàn thành

14.11 Tài liệu tham khảo

Câu cần nhớ: trước khi commit, hãy xem diff; trước khi push, hãy kiểm tra branch; trước khi chạy lệnh xóa hoặc force, hãy dừng và hỏi.

GIT + GITLAB CHO NGƯỜI MỚI