I. Khởi tạo Git

1. Tải và cài đặt Git: Truy cập https://git-scm.com/downloads để tải phiên bản phù hợp với hệ điều hành của bạn (Linux, macOS, Windows). Hướng dẫn cài đặt trên trang chủ rất chi tiết. Bài viết này sẽ tập trung vào thực hành trên Windows.

2. Tạo thư mục dự án: Tạo một thư mục mới trên máy tính. Thư mục này sẽ là nơi chứa toàn bộ mã nguồn mà bạn quản lý bằng Git.

3. Mở Git Bash: Chuột phải vào thư mục dự án đã tạo và chọn "Git Bash".

4. Khởi tạo kho lưu trữ Git: Trong cửa sổ Git Bash, chạy lệnh sau để Git bắt đầu quản lý thư mục này:

git init  # Khởi tạo kho lưu trữ Git cục bộ

5. Thư mục .git: Một thư mục .git sẽ được tạo ra. Thư mục này chứa toàn bộ lịch sử phiên bản, cấu hình của Git và các dữ liệu liên quan. Tuyệt đối không nên chỉnh sửa hoặc xóa thủ công thư mục này.

II. Các Lệnh Git Cơ Bản

1. Thao tác chung

• git status: Kiểm tra trạng thái của tất cả các tệp và thư mục trong kho lưu trữ.
• git add <tên tệp hoặc thư mục>: Thêm một tệp hoặc thư mục cụ thể vào khu vực chuẩn bị (staging area) để Git theo dõi.
• git add .: Thêm tất cả các tệp và thư mục đã thay đổi vào khu vực chuẩn bị.

2. Cấu hình người dùng

Trước khi commit, bạn cần cấu hình tên người dùng và email. Các lệnh này chỉ cần chạy một lần cho mỗi máy tính.

$ git config --global user.name "Tên Của Bạn"
$ git config --global user.email "email@example.com"

Ví dụ:

$ git config --global user.name "Nguyễn Văn A"
$ git config --global user.email "nguyenvana@email.com"

3. Commit phiên bản

Sau khi thêm tệp vào khu vực chuẩn bị, bạn có thể commit để lưu lại một phiên bản:

git commit -m 'Mô tả phiên bản'

Ví dụ:

git commit -m 'Phiên bản 1.0'

Khi có các thay đổi tiếp theo:

git add .
git commit -m 'Phiên bản 1.1'

4. Xem lịch sử commit

git log

5. Tóm tắt quy trình cơ bản

1. Di chuyển vào thư mục dự án bạn muốn quản lý.
2. Chạy git init để khởi tạo kho lưu trữ.
3. Chạy git status để xem trạng thái tệp.
4. Quan sát màu sắc:
   • Đỏ: Tệp mới hoặc đã thay đổi nhưng chưa được thêm vào khu vực chuẩn bị. Sử dụng git add . hoặc tên tệp/thư mục cụ thể.
   • Xanh lá: Tệp đã được thêm vào khu vực chuẩn bị, sẵn sàng để commit. Sử dụng git commit -m 'Mô tả'.
   • Trắng/Không màu: Tệp đã được commit và là một phần của lịch sử phiên bản.
5. Chạy git log để xem lại lịch sử các phiên bản đã commit.

III. Các Khái Niệm Nâng Cao

1. Ba Khu Vực Chính Của Git

Git hoạt động dựa trên ba khu vực chính:

• Working Directory (Khu vực làm việc): Nơi bạn trực tiếp chỉnh sửa mã nguồn.
• Staging Area (Khu vực chuẩn bị/Index): Nơi bạn chuẩn bị các thay đổi sẽ được commit. Lệnh git add đưa các thay đổi từ Working Directory vào Staging Area.
• Local Repository (Kho lưu trữ cục bộ): Nơi lưu trữ lịch sử đầy đủ của dự án. Lệnh git commit đưa các thay đổi từ Staging Area vào Local Repository.

Kho lưu trữ cục bộ bao gồm khu vực HEAD (thường trỏ đến nhánh hiện tại) và master (nhánh chính mặc định). Quá trình commit diễn ra theo hai bước: git add để đưa thay đổi vào Staging Area, sau đó git commit để lưu các thay đổi từ Staging Area vào nhánh hiện tại trong Local Repository.

2. Hoàn tác (Rollback)

Git cung cấp khả năng hoàn tác các thay đổi.

a. Hoàn tác commit

Để quay về một phiên bản trước đó:

1. Xem lịch sử commit để lấy mã hash của phiên bản mong muốn: git log
2. Sử dụng lệnh git reset --hard <mã hash>. Lệnh này sẽ đưa toàn bộ các khu vực (Working Directory, Staging Area, Local Repository) về trạng thái của phiên bản được chỉ định.

Ví dụ:

git reset --hard a3c69761b4ecd8b23c392315cd245f2939024882

b. Xem lại các phiên bản đã hoàn tác

Nếu bạn muốn quay lại một phiên bản đã bị git reset --hard, git log sẽ không hiển thị nó. Sử dụng git reflog để xem toàn bộ lịch sử các thao tác, bao gồm cả các lần hoàn tác.

git reflog

Sau đó, bạn có thể sử dụng lại git reset --hard <mã hash> để quay lại phiên bản mong muốn từ git reflog.

c. Hoàn tác thay đổi trong Working Directory

Nếu bạn đã sửa đổi một tệp trong Working Directory nhưng chưa add hoặc commit, và muốn quay về trạng thái chưa sửa đổi:

git checkout -- <tên tệp>

d. Hoàn tác thay đổi đã add vào Staging Area

Nếu bạn đã dùng git add để đưa tệp vào Staging Area nhưng chưa commit, và muốn đưa tệp đó trở lại Working Directory (chưa bị stage):

git reset HEAD <tên tệp>

Sau đó, bạn có thể dùng git checkout -- <tên tệp> để hoàn tác các sửa đổi trong Working Directory nếu cần.

3. Nhánh (Branch)

Nhánh cho phép bạn tạo ra các môi trường phát triển độc lập, tách biệt với nhánh chính (master/main). Điều này rất hữu ích khi phát triển tính năng mới hoặc sửa lỗi mà không ảnh hưởng đến phiên bản đang hoạt động.

a. Lệnh quản lý nhánh

• git branch: Liệt kê tất cả các nhánh hiện có và chỉ ra nhánh đang hoạt động.
• git branch <tên nhánh mới>: Tạo một nhánh mới.
• git checkout <tên nhánh>: Chuyển sang làm việc trên một nhánh khác.
• git checkout -b <tên nhánh mới>: Tạo một nhánh mới và ngay lập tức chuyển sang nhánh đó. Đây là cách làm phổ biến.
• git merge <tên nhánh cần hợp nhất>: Hợp nhất các thay đổi từ một nhánh khác vào nhánh hiện tại. Trước khi merge, bạn cần checkout sang nhánh đích.
• git branch -d <tên nhánh>: Xóa một nhánh đã được hợp nhất. Sử dụng -D để xóa nhánh chưa được hợp nhất (cẩn thận).

b. Xử lý xung đột khi merge

Khi hai nhánh có những thay đổi khác nhau trên cùng một dòng mã, Git không thể tự động hợp nhất và sẽ báo xung đột. Bạn cần mở tệp bị xung đột, tìm các dấu <<<<<<<, =======, >>>>>>> để xác định và chỉnh sửa thủ công phần mã mong muốn, sau đó commit lại để hoàn tất quá trình merge.

4. Luồng làm việc (Workflow)

Trong môi trường công ty, thường có các nhánh chính như master (hoặc main) cho phiên bản production và develop cho quá trình phát triển. Các tính năng mới hoặc sửa lỗi sẽ được phát triển trên các nhánh riêng biệt, sau đó merge vào develop và cuối cùng là merge vào master khi sẵn sàng phát hành.

IV. Quản lý Mã Nguồn trên GitHub

GitHub là một dịch vụ lưu trữ mã nguồn dựa trên Git, cho phép cộng tác và quản lý dự án trực tuyến.

1. Các bước cơ bản

• Đăng ký tài khoản GitHub.
• Tạo một kho lưu trữ (repository) mới trên GitHub.
• Liên kết kho lưu trữ cục bộ với kho lưu trữ trên GitHub.
• Đẩy (push) mã nguồn từ máy cục bộ lên GitHub.
• Kéo (pull) mã nguồn từ GitHub về máy cục bộ.

2. Các lệnh liên quan đến kho lưu trữ từ xa

• git remote add origin <URL kho lưu trữ GitHub>: Liên kết kho lưu trữ cục bộ với kho lưu trữ từ xa trên GitHub. origin là tên gọi mặc định cho kho lưu trữ từ xa.
• git push -u origin <tên nhánh>: Đẩy các thay đổi từ nhánh cục bộ lên kho lưu trữ từ xa. Cờ -u thiết lập mối liên kết giữa nhánh cục bộ và nhánh từ xa.
• git clone <URL kho lưu trữ GitHub>: Sao chép toàn bộ kho lưu trữ từ GitHub về máy cục bộ, bao gồm cả lịch sử và các nhánh. Lệnh này tự động thiết lập liên kết remote.
• git pull origin <tên nhánh>: Kéo các thay đổi mới nhất từ kho lưu trữ từ xa về nhánh cục bộ. Tương đương với git fetch (tải thay đổi về mà không merge) và git merge (hợp nhất thay đổi).

3. Phát triển trên nhiều máy

