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

🗂️ Phần 1: Git là gì và vì sao Git tồn tại?

Khi làm dự án thật, bạn sẽ rất nhanh gặp cảnh sửa file rồi lại muốn quay về bản cũ, hoặc phải làm việc chung với người khác trên cùng một codebase. Nếu không có công cụ quản lý phiên bản, dự án sẽ sớm rơi vào mớ hỗn độn kiểu project-final, project-final-2, project-final-final.

Git ra đời để giải quyết đúng bài toán đó. Nó giúp bạn lưu lại lịch sử thay đổi, biết ai sửa gì, quay lại phiên bản cũ khi cần và phối hợp làm việc nhóm một cách có kiểm soát hơn.

🔹 1. Git giúp giải quyết vấn đề gì?

• Quản lý phiên bản: biết chính xác file đã thay đổi như thế nào theo thời gian.
• Khôi phục khi cần: nếu sửa sai, bạn có thể quay lại một trạng thái trước đó.
• Làm việc nhóm: nhiều người cùng sửa code mà vẫn có cơ chế đồng bộ và kiểm soát.
• Phân nhánh: thử tính năng mới mà không làm hỏng nhánh chính.

🔹 2. Hai khái niệm quan trọng: Local và Remote

Khi học Git, bạn nên phân biệt rõ hai nơi làm việc sau:

• Local Repository: kho Git trên máy của bạn. Đây là nơi bạn sửa file, add, commit và kiểm tra lịch sử.
• Remote Repository: kho Git trên máy chủ như GitHub, GitLab hoặc Bitbucket. Đây là nơi chia sẻ code với nhóm.

Nói ngắn gọn: bạn làm việc hằng ngày ở local, rồi dùng push và pull để đồng bộ với remote.

🧰 Phần 2: Quy trình làm việc cá nhân ở local

Trước khi làm việc nhóm, bạn phải nắm rất chắc flow local. Đây là chuỗi thao tác cơ bản nhất trong Git mà người mới cần thuộc lòng.

🔹 1. Ba khu vực làm việc “thần thánh”

Khi thao tác với Git ở local, bạn sẽ làm việc với 3 khu vực chính:

• Working Directory: nơi bạn đang sửa file thật trên máy.
• Staging Area: nơi bạn chọn trước những thay đổi nào sẽ được đưa vào commit tiếp theo.
• Repository (.git): nơi Git lưu lịch sử commit chính thức.

Hiểu được 3 khu vực này sẽ giúp bạn hiểu vì sao phải có cả git add lẫn git commit.

🔹 2. Bắt đầu một dự án Git mới với git init

Lệnh git init dùng để khởi tạo một Git repository mới trong thư mục hiện tại. Sau lệnh này, Git sẽ tạo ra thư mục ẩn .git để quản lý lịch sử phiên bản.

💻 Khởi tạo Git repository:

git init
# Khởi tạo một Git repository mới trong thư mục hiện tại

🔹 3. Kiểm tra trạng thái với git status

Sau khi tạo file hoặc chỉnh sửa file, lệnh đầu tiên bạn nên dùng là git status. Đây là lệnh giúp bạn biết hiện tại Git đang nhìn thấy điều gì: file nào mới, file nào đã sửa, file nào đã được add vào staging.

💻 Kiểm tra trạng thái hiện tại:

git status
# Xem file nào đang untracked, modified hoặc đã staged

🔹 4. Đưa file vào staging bằng git add

Khi một file đã sẵn sàng cho commit, bạn dùng git add để đưa nó từ Working Directory vào Staging Area.

💻 Add một file cụ thể:

git add index.html
# Đưa file index.html vào staging để chuẩn bị commit

💻 Add rồi kiểm tra lại trạng thái:

git add index.html
git status
# Kiểm tra lại để thấy file đã chuyển sang trạng thái staged

🔹 5. Tạo commit bằng git commit

Sau khi đã add những thay đổi cần thiết, bạn dùng git commit để chụp lại một mốc lịch sử mới trong repository. Đây là bước biến các thay đổi đã chọn thành một bản ghi chính thức.

💻 Commit với message rõ nghĩa:

git commit -m "Add initial HTML for homepage"
# Tạo commit mới và gắn message mô tả thay đổi

