[Javascript Typescript] Bài 6 - Sổ tay Git Cơ bản cho người mới

[Javascript Typescript] Bài 6 - Sổ tay Git Cơ bản cho người mới



NỘI DUNG BÀI HỌC

✅ Git là gì? (Git CSM)
✅ Ưu điểm của Git
✅ Dịch vụ Git (GitHub)
✅ Các bước cài đặt để sử dụng được Git trên Windows

Phần 1: Bức tranh toàn cảnh - Tại sao Git tồn tại?

1.1. Vấn đề của việc quản lý phiên bản

Hãy tưởng tượng bạn đang viết một tài liệu quan trọng. Quy trình của bạn có thể trông như thế này:

  • tailieu_v1.docx
  • tailieu_v2_sua_loi.docx
  • tailieu_final.docx
  • tailieu_final_that_su_nhe.docx 😭

Cách làm này rất lộn xộn. Git ra đời để giải quyết chính xác vấn đề này, hoạt động như một "cỗ máy thời gian" cho mã nguồn của bạn.

1.2. Phép ẩn dụ cốt lõi: Dự án kiến trúc

Để hiểu Git, hãy tưởng tượng bạn là một kiến trúc sư làm việc trong một dự án thiết kế tòa nhà lớn. Toàn bộ dự án này là Repository (Kho chứa) của bạn.

  • Local Repository (Kho chứa cục bộ): Đây là văn phòng làm việc cá nhân của bạn, đặt trên máy tính của bạn.
  • Remote Repository (Kho chứa từ xa): Đây là thư viện trung tâm của công ty (ví dụ: trên GitHub), nơi lưu trữ bản thiết kế chính thức và là nơi mọi người chia sẻ công việc.


Phần 2: Văn phòng của bạn - Làm chủ quy trình làm việc cá nhân

Bên trong "văn phòng" (Local Repository) của bạn, có ba khu vực làm việc chính. Hiểu rõ ba khu vực này là chìa khóa để làm chủ Git.

2.1. Ba khu vực làm việc thần thánh (với ví dụ)

Hãy thực hành với một kịch bản nhỏ:

Khởi tạo dự án:
mkdir my-project
cd my-project
git init
# Kết quả: Initialized empty Git repository in /path/to/my-project/.git/

 

Bạn vừa "xây dựng" một văn phòng mới. Giờ hãy tạo 2 file bản vẽ.
 
echo "<h1>Homepage</h1>" > index.html

echo "body { color: blue; }" > style.css

 

Working Directory (Bàn làm việc):
Bạn vừa tạo ra 2 file. Chúng đang nằm trên "bàn làm việc". Hãy kiểm tra trạng thái.
git status

# Kết quả:

# On branch master

# No commits yet

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)

#         index.html

#         style.css
Git báo rằng có 2 file "Untracked" (chưa được theo dõi), tức là chúng hoàn toàn mới và Git chưa biết phải làm gì với chúng.

Staging Area (Bàn trình duyệt):
Bây giờ, hãy đưa index.html vào "bàn trình duyệt" để chuẩn bị lưu.

git add index.html

git status

# Kết quả:

# On branch master

# No commits yet

# Changes to be committed:

#   (use "git rm --cached <file>..." to unstage)

#         new file:   index.html

#

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)

#         style.css​

Bạn thấy không? index.html đã sẵn sàng để commit (staged), trong khi style.css vẫn còn trên bàn làm việc (untracked). Đây chính là sức mạnh của Staging Area: cho phép bạn chọn lựa thay đổi nào sẽ đi vào lần lưu tiếp theo.

Repository (.git) (Tủ hồ sơ lưu trữ):
Bây giờ hãy "đóng dấu" và cất bản vẽ index.html vào tủ hồ sơ.

git commit -m "Add initial HTML for homepage"

# Kết quả:

# [master (root-commit) a1b2c3d] Add initial HTML for homepage

#  1 file changed, 1 insertion(+)

#  create mode 100644 index.html
Bây giờ kiểm tra lại trạng thái.

git status

# Kết quả:

# On branch master

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)

#         style.css​

 

Hoàn hảo! index.html đã được lưu an toàn vào lịch sử. Chỉ còn style.css đang chờ xử lý.


2.2. Quy trình làm việc tại Local (với git log)

Hãy hoàn thành nốt công việc.

 

git add style.css

git commit -m "Add basic styling for body"

 

