Mẹo dùng Git/GitHub cho developer từ cơ bản đến nâng cao 2026

05/05/2026 Tuấn Lê Developer Tools, devops, Git, GitHub, Lập trình

Git và GitHub không chỉ là nơi để lưu code. Nếu dùng đúng, chúng giúp bạn làm việc sạch hơn, review dễ hơn, rollback an toàn hơn và phối hợp với team ít đau đầu hơn. Vấn đề là nhiều người học Git theo kiểu nhớ vài lệnh quen thuộc, rồi dùng cùng một workflow trong nhiều năm mà không biết Git/GitHub còn rất nhiều tính năng có thể tiết kiệm thời gian mỗi ngày.

Trong bài Mẹo dùng Git/GitHub cho developer từ cơ bản đến nâng cao 2026, tôi sẽ đi theo hướng thực dụng: không cố biến Git thành một chủ đề học thuật, cũng không chỉ liệt kê lệnh để copy. Mục tiêu là giúp bạn hiểu cách dùng Git/GitHub tốt hơn trong công việc thật: từ lúc mới clone repo, sửa file, commit, tạo branch, mở pull request, xử lý conflict, bảo vệ branch quan trọng, cho đến các mẹo nâng cao như git reflog, git worktree, git sparse-checkout và rerere.

Năm 2026, Git vẫn là nền tảng version control quan trọng nhất với developer, còn GitHub đã vượt xa vai trò “nơi lưu source code”. GitHub hiện là nơi review code, chạy CI/CD, kiểm tra bảo mật, quản lý dependency, bảo vệ branch, quét secret và phối hợp phát triển sản phẩm. Vì vậy, học Git/GitHub đúng cách không chỉ giúp bạn push code lên remote, mà còn giúp bạn làm việc chuyên nghiệp hơn trong mọi dự án.

1. Vì sao nên học lại Git/GitHub dù đã dùng nhiều năm?

Rất nhiều developer dùng Git hằng ngày nhưng vẫn chỉ xoay quanh vài lệnh:

git add .
git commit -m "update"
git push
git pull

Cách dùng này không sai, nhưng nó dễ tạo ra một workflow thiếu kiểm soát. Bạn có thể commit nhầm file, gom quá nhiều thay đổi vào một commit, không biết cách tự cứu khi reset nhầm, hoặc mở pull request khiến reviewer phải đọc một khối thay đổi quá lớn.

Git tốt không phải là biết thật nhiều lệnh lạ. Git tốt là tạo ra lịch sử thay đổi dễ hiểu, dễ review, dễ rollback và dễ debug. GitHub tốt không phải là repo có nhiều badge cho đẹp, mà là repo có quy trình giúp code vào nhánh chính một cách an toàn.

Nếu bạn là người mới, bài này giúp bạn tránh các thói quen xấu ngay từ đầu. Nếu bạn đã dùng Git lâu năm, bài này giúp bạn rà lại workflow hiện tại và bổ sung những phần thường bị bỏ qua trong dự án thật.

2. Tư duy đúng trước khi học lệnh Git

Người mới thường học Git bằng cách nhớ lệnh, nhưng cách học bền hơn là hiểu trạng thái. Một thay đổi trong Git thường đi qua ba vùng:

Working directory  ->  Staging area  ->  Repository

Working directory là nơi bạn đang sửa file. Staging area là nơi bạn chọn những thay đổi sẽ đi vào commit tiếp theo. Repository là lịch sử commit đã được lưu lại.

Trước khi commit, hãy tập thói quen chạy:

git status
git diff
git diff --staged

git status cho biết file nào đang thay đổi, file nào đã được stage. git diff giúp bạn xem thay đổi chưa stage. git diff --staged giúp bạn kiểm tra chính xác nội dung sắp được commit.

Điểm quan trọng ở đây là: đừng commit khi bạn chưa tự đọc lại diff. Một phút tự review trước khi commit có thể tiết kiệm rất nhiều thời gian review và debug về sau.

3. Cấu hình Git tối thiểu sau khi cài mới

Sau khi cài Git, bạn nên cấu hình danh tính commit trước. Đây là thông tin sẽ xuất hiện trong lịch sử commit của repo.

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Tiếp theo, nên đặt editor mặc định nếu bạn thường viết commit message dài:

git config --global core.editor "code --wait"