💡 Lưu ý: Message commit nên ngắn gọn nhưng có nghĩa. Đừng dùng các commit kiểu fix, update, abc nếu thay đổi của bạn có thể mô tả rõ hơn.

🔹 6. Xem lịch sử với git log và git log --oneline

Sau vài commit, bạn sẽ cần xem lại lịch sử thay đổi. Lúc đó git log là công cụ cơ bản nhất.

💻 Xem log đầy đủ:

git log
# Xem lịch sử commit chi tiết theo thứ tự mới nhất trước

💻 Xem log ngắn gọn:

git log --oneline
# Xem lịch sử commit dạng ngắn, dễ đọc nhanh hơn

💻 Ví dụ quy trình local hoàn chỉnh:

git init
# Khởi tạo repository

git status
# Kiểm tra trạng thái ban đầu

git add index.html
# Chọn file index.html để đưa vào staging

git commit -m "Add initial HTML for homepage"
# Tạo commit đầu tiên

git add style.css
# Add thêm file CSS

git commit -m "Add basic styling for body"
# Tạo commit tiếp theo

git log --oneline
# Xem nhanh lịch sử commit vừa tạo

🌐 Phần 3: Làm việc với remote repository

Sau khi đã quen với local, bước tiếp theo là kết nối với kho code từ xa để làm việc nhóm. Đây là lúc các khái niệm như clone, origin, push và pull xuất hiện.

🔹 1. Remote repository là gì?

Remote repository là bản repository nằm trên server, thường là trên GitHub, GitLab hoặc Bitbucket. Nó cho phép nhiều người cùng đồng bộ code và xem lịch sử thay đổi từ một nơi chung.

🔹 2. Lấy dự án về máy bằng git clone

Nếu dự án đã có sẵn trên GitHub, cách phổ biến nhất để bắt đầu là clone về máy. Lệnh này không chỉ tải code về mà còn tự tạo kết nối tới remote mặc định có tên là origin.

git clone https://github.com/company/project-name.git
# Tải toàn bộ repository từ remote về máy local

🔹 3. Kiểm tra remote bằng git remote -v

Sau khi clone hoặc sau khi kết nối remote thủ công, bạn có thể kiểm tra danh sách remote hiện có bằng lệnh sau.

git remote -v
# Xem danh sách remote hiện có cùng địa chỉ fetch và push

origin chỉ là nickname mặc định mà Git dùng để đặt tên cho remote chính. Đây không phải từ khóa bắt buộc, nhưng gần như dự án nào cũng dùng.

🔹 4. Đẩy thay đổi lên remote với git push

Sau khi commit ở local, bạn cần push để đưa commit đó lên remote cho người khác thấy.

git push -u origin feature/login
# Đẩy nhánh feature/login lên remote origin
# -u dùng để thiết lập nhánh tracking cho lần đầu tiên

Sau khi đã dùng -u một lần, những lần sau khi đang đứng đúng nhánh đó, bạn thường chỉ cần gõ:

git push
# Đẩy nhánh hiện tại lên remote đã được tracking trước đó

🔹 5. Cập nhật thay đổi bằng git pull

Khi người khác đã push code mới lên remote, bạn dùng git pull để kéo thay đổi đó về máy. Về bản chất, git pull là sự kết hợp của fetch và merge.

git checkout main
# Chuyển về nhánh main trước khi cập nhật

git pull origin main
# Kéo các thay đổi mới nhất từ remote về nhánh main local

⚠️ Lưu ý: Trước khi bắt đầu một nhánh mới hoặc tiếp tục làm việc, hãy tập thói quen cập nhật main trước để giảm nguy cơ conflict về sau.

🔹 6. Kịch bản làm việc nhóm thực tế

Hãy tưởng tượng An và Bình cùng làm trên một dự án.

💻 An tạo nhánh mới để làm tính năng login:

git checkout -b feature/login
# Tạo nhánh mới và chuyển sang nhánh đó ngay

git add .
# Add các thay đổi hiện tại

git commit -m "Add login form UI"
# Commit phần giao diện login

💻 Sau đó An đẩy nhánh lên GitHub:

git push -u origin feature/login
# Đẩy nhánh feature/login lên remote để chia sẻ với nhóm