Bây giờ, hãy dùng git log để mở "sổ ghi chép" của tủ hồ sơ.

git log

# Kết quả sẽ trông giống thế này:

# commit b4d5e6f... (HEAD -> master)

# Author: Tên Của Bạn <email@example.com>

# Date:   Fri Sep 19 23:30:00 2025 +0700

#

#     Add basic styling for body

#

# commit a1b2c3d...

# Author: Tên Của Bạn <email@example.com>

# Date:   Fri Sep 19 23:25:00 2025 +0700

#

#     Add initial HTML for homepage

 

Để xem log gọn hơn:

git log --oneline

# Kết quả:

# b4d5e6f (HEAD -> master) Add basic styling for body

# a1b2c3d Add initial HTML for homepage

 

Phần 3: Thư viện trung tâm - Làm việc nhóm hiệu quả

Công việc của bạn ở "văn phòng local" sẽ chỉ thực sự có ý nghĩa khi bạn chia sẻ và hợp tác với người khác. Đây là lúc "thư viện trung tâm" - Remote Repository - phát huy tác dụng.

 

3.1. Remote Repository là gì?

Hãy nghĩ về nó như một kho chứa trung tâm đặt trên một máy chủ (như GitHub, GitLab, Bitbucket). Đây là "nguồn chân lý" (source of truth) mà cả nhóm của bạn cùng nhìn vào.

  • Mục đích chính: Hợp tác, sao lưu và đồng bộ hóa code.

  • Tên gọi tắt (Nickname): Để tiện làm việc, Git sử dụng các tên gọi tắt cho các địa chỉ URL dài của remote. Tên mặc định và phổ biến nhất là origin.

 

3.2. Kết nối và kiểm tra Remote

Cách phổ biến nhất để bắt đầu là git clone một dự án đã có sẵn. Lệnh này không chỉ tải code về mà còn tự động thiết lập kết nối đến remote với tên là origin.

Để kiểm tra các kết nối remote hiện có, bạn dùng lệnh git remote -v.

git remote -v

Kết quả bạn sẽ thấy và ý nghĩa của nó:

origin  https://github.com/your-user/your-repo.git (fetch)
origin  https://github.com/your-user/your-repo.git (push)

  • origin 🏷️: Đây là tên gọi tắt mặc định cho URL của kho chứa từ xa. Nó giống như một cái tên trong danh bạ thay cho một số điện thoại dài.

  • https://...: Đây là địa chỉ URL đầy đủ của kho chứa trên server.

  • (fetch) 📥: Xác định địa chỉ này được dùng để lấy (tải) dữ liệu về khi bạn chạy git pull hoặc git fetch.

  • (push) 📤: Xác định địa chỉ này được dùng để đẩy (tải) dữ liệu lên khi bạn chạy git push.


3.3. Quy trình làm việc nhóm hàng ngày

Quy trình này xoay quanh hai hành động chính: đẩy công việc của bạn lên và kéo công việc của người khác về.

A. Đẩy thay đổi lên (Sharing Your Work with git push)

Sau khi đã có những commit mới ở local, bạn cần chia sẻ chúng với nhóm.

Khi đẩy một nhánh mới lần đầu tiên:

Bạn cần dùng thêm cờ -u (hoặc --set-upstream) để tạo một "liên kết theo dõi" giữa nhánh ở máy bạn và nhánh mới trên remote.

# Giả sử bạn đang ở nhánh feature/login
git push -u origin feature/login

Phân tích kết quả in ra từ terminal:

Total 0 (delta 0), reused 0 (delta 0)
remote: ... (các thông báo từ server)
remote: Create a pull request for 'feature/login' on GitHub by visiting:
remote:   https://github.com/your-user/your-repo/pull/new/feature/login
* [new branch]      feature/login -> feature/login
Branch 'feature/login' set up to track remote branch 'feature/login' from 'origin'.

  • * [new branch] feature/login -> feature/login: Dòng này thông báo một nhánh mới đã được tạo trên remote. Nó có nghĩa: "Nhánh local feature/login (bên trái ->) đã được đẩy lên để tạo ra nhánh remote feature/login (bên phải ->)".

  • Branch 'feature/login' set up to track...: Đây là thông báo quan trọng nhất, là kết quả của cờ -u. Nó xác nhận rằng Git đã tạo một liên kết vĩnh viễn. Nhờ đó, lần sau khi ở nhánh này, bạn chỉ cần gõ git push là đủ.

