Git là công cụ quản lý phiên bản mã nguồn, giúp nhiều lập trình viên cùng làm việc trên một dự án mà không ghi đè lên nhau. Với thực tập sinh IT, biết Git gần như là yêu cầu bắt buộc: ngày đầu đi làm bạn sẽ được giao một repo, một nhánh và phải biết commit, push, tạo pull request để code của mình được review và gộp vào dự án chung. Bài viết này tóm gọn 15 lệnh Git bạn dùng hằng ngày và quy trình làm việc nhóm chuẩn, đủ để bạn tự tin trong tuần đầu thực tập.
Cập nhật theo Git phiên bản 2.54 (4/2026). Bài dùng các lệnh hiện đại git switch và git restore — rõ ràng và an toàn hơn cho người mới so với git checkout kiểu cũ.
Nội dung
- Mục lục
- 1. Vì sao thực tập sinh IT bắt buộc phải biết Git
- 2. Các khái niệm cốt lõi: repo, commit, branch, remote
- 3. 15 lệnh Git dùng hằng ngày (kèm ví dụ)
- 4. Quy trình làm việc nhóm: branch → commit → push → pull request → merge
- 5. 6 lỗi Git thường gặp của intern và cách xử lý
- 6. Bài tập thực hành 30 phút
- 7. Câu hỏi thường gặp (FAQ)
- Sẵn sàng đi thực tập IT cùng mentor kèm 1:1?
Mục lục
- 1. Vì sao thực tập sinh IT bắt buộc phải biết Git
- 2. Các khái niệm cốt lõi: repo, commit, branch, remote
- 3. 15 lệnh Git dùng hằng ngày (kèm ví dụ)
- 4. Quy trình làm việc nhóm: branch → commit → push → pull request → merge
- 5. 6 lỗi Git thường gặp của intern và cách xử lý
- 6. Bài tập thực hành 30 phút
- 7. Câu hỏi thường gặp (FAQ)
1. Vì sao thực tập sinh IT bắt buộc phải biết Git
Ở trường, bạn thường code một mình và lưu file trên máy. Ở công ty, hàng chục người cùng sửa một dự án mỗi ngày. Git là thứ giúp tất cả phối hợp được mà không giẫm chân nhau. Cụ thể, biết Git mang lại cho bạn:
- Làm việc nhóm không ghi đè code của nhau. Mỗi người làm trên nhánh riêng rồi gộp lại có kiểm soát.
- Lưu lịch sử và quay lui an toàn. Lỡ làm hỏng, bạn quay lại bản chạy được trước đó trong vài giây.
- Được review code. Pull request là nơi mentor đọc, góp ý và duyệt code của bạn — cách học nhanh nhất khi thực tập.
- Là kỹ năng nhà tuyển dụng mặc định bạn có. Hầu hết tin tuyển intern đều ghi “biết Git/GitHub cơ bản”.
Tin tốt: bạn không cần học hết Git. Khoảng 15 lệnh dưới đây bao phủ 90% công việc hằng ngày.
2. Các khái niệm cốt lõi: repo, commit, branch, remote
Hiểu 5 khái niệm này trước thì các lệnh phía sau sẽ rất dễ nhớ:
- Repository (repo): thư mục dự án được Git theo dõi, chứa toàn bộ code và lịch sử thay đổi.
- Commit: một “bản chụp” các thay đổi tại một thời điểm, kèm dòng mô tả. Hãy coi mỗi commit là một mốc lưu trong game.
- Branch (nhánh): một dòng phát triển độc lập. Bạn tạo nhánh riêng để làm tính năng mà không ảnh hưởng nhánh chính.
- main: nhánh chính, chứa code ổn định. Đây là tên mặc định trên GitHub hiện nay (trước kia gọi là master).
- Remote (origin): bản repo trên máy chủ (GitHub/GitLab).
originlà tên mặc định trỏ tới nơi bạn clone về.
Một thay đổi đi qua 3 vùng: thư mục làm việc (bạn sửa file) → staging (đã git add) → repo (đã git commit). Hiểu 3 vùng này, bạn sẽ không bao giờ bối rối khi đọc git status.
3. 15 lệnh Git dùng hằng ngày (kèm ví dụ)
Bảng tra nhanh dưới đây là 15 lệnh bạn sẽ gõ gần như mỗi ngày. Phần sau giải thích kỹ từng lệnh kèm ví dụ thật.
| Lệnh | Công dụng |
|---|---|
git clone <url> |
Tải toàn bộ repo từ máy chủ (GitHub/GitLab) về máy bạn lần đầu. |
git status |
Xem file nào đã đổi, đang staged hay chưa — chạy thường xuyên nhất. |
git add <file> |
Đưa file vào vùng staging để chuẩn bị commit (git add . để thêm tất cả). |
git commit -m "..." |
Lưu một bản ghi (snapshot) các thay đổi đã staged kèm mô tả. |
git push |
Đẩy commit từ máy bạn lên repo trên máy chủ để chia sẻ với team. |
git pull |
Kéo và gộp các thay đổi mới nhất từ máy chủ về nhánh hiện tại. |
git fetch |
Tải dữ liệu mới về nhưng CHƯA gộp — để xem trước rồi mới merge. |
git switch <nhánh> |
Chuyển sang nhánh khác (cách mới, thay cho git checkout). |
git switch -c <nhánh> |
Tạo nhánh mới và chuyển sang nó ngay. |
git branch |
Liệt kê các nhánh; biết mình đang đứng ở nhánh nào. |
git merge <nhánh> |
Gộp thay đổi từ một nhánh khác vào nhánh hiện tại. |
git log --oneline |
Xem lịch sử commit gọn gàng, mỗi commit một dòng. |
git diff |
So sánh nội dung đã đổi so với bản trước đó. |
git restore <file> |
Hoàn tác thay đổi chưa commit của một file (cách mới, thay git checkout). |
git stash |
Cất tạm thay đổi đang dở để chuyển việc, sau lấy lại bằng git stash pop. |
Nhóm 1 — Bắt đầu & kiểm tra trạng thái
git clone — Lần đầu nhận dự án, bạn copy link repo trên GitHub rồi tải về máy:
git clone https://github.com/cong-ty/du-an.git
git status — Lệnh bạn gõ nhiều nhất. Nó cho biết file nào đang sửa, file nào đã staged, đang ở nhánh nào. Khi phân vân “giờ làm gì tiếp”, cứ gõ git status.
git log --oneline — Xem lịch sử commit gọn, mỗi commit một dòng. Thêm --graph để thấy sơ đồ nhánh.
Nhóm 2 — Lưu thay đổi (add → commit)
git add — Chọn file để đưa vào commit. Dùng git add . để thêm tất cả thay đổi, hoặc chỉ định từng file để commit gọn gàng:
git add index.html style.css
git commit -m "..." — Lưu lại các thay đổi đã staged. Viết mô tả ngắn, rõ, ở thì hiện tại:
git commit -m "Them form dang ky va kiem tra email"
git diff — Xem chính xác bạn đã đổi những dòng nào trước khi commit. Rất hữu ích để tránh commit nhầm.
Nhóm 3 — Đồng bộ với team (push / pull / fetch)
git push — Đẩy commit của bạn lên GitHub. Lần đầu đẩy một nhánh mới, Git có thể yêu cầu:
git push -u origin ten-nhanh-cua-ban
git pull — Kéo code mới nhất của team về và gộp vào nhánh hiện tại. Hãy pull mỗi sáng trước khi bắt đầu làm để tránh xung đột.
git fetch — Giống pull nhưng chỉ tải về, chưa gộp. Dùng khi bạn muốn xem có gì mới trước rồi mới quyết định merge.
Nhóm 4 — Làm việc với nhánh (branch / switch / merge)
git branch — Liệt kê các nhánh; nhánh đang đứng có dấu *.
git switch -c — Tạo nhánh mới và chuyển sang ngay. Luôn tạo nhánh riêng cho mỗi tính năng:
git switch -c feature/dang-nhap
git switch — Chuyển qua lại giữa các nhánh đã có:
git switch main
(Bạn có thể thấy đồng nghiệp dùng git checkout cho việc này — đó là cách cũ, vẫn chạy được. Từ Git 2.23, switch/restore được khuyến nghị vì rõ ràng và ít gây nhầm lẫn hơn.)
git merge — Gộp một nhánh vào nhánh hiện tại. Ví dụ đang ở main và muốn lấy code từ nhánh tính năng:
git switch main
git merge feature/dang-nhap
Nhóm 5 — Cứu nguy (restore / stash)
git restore — Hoàn tác thay đổi CHƯA commit của một file, trả nó về như bản gần nhất:
git restore style.css
git stash — Đang làm dở mà cần chuyển sang việc gấp khác? Cất tạm thay đổi đi cho sạch, xong việc thì lấy lại:
git stash # cat tam
git stash pop # lay lai
4. Quy trình làm việc nhóm: branch → commit → push → pull request → merge
Đây là quy trình chuẩn (gọi là feature branch workflow) mà gần như mọi công ty đang dùng. Nắm 6 bước này là bạn làm việc được trong dự án thật:
- Cập nhật main mới nhất:
git switch mainrồigit pull. - Tạo nhánh riêng cho việc của bạn:
git switch -c feature/ten-tinh-nang. - Làm việc và commit nhiều lần nhỏ:
git add→git commit, mỗi commit là một bước hoàn chỉnh. - Đẩy nhánh lên GitHub:
git push -u origin feature/ten-tinh-nang. - Mở Pull Request (PR): vào GitHub, bấm “Compare & pull request”, mô tả bạn đã làm gì, gắn mentor vào review.
- Sửa theo góp ý rồi merge: mentor duyệt xong, PR được merge vào main. Sau đó xóa nhánh tính năng cho gọn.
Pull request là gì? Là một đề nghị “xin gộp code của tôi vào nhánh chính”, kèm chỗ để mọi người đọc, bình luận từng dòng và duyệt. Với intern, đây chính là nơi bạn được mentor kèm cặp và học nhanh nhất.
5. 6 lỗi Git thường gặp của intern và cách xử lý
1. Commit nhầm vào nhánh main. Quên tạo nhánh nên commit thẳng vào main. Cách tránh: luôn git status xem mình đang ở nhánh nào trước khi commit. Lỡ rồi thì nhờ mentor hướng dẫn chuyển commit sang nhánh đúng.
2. Quên git pull đầu ngày → xung đột (conflict). Code của bạn và đồng đội đụng nhau. Đừng hoảng: Git đánh dấu chỗ xung đột bằng <<<<<<<, =======, >>>>>>>; bạn chọn giữ phần nào, xóa dấu, rồi git add và commit lại.
3. Commit message mơ hồ như “update”, “fix”. Viết rõ làm gì: “Sua loi validate so dien thoai”. Sau này dò lịch sử dễ hơn nhiều.
4. Lỡ commit file không nên đẩy (mật khẩu, node_modules, file .env). Tạo file .gitignore để Git bỏ qua chúng.
5. “Làm hỏng hết rồi!” Hầu hết thao tác Git đều khôi phục được. Trước khi tự sửa liều, hãy dừng lại và hỏi mentor — đừng git push -f khi chưa hiểu nó làm gì.
6. Gõ git checkout rồi mất thay đổi. Đây là lý do bài này khuyên dùng git switch (đổi nhánh) và git restore (hoàn tác file) cho rạch ròi, tránh nhầm lẫn.
6. Bài tập thực hành 30 phút
Tự làm bài tập nhỏ này một lần là bạn nhớ được toàn bộ quy trình. Cần một tài khoản GitHub miễn phí:
- Tạo một repo mới trên GitHub tên
git-thuc-hanh, tick “Add a README”. - Clone về máy:
git clone <link-repo>. - Tạo nhánh:
git switch -c feature/gioi-thieu. - Sửa file README, viết vài dòng giới thiệu bản thân.
- Lưu lại:
git add README.mdrồigit commit -m "Them gioi thieu ban than". - Đẩy lên:
git push -u origin feature/gioi-thieu. - Lên GitHub mở Pull Request, rồi tự merge vào main. Xong — bạn vừa chạy đủ quy trình thật!
7. Câu hỏi thường gặp (FAQ)
Thực tập sinh IT có bắt buộc phải biết Git không?
Gần như bắt buộc. Hầu hết công ty quản lý code bằng Git và yêu cầu intern commit, push, tạo pull request ngay từ tuần đầu. Bạn không cần giỏi, chỉ cần nắm khoảng 15 lệnh cơ bản và quy trình branch → commit → push → pull request → merge.
Học Git mất bao lâu để đủ đi thực tập?
Nếu tập trung, bạn có thể nắm phần cơ bản trong 1–2 ngày và thành thạo sau khoảng 1–2 tuần dùng thật. Cách nhanh nhất là thực hành trên một repo cá nhân: tạo nhánh, commit, push và mở pull request vài lần.
Git và GitHub khác nhau thế nào?
Git là công cụ quản lý phiên bản chạy trên máy bạn. GitHub là dịch vụ trực tuyến để lưu repo Git và cộng tác (pull request, review, issue). Hiểu đơn giản: Git là phần mềm, GitHub là nơi chứa code chung và làm việc nhóm. GitLab, Bitbucket là các dịch vụ tương tự.
Nên dùng git switch hay git checkout?
Với người mới, nên dùng git switch để đổi nhánh và git restore để hoàn tác file. Đây là cách hiện đại (từ Git 2.23) và an toàn hơn vì rạch ròi chức năng. git checkout vẫn chạy được nhưng dễ gây nhầm lẫn vì nó làm cả hai việc.
Lỡ làm hỏng repo hoặc commit nhầm thì sao?
Phần lớn thao tác Git đều khôi phục được nhờ lịch sử commit. Nếu chưa push, bạn thường sửa được tại chỗ; nếu đã push, đừng tự dùng các lệnh xóa lịch sử (như git push -f) khi chưa hiểu — hãy hỏi mentor để xử lý an toàn.
Conflict (xung đột) là gì và xử lý ra sao?
Conflict xảy ra khi hai người sửa cùng một đoạn code. Git đánh dấu vùng xung đột bằng các ký hiệu chèn vào file; bạn mở file, chọn giữ phần đúng, xóa các dấu đánh dấu, rồi git add và commit lại. Pull code mới mỗi ngày sẽ giúp giảm xung đột.
Sẵn sàng đi thực tập IT cùng mentor kèm 1:1?
Biết Git mới là bước khởi đầu. Tại CodeGym Đà Nẵng, thực tập sinh IT được mentor hướng dẫn 1:1, làm dự án thật theo đúng quy trình Git và Agile/Scrum như trong doanh nghiệp — đúng môi trường bạn vừa đọc trong bài này. Để lại thông tin để được tư vấn lộ trình phù hợp với năm học của bạn.
→ Đăng ký tư vấn chương trình thực tập IT có coaching
Đọc thêm trong chuỗi bài thực tập IT:

0 Lời bình