Nếu muốn nhánh mặc định khi tạo repo mới là main, dùng:

git config --global init.defaultBranch main

Với người dùng Windows, macOS hoặc Linux khác nhau, line ending có thể gây diff giả. Nếu team đã có quy chuẩn bằng .editorconfig hoặc .gitattributes, hãy ưu tiên quy chuẩn của project. Với repo nghiêm túc, không nên để từng máy tự quyết định format file theo cảm tính.

4. Đừng dùng `git add .` như phản xạ vô điều kiện

git add . tiện, nhưng cũng là lý do nhiều người commit nhầm file tạm, log, file cấu hình local hoặc thay đổi chưa liên quan. Trước khi dùng git add ., hãy luôn xem trạng thái:

git status

Nếu chỉ muốn stage một file cụ thể:

git add path/to/file

Nếu muốn stage từng phần thay đổi trong cùng một file, dùng:

git add -p

git add -p là một trong những lệnh đáng học sớm nhất. Nó cho phép bạn chọn từng hunk thay đổi để đưa vào commit. Ví dụ, bạn vừa sửa bug đăng nhập và đồng thời format lại vài dòng code trong cùng một file. Thay vì gom tất cả vào một commit, bạn có thể tách phần sửa bug và phần format thành hai commit riêng.

Lịch sử commit sạch thường bắt đầu từ staging sạch.

5. Commit message nên viết cho người đọc sau này

Một commit message tốt không cần quá dài, nhưng phải trả lời được câu hỏi: thay đổi này làm gì và vì sao tồn tại?

Không nên:

git commit -m "fix"
git commit -m "update"
git commit -m "final"
git commit -m "fix bug"

Nên:

git commit -m "fix login redirect after token expiry"
git commit -m "add validation for checkout form"
git commit -m "refactor user repository query"
git commit -m "docs: update local setup guide"

Với team hoặc dự án có CI/CD, bạn có thể dùng kiểu Conventional Commits:

feat: add GitHub OAuth login
fix: prevent duplicate webhook events
docs: update deployment guide
refactor: simplify payment service
chore: update dependencies

Lợi ích của format này là dễ đọc log, dễ generate changelog và dễ tích hợp automation về sau. Nhưng đừng biến commit message thành nghi thức hình thức. Điều quan trọng nhất vẫn là message phải rõ nghĩa.

6. Commit nhỏ tốt hơn một commit khổng lồ

Một commit tốt nên đại diện cho một ý định thay đổi tương đối trọn vẹn. Nếu một commit vừa sửa UI, vừa đổi database schema, vừa cập nhật dependency, vừa format hàng chục file, reviewer sẽ rất khó hiểu đâu là thay đổi chính.

Commit nhỏ giúp:

Review nhanh hơn.
Rollback an toàn hơn.
Debug bằng git bisect dễ hơn.
Người đọc lịch sử repo hiểu được tiến trình thay đổi.
Giảm khả năng che giấu bug trong một diff quá lớn.

Một nguyên tắc thực tế: nếu bạn không thể viết commit message rõ ràng trong một dòng, có thể commit đó đang chứa quá nhiều thứ.

7. Dùng branch theo mục đích, không dùng branch như thư mục nháp

Branch nên đại diện cho một mục tiêu cụ thể. Tên branch không cần dài, nhưng nên đủ rõ để người khác nhìn vào hiểu bạn đang làm gì.

git switch -c feat/github-login
git switch -c fix/payment-timeout
git switch -c chore/update-dependencies
git switch -c docs/setup-guide

Tránh những tên branch kiểu:

update
test
new-code
final-version
fix-all

Với dự án nhỏ, bạn có thể dùng mô hình đơn giản:

main        - code ổn định
feat/*      - tính năng mới
fix/*       - sửa lỗi
docs/*      - tài liệu
chore/*     - việc bảo trì

Branch rõ ràng giúp Pull Request dễ hiểu hơn, giúp CI/CD dễ đặt rule hơn và giúp team tránh merge nhầm thay đổi chưa sẵn sàng.

8. Hiểu đúng `git pull`, `fetch`, `merge` và `rebase`

git pull thực chất là thao tác lấy thay đổi từ remote rồi tích hợp vào branch hiện tại. Với người mới, đây là lệnh tiện. Nhưng khi dự án bắt đầu có nhiều người cùng làm, bạn nên hiểu rõ hơn.

Lệnh này chỉ lấy thông tin mới từ remote, chưa đụng vào branch hiện tại:

git fetch origin

Sau đó, bạn có thể xem branch local đang lệch gì so với remote:

git status
git log --oneline --decorate --graph --all

Nếu muốn merge thay đổi từ main vào branch hiện tại:

git merge origin/main

Nếu muốn đặt lại commit của branch hiện tại lên trên đầu mới nhất của main:

git rebase origin/main

Merge giữ lại lịch sử phân nhánh rõ ràng. Rebase giúp lịch sử tuyến tính hơn. Không có lựa chọn nào đúng cho mọi team. Điều quan trọng là team phải thống nhất quy ước, đặc biệt với branch đã push lên remote và có người khác đang dùng.

Một nguyên tắc an toàn: không rebase tùy tiện branch public mà người khác đã dựa vào, trừ khi team đã thống nhất workflow đó.

9. Trước khi mở Pull Request, hãy tự review diff của mình

Một Pull Request tốt bắt đầu trước khi bấm nút tạo PR. Trước khi push hoặc mở PR, hãy xem lại toàn bộ thay đổi so với branch chính:

git diff main...HEAD

Xem log ngắn:

git log --oneline --decorate --graph main..HEAD

Nếu thấy branch có nhiều commit kiểu fix, fix again, wip, bạn có thể cân nhắc dọn lại trước khi gửi review. Với branch cá nhân chưa ai dùng chung, có thể dùng interactive rebase:

git rebase -i main

Không phải lúc nào cũng cần squash mọi thứ thành một commit. Nhưng nếu lịch sử commit quá nhiễu, việc dọn lại trước khi review sẽ giúp người khác đọc thay đổi dễ hơn.

10. Pull Request không chỉ là nút merge

Trên GitHub, Pull Request là nơi thảo luận, review, chạy check và ghi lại bối cảnh của thay đổi. Một PR tốt nên có đủ ba phần: thay đổi gì, test thế nào và có điểm nào cần reviewer chú ý.

Bạn có thể dùng template như sau trong file .github/pull_request_template.md:

## What changed

- 

## Why

- 

## How to test

1. 
2. 
3. 

## Screenshots

## Notes for reviewers

Với thay đổi UI, nên có ảnh trước/sau. Với thay đổi backend, nên ghi rõ endpoint, case test, migration hoặc rủi ro tương thích. Với thay đổi hạ tầng, nên ghi rõ cách rollback.

PR càng rõ, reviewer càng ít phải đoán. Khi reviewer ít phải đoán, tốc độ merge thường nhanh hơn và chất lượng review cũng tốt hơn.

11. Dùng Draft Pull Request cho việc đang làm dở

Không phải PR nào cũng cần sẵn sàng review ngay. Nếu bạn muốn chia sẻ hướng làm, xin feedback sớm hoặc để CI chạy trước, hãy dùng Draft Pull Request.

Draft PR phù hợp khi:

Bạn đang làm một thay đổi lớn và muốn team nhìn sớm.
Bạn muốn CI chạy trước khi hoàn thiện.
Bạn cần thảo luận hướng thiết kế trước khi viết tiếp.
Bạn không muốn reviewer hiểu nhầm rằng PR đã sẵn sàng merge.

Thói quen này rất hữu ích với team remote. Thay vì im lặng làm một branch lớn trong nhiều ngày, bạn có thể mở Draft PR sớm để mọi người thấy tiến độ và góp ý đúng lúc.

12. Bảo vệ branch chính bằng protected branches hoặc rulesets

Với repo cá nhân nhỏ, push thẳng lên main có thể tạm chấp nhận. Nhưng với dự án nghiêm túc, nhánh chính nên được bảo vệ.

GitHub hỗ trợ branch protection rules và repository rulesets để kiểm soát cách người dùng tương tác với branch hoặc tag. Với branch quan trọng như main, bạn nên cân nhắc:

Require pull request before merging.
Require approvals.
Require status checks to pass.
Require branches to be up to date before merging nếu phù hợp.
Block force pushes.
Block branch deletion.
Require linear history nếu team muốn lịch sử sạch.

Với repo có nhiều PR merge mỗi ngày, GitHub merge queue cũng đáng cân nhắc. Merge queue giúp tự động xếp hàng các PR đã đủ điều kiện và kiểm tra lại trên trạng thái mới nhất trước khi merge. Điểm cần nhớ là nếu dùng GitHub Actions với merge queue, workflow cần hỗ trợ event merge_group để required checks chạy đúng trong hàng đợi.

Baseline thực tế cho đa số repo nhỏ và vừa:

main:
  - Không push trực tiếp
  - Merge qua Pull Request
  - Ít nhất 1 approval
  - CI phải pass
  - Không cho force push
  - Không cho delete branch

Cách này không làm team chậm đi quá nhiều, nhưng giảm đáng kể rủi ro merge nhầm code lỗi vào branch chính.

13. Đừng để secret đi vào Git history

Một trong những lỗi nguy hiểm nhất khi dùng Git/GitHub là commit nhầm secret. Secret có thể là:

.env chứa API key.
Database URL.
Private key.
Access token.
Webhook secret.
Credential của cloud provider.

Hãy thêm các file nhạy cảm vào .gitignore ngay từ đầu:

.env
.env.local
.env.*.local
*.pem
*.key
id_rsa
id_ed25519

Nhưng .gitignore chỉ giúp tránh commit nhầm trong tương lai. Nếu secret đã từng được commit, chỉ xóa file rồi commit lại là chưa đủ, vì secret vẫn có thể nằm trong Git history. Việc cần làm là rotate hoặc revoke secret đó ngay.

Trên GitHub, nên bật secret scanning và push protection nếu repo hỗ trợ. Push protection giúp chặn secret trước khi nó đi vào repository, thay vì chỉ cảnh báo sau khi secret đã bị lộ.

14. Dùng GitHub security features như một lớp kiểm tra sớm

Năm 2026, một repo GitHub tốt không nên chỉ có code và README. Tối thiểu, bạn nên nhìn vào tab Security và cân nhắc các lớp kiểm tra phù hợp.

14.1. Secret scanning và push protection

Secret scanning giúp phát hiện credential bị lộ trong repository. Push protection giúp ngăn một số secret bị push lên ngay từ đầu. Với project thật, đây là lớp bảo vệ rất đáng bật.

14.2. Dependabot

Dependabot giúp theo dõi dependency và tạo PR cập nhật khi có version mới hoặc bản vá bảo mật. Với JavaScript, Python, PHP, Ruby, Go hoặc Java, đây là cách tốt để không bỏ quên dependency cũ quá lâu.

14.3. Dependency review

Dependency review giúp xem thay đổi dependency trong Pull Request và đánh giá tác động bảo mật. Điều này đặc biệt hữu ích khi PR thêm package mới hoặc nâng version lớn.

14.4. CodeQL code scanning

CodeQL giúp phân tích code để tìm lỗi bảo mật và lỗi chất lượng. GitHub hỗ trợ default setup cho CodeQL để cấu hình nhanh trong nhiều repository, còn advanced setup phù hợp khi bạn cần tùy biến workflow.

Không nên bật mọi thứ một cách mù quáng rồi bỏ đó. Hãy bật từng lớp, hiểu alert nào quan trọng, ai chịu trách nhiệm xử lý và khi nào alert được coi là false positive.

15. Dùng GitHub CLI để giảm thao tác trong trình duyệt

Nếu bạn làm việc nhiều trong terminal, GitHub CLI là công cụ rất đáng dùng. Thay vì mở trình duyệt liên tục, bạn có thể tạo PR, xem PR, checkout PR và kiểm tra trạng thái ngay trong terminal.

gh auth login
gh pr create
gh pr list
gh pr view --web
gh pr checkout 123
gh pr checks
gh issue list

Ví dụ, khi muốn review nhanh PR số 123 trên máy local:

gh pr checkout 123
npm test

Workflow này rất tiện khi bạn cần chạy test local, debug sâu hoặc kiểm tra thay đổi mà giao diện web không đủ.

16. Biết cách tự cứu mình bằng `git restore`, `reset` và `reflog`

Git đáng sợ nhất khi bạn nghĩ mình vừa mất code. Thực tế, nhiều trường hợp vẫn cứu được nếu bạn biết tìm đúng chỗ.

Khôi phục file chưa commit về trạng thái gần nhất trong index hoặc HEAD:

git restore path/to/file

Bỏ file khỏi staging nhưng vẫn giữ thay đổi trong working directory:

git restore --staged path/to/file

Nếu muốn xem lịch sử vị trí HEAD đã đi qua:

git reflog

git reflog là phao cứu sinh trong nhiều tình huống: reset nhầm, rebase lỗi, checkout sai hoặc tưởng rằng commit đã biến mất. Khi tìm được commit cần khôi phục, bạn có thể tạo branch mới từ đó:

git switch -c rescue-branch <commit-hash>

Điểm cần nhớ: khi gặp sự cố Git, đừng vội chạy thêm nhiều lệnh theo cảm tính. Hãy dừng lại, chạy git status, xem git reflog, rồi mới quyết định bước tiếp theo.

17. Dùng `git stash` đúng cách khi đang làm dở

git stash giúp cất tạm thay đổi chưa commit để bạn chuyển việc khác. Ví dụ, bạn đang làm tính năng mới nhưng cần checkout sang branch hotfix:

git stash push -m "wip: payment form validation"
git switch main
git pull
git switch -c fix/hotfix-payment

Xem danh sách stash:

git stash list

Lấy lại stash:

git stash pop

Hoặc apply mà không xóa stash khỏi danh sách:

git stash apply stash@{0}

Không nên dùng stash như kho lưu trữ lâu dài. Nếu thay đổi quan trọng, hãy tạo branch và commit tạm với message rõ ràng. Stash phù hợp cho việc chuyển ngữ cảnh nhanh, không phải để thay thế lịch sử commit.

18. Dùng `git worktree` khi phải làm nhiều branch cùng lúc

Nếu bạn thường xuyên đang làm dở một branch nhưng phải chuyển sang branch khác để sửa bug gấp, git worktree rất đáng học.

git worktree cho phép một repository có nhiều working tree, nghĩa là bạn có thể checkout nhiều branch ở nhiều thư mục khác nhau.

git worktree add ../project-hotfix fix/payment-timeout

Khi đó, thư mục hiện tại vẫn giữ branch đang làm dở, còn thư mục ../project-hotfix chứa branch hotfix. Bạn không cần stash liên tục, không cần checkout qua lại và ít rủi ro làm rối working directory.

Khi làm xong và muốn dọn worktree:

git worktree list
git worktree remove ../project-hotfix

Tính năng này đặc biệt hữu ích cho maintainer, reviewer, DevOps hoặc developer phải xử lý nhiều branch trong ngày.

19. Dùng `git sparse-checkout` cho repo lớn hoặc monorepo

Với repo nhỏ, clone toàn bộ source code không phải vấn đề. Nhưng với monorepo hoặc repo rất lớn, bạn có thể chỉ cần một phần thư mục. git sparse-checkout giúp working tree chỉ chứa subset file hoặc thư mục bạn quan tâm.

Ví dụ:

git sparse-checkout init --cone
git sparse-checkout set apps/web packages/ui

Cách này hữu ích khi bạn chỉ làm frontend trong một monorepo lớn, hoặc chỉ cần một package cụ thể để build/test. Nó giúp thư mục làm việc gọn hơn và giảm nhiễu khi tìm file.

Tuy nhiên, sparse checkout không phải công cụ cần dùng cho mọi repo. Nếu project nhỏ hoặc bạn thường xuyên phải sửa nhiều phần khác nhau, clone đầy đủ vẫn đơn giản hơn.

20. Bật `rerere` nếu bạn thường xuyên gặp conflict lặp lại

rerere là viết tắt của “reuse recorded resolution”. Khi bật tính năng này, Git có thể ghi nhớ cách bạn đã xử lý conflict và tự áp dụng lại nếu gặp conflict tương tự trong tương lai.

Bật global:

git config --global rerere.enabled true

rerere hữu ích khi bạn:

Thường xuyên rebase branch dài ngày.
Maintain nhiều nhánh release.
Gặp conflict lặp lại ở cùng một vùng code.
Làm việc trong repo có nhiều thay đổi song song.

Nếu bạn chỉ dùng Git cơ bản, có thể chưa cần bật ngay. Nhưng với người dùng lâu năm, đây là một tính năng nhỏ nhưng tiết kiệm thời gian đáng kể.

21. Khi nào nên squash, merge commit hoặc rebase merge?

GitHub thường cho repo chọn nhiều kiểu merge Pull Request. Ba kiểu phổ biến là merge commit, squash merge và rebase merge.

21.1. Merge commit

Merge commit giữ lại toàn bộ lịch sử branch và tạo một commit merge. Cách này phù hợp khi team muốn thấy rõ nhánh tính năng được tích hợp vào lúc nào.

21.2. Squash merge

Squash merge gom toàn bộ commit trong PR thành một commit duy nhất trên branch chính. Cách này phù hợp khi branch có nhiều commit nhỏ, commit WIP hoặc lịch sử không cần giữ chi tiết.

21.3. Rebase merge

Rebase merge đưa commit của branch vào branch chính theo lịch sử tuyến tính hơn. Cách này phù hợp với team thích log sạch, nhưng yêu cầu mọi người hiểu rebase tốt hơn.

Không có kiểu merge đúng cho mọi dự án. Với team nhỏ, tôi thường ưu tiên squash merge cho feature branch ngắn để main dễ đọc. Với thư viện, framework hoặc repo cần lịch sử chi tiết, merge commit hoặc rebase merge có thể hợp hơn.

22. Đừng bỏ qua README, .gitignore và CONTRIBUTING

Một repo dễ dùng không chỉ nằm ở code. Ba file nhỏ sau giúp repo chuyên nghiệp hơn rất nhiều:

README.md: giải thích project là gì, chạy thế nào, cấu hình ra sao.
.gitignore: tránh commit file build, dependency, secret hoặc file local.
CONTRIBUTING.md: hướng dẫn cách tạo branch, commit, test và mở PR.

Với project có nhiều người tham gia, nên thêm cả:

.github/pull_request_template.md
.github/ISSUE_TEMPLATE/
CODEOWNERS nếu cần tự động request reviewer theo khu vực code.

Những file này không làm code chạy nhanh hơn, nhưng làm team chạy mượt hơn.

23. Một workflow Git/GitHub thực tế cho team nhỏ

Nếu bạn chưa có workflow rõ ràng, có thể bắt đầu với baseline sau:

1. Luôn tạo branch từ main mới nhất
2. Commit nhỏ, message rõ
3. Push branch lên GitHub
4. Mở Draft PR nếu chưa xong
5. Khi sẵn sàng, chuyển PR sang Ready for review
6. CI phải pass
7. Ít nhất 1 người review
8. Squash merge hoặc merge theo quy ước team
9. Xóa branch sau khi merge

Lệnh mẫu:

git switch main
git pull --ff-only
git switch -c feat/user-profile

# sửa code
git status
git add -p
git commit -m "feat: add user profile page"

git push -u origin feat/user-profile
gh pr create --draft

Với team nhỏ, workflow càng rõ càng tốt. Đừng thiết kế quy trình quá nặng ngay từ đầu, nhưng cũng đừng để mọi người push thẳng lên main rồi hy vọng không ai làm hỏng production.

24. Lỗi thường gặp khi dùng Git/GitHub và cách tránh

24.1. Commit quá nhiều thứ không liên quan

Hãy dùng git add -p và chia commit theo ý định thay đổi.

24.2. Pull code mà không biết đang merge hay rebase

Hãy hiểu rõ team đang dùng workflow nào. Nếu cần an toàn, dùng git fetch trước để quan sát.

24.3. Push secret lên GitHub

Luôn có .gitignore, dùng file .env.example thay vì commit .env, bật secret scanning/push protection nếu có thể.

24.4. Force push lên branch dùng chung

Force push có thể phá lịch sử của người khác. Chỉ dùng khi hiểu rõ tác động và ưu tiên --force-with-lease thay vì --force.

git push --force-with-lease

24.5. Không đọc diff trước khi mở PR

Trước khi PR, hãy chạy git diff main...HEAD. Đây là bước đơn giản nhưng giúp phát hiện rất nhiều lỗi ngớ ngẩn.

24.6. Để PR quá lớn

PR càng lớn, review càng chậm. Nếu có thể, hãy tách thành nhiều PR nhỏ theo từng bước: chuẩn bị refactor, thêm API, thêm UI, bật feature flag.

24.7. Không có rule bảo vệ branch chính

Với repo nghiêm túc, main nên có branch protection hoặc ruleset. Không nên phụ thuộc hoàn toàn vào trí nhớ của từng người.

25. Checklist Git/GitHub nên áp dụng trong năm 2026

Nếu muốn nâng cấp workflow nhanh, bạn có thể bắt đầu với checklist này.

Ở máy local:

Cấu hình đúng user.name và user.email.
Luôn xem git status trước khi commit.
Dùng git diff và git diff --staged.
Dùng git add -p khi sửa nhiều thứ trong cùng một file.
Biết dùng git restore, git stash và git reflog.
Dùng git worktree nếu thường xuyên làm nhiều branch cùng lúc.

Ở GitHub:

Không push trực tiếp lên main với repo quan trọng.
Dùng Pull Request template.
Bật required status checks cho CI.
Bật branch protection hoặc repository rulesets.
Bật secret scanning và push protection nếu repo hỗ trợ.
Dùng Dependabot hoặc quy trình cập nhật dependency rõ ràng.
Cân nhắc CodeQL cho repo có yêu cầu bảo mật cao.
Dùng merge queue nếu branch chính có nhiều PR merge liên tục.

26. FAQ

26.1. Người mới nên học Git hay GitHub trước?

Nên học Git trước ở mức cơ bản: status, add, commit, branch, switch, merge, restore và log. Sau đó học GitHub để hiểu remote, Pull Request, review, issue, Actions và bảo mật repo. Git là nền tảng, GitHub là nền cộng tác xung quanh Git.

26.2. Có nên dùng GUI Git không?

Có thể dùng. GitHub Desktop, VS Code Source Control, JetBrains Git UI hoặc các Git client khác đều hữu ích. Tuy nhiên, bạn vẫn nên hiểu CLI cơ bản vì khi lỗi xảy ra, CLI thường giúp debug rõ hơn.

26.3. Có nên commit trực tiếp lên main không?

Với repo học tập cá nhân thì được. Với repo production, repo team hoặc repo có CI/CD deploy tự động, không nên. Hãy dùng branch, Pull Request và branch protection.

26.4. Nên dùng merge hay rebase?

Tùy quy ước team. Merge dễ hiểu và giữ lịch sử phân nhánh. Rebase giúp lịch sử tuyến tính hơn nhưng cần dùng cẩn thận, nhất là với branch đã public. Điều quan trọng là team thống nhất một cách làm.

26.5. Lỡ commit nhầm secret rồi xóa ở commit sau có an toàn chưa?

Chưa. Secret có thể vẫn còn trong Git history. Việc cần làm là revoke hoặc rotate secret đó ngay, sau đó mới xử lý lịch sử repo nếu cần.

26.6. Khi nào nên dùng `git worktree`?

Khi bạn thường xuyên phải chuyển giữa nhiều branch, review PR local, sửa hotfix gấp hoặc maintain nhiều nhánh release. git worktree giúp mỗi branch có thư mục làm việc riêng, giảm nhu cầu stash qua lại.

26.7. Khi nào nên dùng `git sparse-checkout`?

Khi repo quá lớn và bạn chỉ cần làm việc với một vài thư mục. Với repo nhỏ hoặc project đơn giản, sparse checkout có thể không cần thiết.

27. Kết luận

Git/GitHub không khó vì thiếu lệnh, mà khó vì người dùng không có workflow rõ ràng. Khi mới bắt đầu, hãy tập trung vào trạng thái, diff, staging và commit message. Khi làm việc nhóm, hãy tập trung vào branch, Pull Request, review và CI. Khi dự án lớn hơn, hãy bổ sung branch protection, rulesets, security scanning, dependency review, worktree, sparse checkout và các công cụ tự động hóa phù hợp.

Một repo tốt không chỉ là repo chạy được. Một repo tốt là repo mà người khác có thể đọc lịch sử, hiểu thay đổi, review an toàn, rollback khi cần và tiếp tục phát triển mà không phải đoán quá nhiều.

Nói ngắn gọn: Git là nhật ký kỹ thuật của dự án. Viết nhật ký đó rõ ràng, bạn của vài tháng sau sẽ cảm ơn bạn.

Nguồn tham khảo chính thức nên đọc thêm

Bài viết khác

Cách đăng ký lịch âm trên iPhone bằng link ICS mới nhất 2026

Tác giả

Tuấn Lê

Tại DevNook, mình chia sẻ kiến thức thực chiến, kinh nghiệm làm sản phẩm và những công cụ hữu ích giúp bạn làm việc hiệu quả hơn mỗi ngày.

27 bài đã xuất bản Xem trang tác giả