B. Cập nhật thay đổi (Getting Updates with git pull)

Trước khi bắt đầu code hoặc sau một thời gian, bạn nên cập nhật "văn phòng" của mình với những gì mới nhất từ "thư viện trung tâm".

# Đảm bảo bạn đang ở nhánh chính
git checkout main

# Kéo các cập nhật mới nhất về
git pull origin main

Lệnh git pull thực chất là sự kết hợp của hai bước: git fetch (tải các thay đổi về nhưng chưa áp dụng) và git merge (trộn các thay đổi đó vào nhánh của bạn).


3.4. Kịch bản làm việc nhóm thực tế (An & Bình)

Hãy xem cách các lệnh này hoạt động trong một kịch bản hoàn chỉnh.

Bắt đầu: An và Bình cùng chạy git clone để có "văn phòng" riêng của mình. Cả hai đều có một remote tên là origin.

An làm việc: An muốn làm tính năng đăng nhập.

git checkout -b feature/login  # Tạo nhánh mới
# ... An code và tạo các commit ...
git commit -m "Add login form UI"


An chia sẻ: An đẩy nhánh của mình lên GitHub lần đầu tiên.

git push -u origin feature/login

Bây giờ, mọi người trong nhóm có thể thấy nhánh feature/login trên GitHub.

Bình làm việc: Trong lúc đó, Bình sửa một lỗi nhỏ trên nhánh main và đẩy lên.

git checkout main
# ... Bình sửa lỗi và commit ...
git commit -m "Fix typo on homepage"
git push origin main

Bây giờ, nhánh main trên remote đã được cập nhật.

An cập nhật: Trước khi tiếp tục công việc, An muốn đồng bộ nhánh main của mình với remote.

git checkout main          # Chuyển về nhánh main
git pull origin main       # Kéo bản sửa lỗi của Bình về

Bây giờ, nhánh main trên máy An đã được cập nhật. Anh ấy có thể quay lại nhánh của mình (git checkout feature/login) để làm việc tiếp.

Tích hợp: Sau khi An hoàn thành, nhánh feature/login được merge vào main trên GitHub (thường thông qua một Pull Request).

Đồng bộ hóa cuối cùng: Bây giờ, cả An và Bình đều cần cập nhật nhánh main của họ để nhận được tính năng đăng nhập mới.

git checkout main
git pull origin main
Quy trình này đảm bảo mọi người luôn làm việc với phiên bản code mới nhất và các thay đổi được tích hợp một cách có hệ thống.


3.5: Tích hợp Code qua Pull Request (Trái tim của sự hợp tác)

Dòng "nhánh feature/login được merge vào main trên GitHub" không chỉ đơn giản là một lệnh git merge. Trong thực tế, nó là một quy trình có kiểm soát, thảo luận và đánh giá, được gọi là Pull Request (hoặc Merge Request trên GitLab).

Pull Request (PR) là gì?

Một Pull Request là một yêu cầu chính thức để hợp nhất code từ một nhánh này (ví dụ: feature/login của An) vào một nhánh khác (thường là nhánh main).

Hãy quay lại phép ẩn dụ về kiến trúc sư:

  • Nhánh feature/login của An giống như một bộ bản vẽ chi tiết cho hệ thống lối vào tòa nhà.

  • Thay vì An tự ý thêm bản vẽ của mình vào bộ bản vẽ tổng thể (nhánh main), anh ấy gửi một "Yêu cầu xét duyệt" (Pull Request) đến hội đồng kiến trúc sư (các thành viên khác trong nhóm).

Tại sao phải dùng Pull Request?

Việc này mang lại 4 lợi ích khổng lồ so với việc merge trực tiếp:

  • Đánh giá Code (Code Review) 👀: Các thành viên khác (ví dụ: Bình) có thể xem xét từng dòng code mà An đã viết. Họ có thể để lại bình luận, đặt câu hỏi ("Tại sao bạn dùng cách này?"), hoặc đề xuất cải tiến ("Chỗ này có thể viết gọn hơn"). Việc này giúp nâng cao chất lượng code và phát hiện lỗi sớm.

  • Thảo luận (Discussion) 💬: PR tạo ra một không gian để cả nhóm thảo luận về các thay đổi. Điều này đảm bảo mọi người đều hiểu những gì đang được thêm vào dự án.

  • Kiểm tra tự động (Automated Checks) ✅: Các dự án hiện đại thường tích hợp các công cụ kiểm thử tự động (CI/CD). Khi An mở một PR, hệ thống sẽ tự động chạy các bài test để đảm bảo code mới của anh ấy không làm hỏng các tính năng hiện có. Nếu tất cả các test đều qua, một dấu tích màu xanh sẽ xuất hiện.

  • Lịch sử rõ ràng (Clear History) 📝: Lịch sử của dự án không chỉ là một chuỗi các commit, mà còn là lịch sử của các PR. Mọi người có thể xem lại ai đã đề xuất thay đổi, ai đã review, và các cuộc thảo luận liên quan.