Sử dụng GitHub giúp bạn dễ dàng chuyển đổi giữa các máy tính. Bạn có thể push mã lên GitHub từ máy này và pull về từ máy khác để tiếp tục làm việc.

V. Rebase (Biến Đổi Cơ Sở)

rebase là một lệnh mạnh mẽ dùng để tích hợp các thay đổi từ một nhánh vào nhánh khác, nhưng theo một cách khác với merge. Thay vì tạo một commit mới để hợp nhất, rebase di chuyển các commit của nhánh hiện tại lên đầu của nhánh đích, tạo ra một lịch sử tuyến tính và gọn gàng hơn.

1. Cảnh báo quan trọng

Không nên rebase các commit đã được đẩy lên kho lưu trữ từ xa (đã chia sẻ với người khác), vì nó sẽ thay đổi lịch sử commit và gây nhầm lẫn cho đồng đội.

2. Các trường hợp sử dụng

• Gom nhiều commit nhỏ thành một commit lớn: Sử dụng git rebase -i <commit cũ hơn> hoặc git rebase -i HEAD~N (N là số lượng commit gần nhất muốn gom) để mở giao diện tương tác, chọn các commit muốn gom lại và gán nhãn (pick, squash, fixup...).
• Tích hợp thay đổi từ nhánh khác vào nhánh hiện tại để có lịch sử tuyến tính: Ví dụ, khi đang ở nhánh dev và muốn tích hợp các thay đổi mới nhất từ master, bạn có thể chạy git checkout dev rồi git rebase master. Sau đó, checkout lại master và merge dev để có một lịch sử thẳng.

3. Xử lý xung đột khi rebase

Tương tự như merge, rebase cũng có thể gặp xung đột. Sau khi giải quyết xung đột thủ công, bạn cần chạy git add . và sau đó git rebase --continue để tiếp tục quá trình rebase.

VI. Sử dụng Beyond Compare để giải quyết xung đột

Beyond Compare là một công cụ so sánh và hợp nhất tệp mạnh mẽ, có thể tích hợp với Git để giải quyết xung đột một cách trực quan.

1. Cài đặt

Tải và cài đặt Beyond Compare từ http://www.scootersoftware.com/download.php.

2. Cấu hình Git

Thực hiện các lệnh sau trong Git Bash:

git config --local merge.tool bc3
git config --local mergetool.bc3.path "/đường/dẫn/tới/bcomp"
git config --local mergetool.keepBackup false

Nếu các lệnh trên không hoạt động, bạn có thể chỉnh sửa trực tiếp tệp cấu hình .gitconfig (trên Windows thường ở C:\Users\<tên người dùng>\.gitconfig hoặc ~/.gitconfig trên macOS/Linux) và thêm các mục sau:

[merge]
    tool = bc3

[mergetool "bc3"]
    path = D:/Program Files (x86)/Beyond Compare 3/BCompare.exe # Thay đổi đường dẫn cho phù hợp

3. Áp dụng

Khi xảy ra xung đột sau lệnh git merge hoặc git rebase, chạy lệnh:

git mergetool

Beyond Compare sẽ mở ra, cho phép bạn chọn phiên bản nào để giữ hoặc kết hợp cả hai.

VII. Phối hợp làm việc nhóm

Quy trình Gitflow là một mô hình phổ biến cho các dự án lớn, sử dụng các nhánh chuyên biệt cho các mục đích khác nhau (master, develop, feature, release, hotfix).

1. Tổ chức trên GitHub

Tạo một "Organization" trên GitHub để quản lý nhiều kho lưu trữ và thành viên.

2. Gắn thẻ phiên bản (Tag)

Sử dụng git tag để đánh dấu các phiên bản quan trọng (ví dụ: git tag -a 'v1.0' -m 'Phiên bản phát hành 1.0'). Đừng quên đẩy các thẻ này lên GitHub: git push origin --tags.

3. Mời thành viên và quản lý quyền

Mời các thành viên vào tổ chức hoặc kho lưu trữ. Phân quyền truy cập (chỉ đọc, có quyền ghi) cho từng thành viên ở cấp độ tổ chức và kho lưu trữ.

4. Pull Request (Yêu cầu hợp nhất)

Khi một thành viên hoàn thành công việc trên một nhánh (ví dụ: nhánh tính năng), họ sẽ tạo một "Pull Request" (PR) để yêu cầu hợp nhất thay đổi đó vào một nhánh khác (thường là develop hoặc master). Người quản lý hoặc các thành viên khác sẽ xem xét mã (code review) trước khi phê duyệt và hợp nhất PR.

Cấu hình các quy tắc trên GitHub (ví dụ: yêu cầu review trước khi merge vào master) để đảm bảo chất lượng mã.

VIII. Đóng góp cho dự án mã nguồn mở