💻 Trong khi đó Bình sửa lỗi ở nhánh main:

git checkout main
# Đứng trên nhánh main

git add .
git commit -m "Fix typo on homepage"
git push origin main
# Đẩy bản sửa lỗi lên main trên remote

💻 An cần cập nhật bản mới nhất từ main:

git checkout main
# Chuyển về main local

git pull origin main
# Kéo bản mới nhất từ remote về

git checkout feature/login
# Quay lại nhánh đang làm để tiếp tục công việc

🔀 Phần 4: Branch, Pull Request và Merge Conflict

Đây là phần rất quan trọng khi làm việc nhóm. Git không chỉ giúp lưu lịch sử, mà còn cho phép mỗi người làm việc trên nhánh riêng, sau đó tích hợp lại vào nhánh chính một cách có kiểm soát.

🔹 1. Chuyển và tạo nhánh bằng git checkout

Bạn có thể dùng git checkout để chuyển sang nhánh khác hoặc tạo nhánh mới ngay lập tức.

git checkout feature/windows
# Chuyển sang nhánh feature/windows nếu nhánh đã tồn tại

git checkout -b new-feature
# Tạo nhánh new-feature và chuyển sang luôn

💡 Lưu ý: Ngày nay nhiều tài liệu mới dùng git switch cho thao tác chuyển nhánh, nhưng bài này đang dùng git checkout nên bạn vẫn cần biết và đọc được nó.

🔹 2. Pull Request là gì?

Khi hoàn thành công việc trên một nhánh như feature/login, bạn thường không merge thẳng vào main ngay. Thay vào đó, bạn tạo một Pull Request trên GitHub để nhóm cùng review trước khi hợp nhất.

Pull Request là một yêu cầu chính thức để xin hợp nhất code từ một nhánh này vào một nhánh khác.

• Review code: đồng đội có thể đọc, góp ý và phát hiện bug trước khi merge.
• Thảo luận rõ ràng: mọi trao đổi đều tập trung quanh cùng một thay đổi.
• Kiểm soát chất lượng: tránh đưa code chưa ổn vào nhánh chính.

💻 Flow Pull Request phổ biến:

git checkout -b feature/login
# Tạo nhánh làm tính năng mới

git add .
git commit -m "Add login form UI"
# Commit phần việc đã làm

git push -u origin feature/login
# Đẩy nhánh lên GitHub để mở Pull Request

Sau bước này, bạn vào GitHub, mở Pull Request, chờ review, sửa nếu cần, rồi mới merge vào main.

🔹 3. Merge conflict là gì?

Conflict xảy ra khi Git không biết phải chọn thay đổi nào vì hai nhánh cùng sửa vào một chỗ trong cùng một file. Lúc đó Git sẽ dừng merge và yêu cầu bạn tự quyết định nội dung cuối cùng.

💻 Ví dụ tạo conflict:

git checkout -b feature/add-an
# Tạo nhánh của An

git add team.txt
git commit -m "Add An to team"
# Commit thay đổi của An

git checkout main
git checkout -b feature/add-binh
# Tạo nhánh khác của Bình

git add team.txt
git commit -m "Add Binh to team"
# Commit thay đổi của Bình

git checkout main
git merge feature/add-an
# Merge nhánh của An vào main trước

git merge feature/add-binh
# Khi merge nhánh của Bình, Git có thể báo conflict nếu cùng sửa một dòng

Khi conflict xảy ra, Git sẽ chèn các dấu đặc biệt như sau vào file:

<<<<<<< HEAD
Noi dung hien tai tren nhanh dang merge vao
=======
Noi dung den tu nhanh dang merge
>>>>>>> feature/add-binh

• <<<<<<< HEAD: phần nội dung hiện tại ở nhánh bạn đang đứng.
• =======: ranh giới phân cách hai phiên bản.
• >>>>>>> feature/add-binh: nội dung đến từ nhánh đang được merge vào.

💻 Sau khi sửa conflict, cần làm gì?

git add team.txt
# Xác nhận rằng file conflict đã được sửa xong

git commit
# Tạo commit merge để hoàn tất việc hợp nhất