Quy trình một Pull Request trên GitHub

Đây là các bước mà An và Bình sẽ thực hiện:

  • Đẩy nhánh lên GitHub: An đã hoàn thành công việc trên nhánh feature/login và đã đẩy nó lên remote (git push -u origin feature/login).

  • Mở Pull Request: An truy cập trang GitHub của dự án. GitHub sẽ hiển thị một thông báo nổi bật: "feature/login had recent pushes. Compare & pull request". An nhấp vào nút đó.

  • Điền thông tin PR: An sẽ điền vào một form:

    • Tiêu đề: "Feature: Add User Login System"

    • Mô tả: An sẽ giải thích những gì anh ấy đã làm, tại sao, và có thể hướng dẫn cách để người khác kiểm tra tính năng này. Anh ấy sẽ @Binh để yêu cầu Bình review code.

  • Review và phản hồi:

    • Bình nhận được thông báo. Anh ấy vào trang PR, xem các thay đổi trong tab "Files Changed".

    • Bình thấy một lỗi logic nhỏ và để lại một bình luận ngay trên dòng code đó: "Chỗ này cần kiểm tra xem người dùng có tồn tại không trước khi xác thực mật khẩu."

  • Cập nhật và Push lại:

    • An thấy bình luận của Bình. Anh ấy sửa code trên máy local của mình trong nhánh feature/login, tạo một commit mới: git commit -m "Fix: Add user existence check".

    • An chỉ cần git push một lần nữa. Pull Request trên GitHub sẽ tự động cập nhật với commit mới nhất.

  • Phê duyệt và Hợp nhất (Approve & Merge):

    • Bình xem lại thay đổi mới của An và thấy mọi thứ đã ổn. Anh ấy nhấn vào "Approve".

    • Khi PR đã được phê duyệt (và các bài test tự động đã qua), người có quyền (hoặc chính An) sẽ nhấn nút màu xanh lá "Merge pull request".

  • Hoàn tất: GitHub sẽ thực hiện thao tác merge trên server, đưa tất cả các commit từ feature/login vào lịch sử của nhánh main. Nhánh main trên remote bây giờ đã có tính năng đăng nhập.

Sau khi Merge thì sao?

  • Dọn dẹp nhánh 🗑️: Nhánh feature/login đã hoàn thành sứ mệnh của nó. GitHub sẽ đề xuất một nút "Delete branch" để xóa nó trên remote. An cũng nên xóa nó ở local: git branch -d feature/login.

  • Đồng bộ hóa 🔄: Bây giờ, nhánh main trên remote đã đi trước nhánh main trên máy của tất cả mọi người. Việc cuối cùng mà tất cả thành viên trong nhóm (kể cả An và Bình) phải làm là:

    git checkout main
git pull origin main

    Lệnh này sẽ kéo phiên bản mới nhất của nhánh main (đã bao gồm tính năng đăng nhập) về máy của họ.


git checkout để chuyển nhánh (Switching Branches) 🗺️

Đây là công dụng phổ biến nhất. Lệnh này cho phép bạn di chuyển HEAD (con trỏ "bạn đang ở đây") sang một nhánh khác hoặc một commit khác.

Hãy tưởng tượng các nhánh của bạn là những bộ bản vẽ thiết kế khác nhau cho cùng một tòa nhà:

  • Nhánh main: Bản vẽ tổng thể đã được phê duyệt.

  • Nhánh feature/windows: Bản vẽ chi tiết chỉ tập trung vào việc thiết kế cửa sổ.

  • Nhánh feature/doors: Bản vẽ chi tiết chỉ tập trung vào thiết kế cửa ra vào.

Lệnh: git checkout <tên-nhánh>

