Lệnh Git hàng ngày cho junior | status, add, commit, branch, PR【2026】

Fresher join team outsource hoặc startup Việt thường bị kẹt ở chỗ không phải “Git là gì”, mà là hôm nay sửa 3 file thì gõ lệnh nào, nhánh nào, khi nào được mở PR. Lead bảo “push lên rồi tạo PR” — bạn mở terminal, git status đỏ một đống, sợ add . lọt .env, sợ commit lên main.

Bài này là cheat sheet lệnh Git hàng ngày theo góc junior Việt: status / add / commit / branch / PR. Không phải tài liệu tham chiếu toàn bộ Git — chỉ những lệnh bạn gõ gần như mỗi ngày trong sprint.

Ai nên đọc

• Junior / intern tuần đầu trên repo GitHub của khách
• Freelancer nhận task nhỏ, cần PR sạch để lead review
• Sinh viên làm đồ án nhóm lần đầu dùng branch thay vì zip gửi Zalo

---

Vòng lặp tối thiểu (nhớ 4 lệnh)

Nếu chỉ nhớ được một câu: đừng commit trực tiếp lên main/master trên repo team. Tạo nhánh feature, push nhánh đó, mở Pull Request.

# Ví dụ một buổi sáng task "sửa validate form login"
git checkout main
git pull origin main
git checkout -b fix/login-validate
# ... sửa code ...
git status
git add src/components/LoginForm.tsx
git commit -m "fix: reject empty password on login form"
git push -u origin HEAD
# → mở PR trên GitHub

---

Bảng “muốn làm gì → lệnh nào”

Ghi nhớ: restore xóa thay đổi chưa commit trên file đó — không dùng như “undo nhẹ” nếu chưa chắc. Chưa chắc thì stash an toàn hơn.

---

git status — lệnh số 0

Trước mọi add / commit / push, chạy git status. Junior hay bỏ qua vì “chắc chỉ có 1 file” — rồi lọt debug.log, .env.local, hoặc file package-lock.json không thuộc task.

Đọc output theo 3 khối:

1. On branch … — đúng nhánh feature chưa? Đang ở main thì dừng, tạo nhánh mới.
2. Changes to be committed — đã stage, sẽ vào commit tới.
3. Changes not staged / Untracked — chưa stage; kiểm tra từng dòng trước khi add ..

git status
# On branch fix/login-validate
# Changes not staged for commit:
#   modified:   src/components/LoginForm.tsx
# Untracked files:
#   .env.local          ← ĐỪNG add
#   scratch-notes.md    ← cân nhắc

---

add và commit — đừng máy móc add .

Khi nào git add . ổn

• Repo nhỏ, task rõ, bạn vừa tạo vài file source mới
• Đã nhìn status và chắc không có secret / artifact

Khi nào nên add từng file

• Diff lẫn debug (console.log, file tạm)
• Có cả thay đổi liên quan task và thay đổi “thử cho vui”
• Team có pre-commit scan secret — vẫn tốt hơn nếu bạn không stage .env

# An toàn hơn cho junior
git add src/api/user.ts src/api/user.test.ts
git commit -m "feat: add pagination to user list API"

# Sửa message commit gần nhất — CHỈ khi chưa push
git commit --amend -m "feat: add pagination and empty-state for user list"

Quy ước message team outsource hay dùng Conventional Commits ngắn:

Prefix	Khi nào
feat:	Thêm hành vi / API / UI mới
fix:	Sửa bug
chore:	Config, dependency, dọn dẹp
docs:	README, comment hướng dẫn
refactor:	Đổi cấu trúc, không đổi behavior

Tránh: update, fix, asdasd, hoặc paste cả đoạn chat vào message.

---

Branch và PR — cách team Việt / outsource thường làm

Model đơn giản đủ dùng tuần đầu

1. main (hoặc develop) = nhánh ổn định, bạn không commit trực tiếp.
2. Mỗi ticket / task = một nhánh: feature/…, fix/…, chore/….
3. Push nhánh → mở Pull Request → lead review → merge.

# Bắt đầu task từ main mới nhất
git checkout main
git pull origin main
git checkout -b feature/export-csv-orders