⚠️ Lưu ý: Conflict không có nghĩa là Git “hỏng”. Nó chỉ có nghĩa là Git không dám tự quyết thay bạn. Bạn cần đọc kỹ file và chọn nội dung cuối cùng đúng với ý đồ nghiệp vụ.

🔹 4. Một lưu ý về git checkout -- <file>

Bài gốc cũng nhắc tới cách dùng git checkout -- <tên-file> để khôi phục file về trạng thái trước đó. Lệnh này có thể hữu ích, nhưng cũng khá nguy hiểm vì nó có thể làm mất thay đổi chưa commit.

git checkout -- style.css
# Khôi phục file style.css về trạng thái gần nhất trong Git
# Cẩn thận vì thay đổi chưa commit có thể bị mất

🙈 Phần 5: .gitignore và cách tránh commit nhầm file không nên theo dõi

File .gitignore là danh sách các quy tắc để nói với Git rằng: “những file hoặc thư mục này đừng theo dõi”. Đây là file rất quan trọng trong mọi dự án thật.

🔹 1. Vì sao .gitignore quan trọng?

• Giữ repository sạch: tránh commit file tạm, log, cache, file hệ điều hành.
• Bảo vệ thông tin nhạy cảm: tránh đẩy file .env, API key, password lên remote.
• Giảm rác trong lịch sử commit: chỉ theo dõi những file thực sự liên quan đến source code.

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

Mỗi dòng trong file là một quy tắc. Bạn có thể ignore file cụ thể, thư mục, nhóm file theo phần mở rộng, hoặc tạo ngoại lệ bằng dấu !.

💻 Ví dụ quy tắc cơ bản:

# Ignore file cu the
.env

# Ignore thu muc
node_modules/
test-results/

# Ignore theo phan mo rong
*.log

# Giu lai mot file cu the du dang nam trong thu muc da ignore
!important.log

💻 Ví dụ .gitignore cho dự án Playwright:

# Thu muc dependencies
node_modules/

# Ket qua chay test
test-results/
playwright-report/

# File moi truong
.env

# File log va file tam
*.log
*.tmp

# File he dieu hanh
.DS_Store
Thumbs.db

🔹 3. Tình huống “lỡ commit rồi” thì sao?

Đây là lỗi rất phổ biến: bạn quên tạo .gitignore từ đầu, rồi đã add và commit file nhạy cảm như .env. Sau đó dù có thêm .env vào .gitignore, Git vẫn tiếp tục theo dõi file đó.

Lý do là vì .gitignore chỉ áp dụng cho những file chưa được Git theo dõi.

💻 Cách ngừng theo dõi file đã lỡ commit:

git rm --cached .env
# Gỡ file .env khỏi vùng theo dõi của Git nhưng không xóa file thật trên máy

git commit -m "Stop tracking .env file"
# Commit để xác nhận việc ngừng theo dõi file này

⚠️ Lưu ý: Nếu file nhạy cảm đã từng bị push lên remote công khai, việc chỉ thêm vào .gitignore là chưa đủ. Khi đó bạn còn phải xử lý vấn đề lịch sử commit và thay đổi lại các secret đã lộ.

🔹 4. Ghi nhớ nhanh cho người mới học Git

• git init để bắt đầu repository mới.
• git status là lệnh nên dùng thường xuyên nhất để biết mình đang ở trạng thái nào.
• git add để chọn thay đổi đưa vào staging.
• git commit để tạo một mốc lịch sử mới.
• git log --oneline để xem lịch sử ngắn gọn.
• git clone để lấy dự án từ remote về máy.
• git push để đẩy thay đổi lên remote, git pull để kéo thay đổi mới về.
• git checkout -b <branch> để tạo và chuyển sang nhánh mới.
• Conflict là chuyện bình thường khi làm việc nhóm, đừng hoảng khi gặp.
• Tạo .gitignore càng sớm càng tốt, đặc biệt với file nhạy cảm như .env.

✅ Kết luận: Bài 6 là bộ “sổ tay sinh tồn” cho người mới học Git. Nếu nắm chắc flow local, remote, branch, pull request, conflict và .gitignore, bạn sẽ đủ nền để làm việc nhóm an toàn hơn và tự tin hơn khi bước vào các dự án automation thật.