Bạn đang ở nhánh main. Bây giờ bạn muốn bắt đầu làm việc với cửa sổ.

# Di chuyển đến nhánh 'feature/windows'
git checkout feature/windows

Điều gì xảy ra khi bạn chạy lệnh này?

  • HEAD di chuyển: Git sẽ di chuyển con trỏ HEAD từ nhánh main sang nhánh feature/windows.

  • Working Directory thay đổi: Các file trong thư mục làm việc của bạn sẽ ngay lập tức được cập nhật để phản ánh chính xác trạng thái của commit cuối cùng trên nhánh feature/windows. Bất kỳ file nào chỉ có ở nhánh main sẽ biến mất, và các file chỉ có ở nhánh feature/windows sẽ xuất hiện. Nó giống như bạn cất bộ bản vẽ tổng thể đi và trải bộ bản vẽ chi tiết cửa sổ ra bàn làm việc.

Tạo và chuyển nhánh cùng lúc:

Bạn có thể kết hợp việc tạo nhánh mới và chuyển sang nó ngay lập- tức bằng cờ -b.

# Lệnh này tương đương với:
# git branch new-feature
# git checkout new-feature
git checkout -b new-feature

git checkout để khôi phục file (Restoring Files) ⏪

Công dụng này ít phổ biến hơn nhưng rất mạnh mẽ. Nó cho phép bạn hủy bỏ các thay đổi trong thư mục làm việc (Working Directory) và đưa một file trở lại trạng thái của nó ở commit gần nhất.

Lệnh: git checkout -- <tên-file>

Cảnh báo: ⚠️ Lệnh này rất nguy hiểm vì nó sẽ ghi đè vĩnh viễn các thay đổi bạn đã thực hiện trên file đó. Hãy coi nó như một nút "hoàn tác" không thể khôi phục.

Ví dụ:

Bạn đã chỉnh sửa file style.css và thực hiện rất nhiều thay đổi. Nhưng sau một hồi, bạn nhận ra mọi thứ trở nên hỗn loạn và bạn chỉ muốn quay lại phiên bản sạch sẽ, ổn định của file này (phiên bản đã được commit lần cuối)Bash

# Hủy bỏ tất cả các thay đổi trên file style.css
# và đưa nó về trạng- thái của commit cuối cùng
git checkout -- style.css

Điều gì xảy ra?

Git sẽ lấy phiên bản của style.css được lưu trong HEAD (commit cuối cùng) và dùng nó để ghi đè lên file style.css hiện tại trong thư mục làm việc của bạn. Mọi thay đổi bạn vừa thực hiện trên file đó sẽ biến mất.

 

Phần 4: Siêu năng lực của Git - Phân nhánh và Xung đột

4.1. Ví dụ về giải quyết xung đột (Merge Conflict)

Đây là kịch bản kinh điển:
Chuẩn bị: Trong nhánh main, bạn có file team.txt với nội dung:

Project Members:

- Alice

Bạn commit file này.
Nhánh của An: An muốn thêm tên mình vào. 
git checkout -b feature/add-an
# An sửa file team.txt thành:
# Project Members:
# - Alice
# - An
git add team.txt
git commit -m "Add An to team"

 

Nhánh của Bình: Cùng lúc đó, Bình cũng muốn thêm tên mình vào. Bình cũng bắt đầu từ nhánh main gốc.
git checkout main

git checkout -b feature/add-binh

# Bình sửa file team.txt thành:

# Project Members:

# - Alice

# - Binh

git add team.txt

git commit -m "Add Binh to team"
Trộn nhánh của An: Bây giờ, bạn quay lại main và trộn nhánh của An.

git checkout main

git merge feature/add-an

# Kết quả: Fast-forward. Thành công! Nội dung file main giờ đã có tên An.

 

Gây ra xung đột: Bạn tiếp tục trộn nhánh của Bình.

git merge feature/add-binh

# Kết quả:

# Auto-merging team.txt

# CONFLICT (content): Merge conflict in team.txt

# Automatic merge failed; fix conflicts and then commit the result.
Xung đột đã xảy ra! Vì cả hai nhánh đều thay đổi cùng một vị trí trong file.
Giải quyết: Mở file team.txt, bạn sẽ thấy:
Project Members:

- Alice

<<<<<<< HEAD

- An

=======

- Binh

>>>>>>> feature/add-binh
    • <<<<<<< HEAD: Bắt đầu phần code của nhánh bạn đang ở (main, đã có tên An).
    • =======: Ranh giới.
    • >>>>>>> feature/add-binh: Kết thúc phần code từ nhánh bạn đang cố trộn vào.
Bạn cần phải tự tay sửa file này để có được kết quả cuối cùng mong muốn. Ví dụ:
Project Members:

- Alice

- An

- Binh
Hoàn tất: Sau khi sửa và lưu file, bạn cần báo cho Git rằng bạn đã giải quyết xong.

 
git add team.txt

git commit

# Git sẽ mở một trình soạn thảo với một thông điệp commit mặc định

# ví dụ: "Merge branch 'feature/add-binh'". Bạn chỉ cần lưu và đóng lại.​

Xung đột đã được giải quyết thành công!

Phần 5: .gitignore là gì

Hãy coi .gitignore như một danh sách các quy tắc mà bạn đưa cho "người bảo vệ" (Git) của kho chứa. Trước khi Git thực hiện bất kỳ hành động nào như kiểm tra trạng thái (git status) hay thêm file (git add), nó sẽ nhìn vào danh sách này trước. Nếu một file hoặc thư mục khớp với một quy tắc trong danh sách, Git sẽ hoàn toàn làm lơ nó, coi như nó không tồn tại.

Tại sao .gitignore lại cực kỳ quan trọng?

Việc "làm lơ" file nghe có vẻ lạ, nhưng nó lại giải quyết 4 vấn đề lớn:

  1. Giữ kho chứa sạch sẽ: Dự án của bạn sẽ tự động tạo ra nhiều file "rác" như file log, file tạm, file do hệ điều hành tạo ra (.DS_Store trên macOS, Thumbs.db trên Windows). .gitignore giúp ngăn chúng làm bẩn lịch sử commit của bạn.

  2. Bảo vệ thông tin nhạy cảm: Đây là lý do quan trọng nhất. Các file chứa mật khẩu, khóa API, thông tin kết nối cơ sở dữ liệu (thường là file .env) không bao giờ được đưa lên kho chứa công khai. .gitignore đảm bảo bạn không vô tình đẩy chúng lên GitHub.

  3. Giảm dung lượng kho chứa: Các thư mục như node_modules (trong dự án JavaScript) hoặc môi trường ảo (trong Python) có thể chứa hàng nghìn file và nặng hàng trăm MB. Chúng không phải là code gốc của bạn và có thể được cài đặt lại từ một file quản lý (như package.json). Việc bỏ qua chúng giúp kho chứa của bạn nhẹ và nhanh.

  4. Tránh xung đột không cần thiết: Các file cấu hình riêng của IDE (như thư mục .vscode hoặc .idea) có thể khác nhau trên máy của mỗi người. Việc bỏ qua chúng giúp tránh các xung đột (merge conflicts) không liên quan đến logic code.

 

Cách viết quy tắc trong .gitignore

 

File .gitignore là một file văn bản đơn giản. Mỗi dòng là một quy tắc.

  • Bình luận (Comments):

    Dùng dấu # ở đầu dòng để ghi chú. Việc này rất hữu ích để giải thích tại sao bạn lại bỏ qua một thứ gì đó.

    # Bỏ qua các file log được tạo tự động
*.log

  • Bỏ qua file cụ thể:

    Chỉ cần ghi tên file đầy đủ.

    secret.txt
config.local.php

  • Bỏ qua toàn bộ thư mục:

    Ghi tên thư mục và theo sau là dấu /. Thao tác này sẽ bỏ qua thư mục đó và tất cả mọi thứ bên trong nó.

    # Bỏ qua toàn bộ thư mục chứa các file do người dùng upload
uploads/

  • Sử dụng ký tự đại diện (Wildcards):

    Dấu * là ký tự đại diện cho một chuỗi bất kỳ.

    # Bỏ qua tất cả các file có đuôi .log
*.log

# Bỏ qua tất cả các file có đuôi .tmp
*.tmp

  • Ngoại lệ (Exceptions):

    Đôi khi bạn muốn bỏ qua cả một thư mục nhưng lại muốn giữ lại một file cụ thể bên trong nó. Hãy dùng dấu ! ở đầu quy tắc.

    # Bỏ qua tất cả các file .log
*.log

# NHƯNG đừng bỏ qua file quan trọng này
!important.log

 

Ví dụ thực tế: Một file .gitignore cho dự án playwright