Quy trình đóng góp cho các dự án mã nguồn mở thường bao gồm các bước:

1. Tìm dự án: Tìm một dự án bạn quan tâm trên GitHub.
2. Fork dự án: Tạo một bản sao của dự án về tài khoản GitHub của bạn.
3. Clone về máy: Clone bản fork về máy cục bộ.
4. Tạo nhánh mới: Tạo nhánh riêng để thực hiện sửa đổi.
5. Thực hiện thay đổi: Sửa lỗi hoặc thêm tính năng.
6. Commit và Push: Commit các thay đổi và đẩy lên nhánh của bạn trên GitHub.
7. Tạo Pull Request: Gửi yêu cầu hợp nhất (PR) từ nhánh của bạn trong bản fork tới nhánh chính của dự án gốc.

Nếu yêu cầu của bạn được chấp nhận, thay đổi sẽ được tích hợp vào dự án gốc.

IX. Cấu hình Git

Git có ba cấp độ cấu hình:

• Cấu hình theo dự án (local): Chỉ áp dụng cho kho lưu trữ hiện tại. Lưu trong tệp .git/config. Dùng git config --local ....
• Cấu hình toàn cục (global): Áp dụng cho tất cả các kho lưu trữ trên máy người dùng hiện tại. Lưu trong tệp ~/.gitconfig (macOS/Linux) hoặc C:\Users\<tên người dùng>\.gitconfig (Windows). Dùng git config --global ....
• Cấu hình hệ thống (system): Áp dụng cho tất cả người dùng trên máy. Lưu trong tệp cấu hình hệ thống của Git. Cần quyền quản trị. Dùng git config --system ....

Thứ tự ưu tiên áp dụng cấu hình: Local > Global > System.

Các lệnh cấu hình hữu ích:

• git config -l: Xem tất cả các cấu hình đang có hiệu lực.
• git config --edit: Mở tệp cấu hình hiện tại để chỉnh sửa.
• git config --get <tên cấu hình>: Lấy giá trị của một cấu hình cụ thể.
• git config --unset <tên cấu hình>: Xóa một cấu hình.

X. Đăng nhập không cần mật khẩu vào kho lưu trữ từ xa

Có ba cách chính để tránh phải nhập mật khẩu mỗi khi push/pull:

1. Sử dụng URL với thông tin đăng nhập

Nhúng trực tiếp username và password vào URL của remote repository. Tuy nhiên, cách này không an toàn và không được khuyến khích cho môi trường production.

git remote set-url origin https://your_username:your_password@github.com/username/repo.git

2. Sử dụng SSH (Khóa Công khai/Riêng tư)

Đây là phương pháp được khuyến nghị và an toàn nhất.

1. Tạo cặp khóa SSH: Chạy ssh-keygen trên máy cục bộ để tạo cặp khóa (id_rsa là khóa riêng tư, id_rsa.pub là khóa công khai).
2. Thêm khóa công khai lên GitHub: Sao chép nội dung của tệp id_rsa.pub và thêm vào phần SSH Keys trong cài đặt tài khoản GitHub của bạn.
3. Cấu hình remote bằng SSH URL: Sử dụng URL SSH của kho lưu trữ (thường bắt đầu bằng git@github.com:...) khi add remote hoặc clone.

3. Trình quản lý thông tin xác thực của Git

Git có thể tự động lưu trữ thông tin đăng nhập của bạn trong một khoảng thời gian nhất định (caching) hoặc lưu trữ lâu dài. Cách này tiện lợi nhưng cần cân nhắc về bảo mật.

XI. Bỏ qua tệp và thư mục (.gitignore)

Tệp .gitignore cho phép bạn chỉ định các tệp hoặc thư mục mà Git sẽ không theo dõi hoặc commit (ví dụ: tệp biên dịch, tệp cache, tệp cấu hình nhạy cảm, thư mục node_modules...).

Tạo một tệp tên là .gitignore trong thư mục gốc của dự án và liệt kê các mẫu tệp/thư mục cần bỏ qua. Git cung cấp các mẫu có sẵn cho nhiều ngôn ngữ và framework trên GitHub (https://github.com/github/gitignore).

Ví dụ về nội dung .gitignore:

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

# Bỏ qua thư mục node_modules
node_modules/

# Bỏ qua tệp database.sqlite
database.sqlite

XII. Quản lý công việc và đóng góp trên GitHub

1. Issues (Vấn đề)

Sử dụng tính năng Issues để theo dõi lỗi (bug), yêu cầu tính năng mới, hoặc các công việc cần làm. Bạn có thể gán nhãn, chỉ định người phụ trách và thảo luận về từng vấn đề.

2. Wiki

Tạo tài liệu cho dự án, bao gồm mô tả, hướng dẫn cài đặt, kiến trúc hệ thống, v.v.