Mở trang GitHub của chính mình lên. Kéo xuống phần contribution graph — chuỗi ô vuông nhạt màu kéo dài suốt mấy tuần, rồi bỗng dồn cục đậm màu đúng ba ngày trước deadline. Click vào repo mới nhất: không có README, hoặc README chỉ vỏn vẹn dòng # my-project mặc định. Xem tiếp lịch sử commit: fix bug, fix bug 2, asdasd, final_v3_that_su_la_final.

Nếu bạn vừa giật mình vì thấy đúng repo của mình trong đó thì cứ yên tâm — gần như ai học lập trình cũng từng đi qua giai đoạn này. Vấn đề là nhà tuyển dụng chỉ lướt qua một repo trong vài giây trước khi quyết định có đọc tiếp hay không, và một repo trông như trên sẽ bị bỏ qua gần như ngay lập tức.

Nói nhanh một câu để khỏi ai bị rối trước khi vào phần chính: Git là công cụ quản lý phiên bản chạy ngay trên máy, dùng được cả khi offline. GitHub là nơi lưu bản sao đó lên mây, cộng thêm hàng loạt tính năng cộng tác — Pull Request, Issues, Actions, Secret Scanning. Dùng Git mà không cần GitHub hoàn toàn được, nhưng làm việc nhóm hay cần một nơi backup thì GitHub mới thật sự phát huy tác dụng.

Xong phần lý thuyết bắt buộc. Giờ đến 5 sai lầm cụ thể mà gần như newbie nào cũng mắc — và cách sửa từng cái ngay trong 5 phút.

1. Coi Repo là ổ cứng phụ, không phải hồ sơ năng lực

Không có README.md nghĩa là người xem không biết dự án làm gì, dùng công nghệ nào, hay muốn chạy thử thì gõ lệnh gì. Phần lớn sẽ đóng tab trước khi kịp đọc dòng code đầu tiên.

Cách sửa: một README tối thiểu chỉ cần bốn phần — tên dự án kèm mô tả một câu, ảnh hoặc gif demo nếu có giao diện, hướng dẫn cài đặt và chạy, danh sách công nghệ sử dụng. Không cần dài, chỉ cần đủ để người lạ hiểu trong nửa phút.

2. Không dùng .gitignore — biến Repo thành bãi rác, hoặc tệ hơn là lộ mật khẩu

Đây là sai lầm nguy hiểm nhất trong danh sách. Không tạo .gitignore từ đầu, thư mục node_modules/ hay file .env rất dễ bị git add . cuốn theo mà không ai để ý. node_modules/ chỉ làm repo nặng nề, bẩn mắt. Nhưng file .env chứa API key hay mật khẩu database thì là chuyện hoàn toàn khác.

GitHub có tính năng Secret Scanning tự động quét các Public Repo để phát hiện những định dạng khoá bí mật phổ biến. Nhưng đó không phải lá chắn duy nhất cần lo — ngoài kia còn cả một hệ sinh thái bot của kẻ xấu âm thầm theo dõi luồng sự kiện công khai của GitHub gần như theo thời gian thực, chỉ để “chôm” key ngay khi vừa xuất hiện. Không ít lập trình viên từng kể lại việc nhận email cảnh báo chi phí AWS tăng vọt chỉ trong vòng vài phút sau khi lỡ tay push file .env.

Cách sửa:

  • Tạo .gitignore trước lần git add . đầu tiên, không phải sau khi đã lỡ commit.
  • Nếu tạo repo mới ngay trên GitHub.com, có thể chọn sẵn mẫu .gitignore theo ngôn ngữ đang dùng (Node, Python, Java…) ngay trong bước khởi tạo, không cần gõ tay từ đầu.
  • Dùng file .env.example chỉ chứa tên biến, không chứa giá trị thật, để người khác biết cần khai báo gì.
  • Nếu đã lỡ push secret thật: xoá file ở commit sau là chưa đủ, vì giá trị cũ vẫn còn nguyên trong lịch sử Git. Việc đầu tiên cần làm là thu hồi (revoke) key đó ngay tại nơi đã cấp, rồi mới tính đến chuyện dọn lịch sử.

3. Commit message kiểu tường thuật nội tâm