# ## Dependencies ##
# Bỏ qua toàn bộ thư mục chứa các thư viện tải về.
# Thư mục này sẽ được tạo lại khi chạy 'npm install' hoặc 'yarn install'.
/node_modules

# ## Build Output ##
# Bỏ qua các thư mục chứa code đã được biên dịch hoặc đóng gói.
/dist
/build
/out
*.tsbuildinfo

# ## Playwright - CỰC KỲ QUAN TRỌNG ##
# Bỏ qua các báo cáo (report), kết quả (result), và các file tạm
# được tạo ra mỗi khi bạn chạy test. Chúng không phải là code
# và không nên được đưa vào version control.
/playwright-report/
/test-results/

# Bỏ qua các file trace của Playwright (thường là file .zip)
*.zip

# Bỏ qua các trình duyệt mà Playwright tải về.
# Thư mục này rất lớn và sẽ được tự động tải lại khi cần.
/ms-playwright/

# ## Logs ##
# Bỏ qua các file log được tạo tự động.
*.log
npm-debug.log*
yarn-error.log
yarn-debug.log

# ## Environment Variables ##
# Bỏ qua các file chứa biến môi trường. Chúng chứa thông tin nhạy cảm
# như API keys, mật khẩu, không bao giờ được commit.
.env
.env.local
.env.*.local

# Tuy nhiên, hãy giữ lại file .env.example để người khác biết cần
# tạo những biến môi trường nào. Dấu "!" là một ngoại lệ.
!.env.example

# ## IDE & System Files ##
# Bỏ qua các file cấu hình của IDE và file tạm của hệ điều hành.
# Cấu hình IDE nên là của cá nhân mỗi người.
/.vscode/
/.idea/
.DS_Store
Thumbs.db

 

Tình huống đặc biệt: "Lỡ" commit file rồi mới thêm vào .gitignore

 

Đây là một lỗi rất phổ biến. Bạn quên tạo .gitignore từ đầu và đã git add . rồi commit file .env. Bây giờ, dù bạn có thêm .env vào .gitignore, Git vẫn sẽ tiếp tục theo dõi nó.

Tại sao? Vì file .env đã nằm trong "tủ hồ sơ lưu trữ" (Repository). Quy tắc .gitignore chỉ áp dụng cho các file chưa được theo dõi (untracked).

Cách giải quyết: Bạn cần phải nói với Git: "Hãy dừng việc theo dõi file này, nhưng đừng xóa nó khỏi máy của tôi."

  1. Thêm quy tắc vào .gitignore:

    Mở file .gitignore và thêm dòng .env.

  2. Chạy lệnh để xóa file khỏi "khu vực theo dõi" của Git:

    git rm --cached .env

    • git rm: Lệnh xóa file.

    • --cached: Tùy chọn cực kỳ quan trọng! Nó chỉ xóa file khỏi Staging Area (chỉ số của Git) chứ không xóa file vật lý trong thư mục của bạn.

  3. Commit sự thay đổi này:

    Bây giờ git status sẽ báo file .env đã bị "xóa" (theo cách nhìn của Git). Hãy commit để xác nhận việc ngừng theo dõi này.

    git commit -m "Stop tracking .env file"

Kể từ bây giờ, file .env của bạn đã an toàn trên máy local và sẽ không bao giờ bị đẩy lên remote nữa.

 

Lời khuyên tốt nhất

  • Tạo file .gitignore ngay từ đầu: Đây nên là một trong những hành động đầu tiên khi bạn git init một dự án mới.

Teacher

Teacher

Nguyên Hoàng

Automation Engineer

With 7+ years of hands-on experience across multiple languages and frameworks. I'm here to share knowledge, helping you turn complex processes into simple and effective solutions.

Cộng đồng Automation Testing Việt Nam:

🌱 Telegram Automation Testing:   Cộng đồng Automation Testing
🌱 Facebook Group Automation: Cộng đồng Automation Testing Việt Nam
🌱 Facebook Fanpage: Cộng đồng Automation Testing Việt Nam - Selenium
🌱 Telegram Manual Testing:   Cộng đồng Manual Testing
🌱 Facebook Group Manual: Cộng đồng Manual Testing Việt Nam

Chia sẻ khóa học lên trang

Bạn có thể đăng khóa học của chính bạn lên trang Anh Tester để kiếm tiền

ĐĂNG KÝ NGAY

Danh sách bài học