# ... làm việc, commit nhiều lần trên nhánh này cũng được ...

git push -u origin HEAD

Trên GitHub: Compare & pull request → mô tả:

• Làm gì / ticket nào (link Jira/Linear nếu có)
• Cách test (bước reproduce)
• Screenshot nếu đổi UI
• Checklist: không có .env, không comment // TODO remove lộ ra production

pull trước khi PR — tránh conflict muộn

Nếu main đã có merge mới trong lúc bạn làm:

git checkout main
git pull origin main
git checkout feature/export-csv-orders
git merge main
# hoặc: git rebase main  — theo convention team
# resolve conflict → add → commit / rebase --continue
git push

Junior hay đợi conflict đến lúc bấm Merge trên GitHub. Merge local sớm = conflict nhỏ hơn, review dễ hơn.

---

Salvage: stash, restore, reset mềm

Đã push lên nhánh dùng chung: đừng reset + force push trừ khi lead cho phép. Tạo commit sửa tiếp thường an toàn hơn với junior.

---

Case study 1 — Intern lọt .env vào PR

Bối cảnh: Intern thêm VITE_API_URL vào .env, quên file đã untracked. git add . → commit → push → PR hiện secret staging.

Xử lý đúng:

1. Rotate key staging nếu đã public trên GitHub (kể cả PR private của org vẫn coi là rủi ro).
2. Thêm .env vào .gitignore, xóa file khỏi index: git rm --cached .env.
3. Commit chore; nhờ lead confirm history (nếu cần purge nâng cao thì để lead làm).

Phòng ngừa: luôn git status trước add; prefer add từng path; bật secret scanning nếu org có.

Case study 2 — Conflict trước demo khách

Bối cảnh: Hai người sửa cùng routes.ts. Bạn mở PR, GitHub báo conflict với main.

Cách làm gọn:

git fetch origin
git checkout feature/your-branch
git merge origin/main
# mở routes.ts, xóa <<<<<<< ======= >>>>>>>
git add routes.ts
git commit -m "merge: resolve routes conflict with main"
git push

Nếu conflict dài (hai bản JSON/config lệch nhiều), paste hai phía vào công cụ diff trên trình duyệt để nhìn thêm/xóa từng dòng trước khi quyết định giữ đoạn nào — nhanh hơn đọc marker Git trần khi file lớn.

---

Checklist trước khi mở PR

• Đúng nhánh feature, không push thẳng main
• git status sạch hoặc chỉ còn file cố ý bỏ ngoài
• Không có .env, key, dump DB, file zip
• Commit message đọc được; không một commit “fix everything” 40 file không liên quan (tách PR nếu cần)
• Đã pull/merge main gần nhất, conflict local đã xong
• Tự chạy test / smoke theo README
• Mô tả PR có bước verify cho reviewer

---

Lỗi junior hay mắc

Triệu chứng	Nguyên nhân hay gặp	Việc nên làm
rejected (fetch first) khi push	Remote có commit mới	git pull (hoặc rebase) rồi push lại
Detached HEAD	Checkout vào hash/tag	checkout lại tên nhánh
”Tôi mất code”	restore / reset nhầm	Học stash và commit WIP nhỏ thường xuyên
PR quá lớn	Làm nhiều ticket trên một nhánh	Một nhánh ≈ một mục review
Merge xong app chết	Conflict giữ cả hai đoạn sai	Chạy app local sau khi resolve

---

FAQ nhanh trong bài

Chỉ dùng GitHub Desktop có sao không? Được lúc mới học, nhưng terminal giúp bạn hiểu status/add khi CI fail hoặc conflict — học song song vẫn tốt.

Bao nhiêu commit trên một PR? Không có số thần thánh. Nhiều commit nhỏ rõ nghĩa dễ review hơn một commit khổng lồ; có thể squash lúc merge nếu team bật.

Có cần thuộc rebase -i ngay không? Không. Biết merge main vào feature và resolve conflict là đủ cho tháng đầu.

---

Liên kết liên quan

• So sánh diff trên trình duyệt — đọc hai bản config/code khi conflict dài
• Best practices file .env — tránh commit secret
• Danh sách công cụ