fix bug, fix bug 2, asdasd, update — lịch sử commit chính là câu chuyện của cả dự án. Người review code, hoặc chính bạn sáu tháng sau, sẽ dựa vào đó để hiểu vì sao một đoạn code thay đổi, thay vì phải đọc lại toàn bộ diff.

Cách sửa: dùng format ngắn gọn kiểu Conventional Commits — một tiền tố mô tả loại thay đổi, theo sau là mô tả ở thì hiện tại:

feat: add user login with JWT
fix: resolve null pointer khi checkout
docs: cập nhật hướng dẫn cài đặt trong README
refactor: tách logic validate ra hàm riêng

Chỉ cần quen bốn tiền tố feat, fix, docs, refactor là đủ dùng cho hầu hết dự án cá nhân.

4. Code thẳng trên nhánh main — và nỗi ám ảnh mang tên “conflict”

Tình huống quen thuộc với ai từng làm bài tập nhóm: ba người cùng sửa file app.js trực tiếp trên main. Người thứ hai push lên, người thứ ba pull về là gặp ngay dòng chữ CONFLICT (content): Merge conflict in app.js, không ai chắc đoạn code của mình hay của bạn mới là bản đúng, cả nhóm ngồi gỡ conflict thủ công lúc nửa đêm trước hạn nộp.

Cách sửa: mỗi người, hoặc mỗi tính năng, làm việc trên một nhánh riêng, chỉ gộp vào main qua Pull Request sau khi đã review:

git checkout -b feature/login
# ... code tính năng login ...
git add .
git commit -m "feat: add login form"
git push -u origin feature/login

Sau đó mở Pull Request trên GitHub để người khác xem qua trước khi merge. Conflict vẫn có thể xảy ra, nhưng chỉ nằm trong phạm vi được review có kiểm soát, thay vì bùng nổ trực tiếp trên main.

5. Dồn cả học kỳ vào đúng một lần commit

Contribution graph là thứ nhiều nhà tuyển dụng liếc qua đầu tiên. Một chuỗi ô vuông đều đặn suốt nhiều tuần nói lên thói quen làm việc tốt hơn hẳn một cụm màu đậm duy nhất xuất hiện đúng đêm trước deadline.

Cách sửa: commit ngay khi một phần nhỏ chạy được, đừng đợi “xong hết mới commit”. Một tính năng nhỏ hoàn chỉnh nên là một commit, không cần chờ cả dự án hoàn thiện mới đẩy lên.

Thực chiến: dựng một Repo sạch từ con số 0

Thay vì tạo repo rồi mới nhớ ra thiếu gì, đây là thứ tự nên làm ngay từ commit đầu tiên:

# 1. Khởi tạo Git trong thư mục dự án
git init

# 2. Tạo README ngay từ đầu, đừng để trống
echo "# My First Project" > README.md

# 3. Tạo .gitignore TRƯỚC khi add bất cứ file nào
echo "node_modules/" > .gitignore
echo ".env" >> .gitignore

# 4. Add và commit
git add .
git commit -m "feat: initial project setup"

# 5. Đổi nhánh mặc định thành main
git branch -M main

# 6. Gắn với repo đã tạo trên GitHub
git remote add origin https://github.com/username/repo.git

# 7. Đẩy code lên
git push -u origin main

Thứ tự ở bước 2 và 3 quan trọng hơn nhìn tưởng: .gitignore phải có mặt trước lần git add . đầu tiên. Một khi file đã được commit, thêm nó vào .gitignore sau đó không tự xoá nó khỏi lịch sử — phải chạy thêm git rm --cached <tên file> mới gỡ được.

3 quy tắc vàng để GitHub thật sự là Portfolio, không phải kho lưu tạm

  1. Luôn có .gitignore ngay từ commit đầu tiên, và không bao giờ commit file chứa secret thật.
  2. README.md tử tế — mô tả dự án, ảnh hoặc gif demo, hướng dẫn chạy, công nghệ sử dụng.
  3. Commit đều đặn, message rõ ràng — nhiều commit nhỏ có ý nghĩa luôn tốt hơn một commit khổng lồ vào phút chót.

Việc nên làm tiếp theo không phải là đọc thêm lý thuyết, mà là mở lại repo gần nhất của mình ngay bây giờ, kiểm tra xem nó đang mắc sai lầm nào trong 5 cái ở trên — rồi sửa bằng đúng khối lệnh phía trên.

Nguồn tham khảo: