Bài viết này được tham khảo từ bài giảng về Git & Github for version control của Ph.D Nguyễn Thái Hà trong khóa học AIO25 của AI VietNam. Ngoài ra còn có sự giúp sức của Chat GPT trong quá trình viết bài và tổng hợp thông tin 😄

Table of contents
1. Giới thiệu hệ thống quản lý phiên bản và Git
- 1.1. Version Control System (VCS)
  - Khái niệm VCS
  - Các loại VCS
- 1.2. Git
2. Quy trình làm việc Git cơ bản
3. Quản lý nhánh và lịch sử
4. Cộng tác qua GitHub
5. Tùy chỉnh và mở rộng Git
6. Thực hành với Git
Tổng kết
Tài liệu tham khảo

1. Giới thiệu hệ thống quản lý phiên bản và Git

Bạn đang làm việc trên một dự án. Mỗi khi bạn đạt được một bước tiến mới, bạn muốn “chụp lại” trạng thái của code ở thời điểm đó, để nếu có gì sai sót thì vẫn có thể quay lại. Đó chính là lúc Git xuất hiện.

🟣 Git giống như một chiếc máy ảnh thông minh: mỗi khi bạn “commit”, nó sẽ chụp lại toàn bộ project của bạn tại thời điểm đó. Bạn có thể xem lại các lần chụp, quay về bản cũ, hoặc xem đã thay đổi những gì. Nhưng Git chỉ hoạt động trên máy tính cá nhân. Vậy làm sao để lưu trữ, chia sẻ code, và cùng làm việc với người khác?

🟢 GitHub giống như Google Photos cho lập trình viên: nơi bạn đăng ảnh (tức là đẩy code) từ Git lên cloud, lưu trữ an toàn và tiện chia sẻ cho bạn bè, đồng đội, hoặc open-source community. Bài viết này sẽ đưa bạn từ những khái niệm cơ bản nhất của Git, từng bước làm quen với quy trình làm việc chuẩn, cách quản lý lịch sử và nhánh, đến kỹ năng cộng tác qua GitHub và tinh chỉnh Git cho các mục đích nâng cao. Dù bạn là sinh viên đang học lập trình, hay mới bước chân vào ngành công nghệ thì hành trình tìm hiểu Git này sẽ là nền móng vững chắc cho bạn để có thể làm việc nhóm mượt mà.

1.1. Version Control System (VCS)

Nếu bạn là một vibe-coder, chắc là bạn đã từng gặp tình huống prompt cho Cursor sửa một lỗi nhỏ gì đó, xong rồi… nó phá banh luôn cả project của bạn. Lúc đó, bạn chỉ ước có thể quay ngược thời gian trở về version 5 phút trước, khi mọi thứ còn đang chạy ngon lành. Chào mừng bạn đến với Version Control System (VCS) – công cụ giúp bạn theo dõi và lưu lại mọi thay đổi của tập tin theo thời gian, để biết được ai thay đổi gì, thay đổi lúc nào, và quan trọng nhất là có thể khôi phục lại mọi thứ khi cần.

Khái niệm VCS

Version Control System là hệ thống theo dõi và lưu lại các thay đổi của tập tin theo thời gian. VCS giúp ghi lại ai thực hiện thay đổi, thay đổi gì và khi nào. image 1 3.png Lợi ích khi dùng Version Control System:

Khôi phục phiên bản cũ khi có lỗi xảy ra
So sánh sự khác biệt giữa các phiên bản
Theo dõi người thay đổi, nội dung thay đổi và thời điểm
Bảo vệ dữ liệu và hỗ trợ làm việc nhóm hiệu quả

Các loại VCS

Local Version Control

Mô hình đơn giản nhất của VCS là Local Version Control, nơi tất cả phiên bản được lưu trữ trực tiếp trên máy tính của bạn. Tuy đơn giản, nhưng mô hình này còn nhiều hạn chế khi làm việc nhóm, khi cần đồng bộ qua nhiều thiết bị hoặc đơn giản là khi máy tính bạn bị trộm lấy mất 😌.
Centralized VCS (CVCS)

Cách hoạt động của CVCS giống như một máy chủ trung tâm (server) nơi tất cả lập trình viên phải kết nối để làm việc. Mỗi khi bạn muốn lấy code mới hoặc đẩy thay đổi lên, bạn phải tương tác với server này.

Ví dụ: Subversion (SVN), CVS

Nhược điểm lớn: Nếu server gặp sự cố thì toàn bộ team dev hôm đó có thể lên công ty ngồi chơi xơi nước hoặc mất dữ liệu thì cả team sẽ bay màu theo.
Distributed VCS (DVCS)

DVCS – như Git – hoạt động khác biệt: mỗi lập trình viên đều có một bản sao đầy đủ của toàn bộ repository, bao gồm cả lịch sử version.

Điều này có nghĩa là bạn vẫn có thể commit, revert, xem log, thậm chí khôi phục lại project ngay cả khi không kết nối mạng hoặc server bị hỏng.

Ưu điểm vượt trội:
- An toàn hơn, vì không phụ thuộc vào 1 server duy nhất
- Tự do thao tác offline
- Dễ backup, dễ phân nhánh và làm việc song song

1.2. Git

Lược sử Git - Chuyện bắt đầu từ một cuộc “chia tay”

image 3 4.png Các bạn có biết hệ điều hành Linux không?

Linux là một họ các hệ điều hành nguồn mở, dựa trên nhân Linux, một nhân hệ điều hành được phát hành lần đầu tiên vào năm 1991 bởi Linus Torvalds. Linux được biết đến với tính linh hoạt, ổn định và bảo mật, và được sử dụng rộng rãi trên nhiều loại thiết bị, từ máy tính cá nhân đến máy chủ và các thiết bị nhúng. Trong những năm đầu xây dựng Linux (1991–2002), các thay đổi trong mã nguồn được các lập trình viên chia sẻ dưới dạng patch (miếng vá) rồi gửi tay qua email (Nghe kể giống tôi năm nhất làm việc nhóm bằng cách gửi code qua zalo vậy). Đến năm 2002, dự án Linux kernel bắt đầu sử dụng một hệ thống quản lý phiên bản phân tán (DVCS) độc quyền có tên là BitKeeper. Tuy nhiên, đến năm 2005, mối quan hệ giữa cộng đồng phát triển Linux và công ty thương mại đứng sau BitKeeper rạn nứt nghiêm trọng, dẫn đến việc BitKeeper thu hồi quyền sử dụng miễn phí. Chính sự kiện này đã thôi thúc cộng đồng phát triển Linux đặc biệt là Linus Torvalds, cha đẻ của Linux quyết định tự phát triển một công cụ mới, rút ra bài học từ kinh nghiệm dùng BitKeeper. Mục tiêu thiết kế của hệ thống mới này bao gồm:

Tốc độ cao
Thiết kế đơn giản
Hỗ trợ mạnh mẽ cho phát triển phi tuyến tính (tức là có hàng ngàn nhánh hoạt động song song)
Phân tán hoàn toàn (fully distributed)
Xử lý hiệu quả các dự án lớn như Linux kernel (về tốc độ và dung lượng dữ liệu) Kể từ khi ra đời năm 2005 đến nay, Git đã không ngừng phát triển và hoàn thiện, không những giữ được những giá trị cốt lõi ban đầu mà còn ngày càng dễ sử dụng hơn.

Nguyên lý hoạt động của Git

Snapshot thay vì Diff

Khác với các hệ thống quản lý phiên bản cũ chỉ lưu sự khác biệt giữa các lần chỉnh sửa (diff), Git chọn cách làm hào phóng hơn đó là nó lưu nguyên bản một “bức ảnh chụp” toàn bộ dự án mỗi khi bạn commit.

Nghe có vẻ tốn bộ nhớ? Không đâu. Đối với những phần không thay đổi, Git chỉ tạo liên kết đến bản snapshot cũ — giống như tạo shortcut, vừa tiết kiệm dung lượng, vừa siêu nhanh.

📸 Mỗi lần commit = một lần chụp lại toàn bộ project.
Đảm bảo toàn vẹn dữ liệu với SHA-1

Mỗi thứ bạn lưu trong Git: từ file, commit, đến nhánh đều được niêm phong bằng một mã định danh 40 ký tự gọi là SHA-1.

Nếu nội dung file chỉ cần đổi 1 dấu chấm, mã SHA-1 sẽ thay đổi hoàn toàn. Nhờ đó, Git có thể kiểm tra chính xác xem dữ liệu có bị sửa, bị mất hoặc bị lỗi không.

Đây là lý do Git gần như không bao giờ làm bạn mất code (trừ khi bạn lỡ force push).
Nguyên lý “Offline-first”

Một trong những điểm đáng yêu nhất của Git là bạn có thể làm việc thoải mái mà không cần Internet.

Mọi thao tác như:
- git commit
- git branch
- git merge
- git log
đều thực hiện hoàn toàn trên máy bạn. Chỉ khi nào bạn muốn chia sẻ lên GitHub (push/pull) thì mới cần kết nối mạng.

Điều này cực kỳ hữu ích khi:
- Đi code quán cà phê không có Wi-Fi
- Mạng rớt nhưng vẫn muốn commit code cho yên tâm
- Làm việc offline khi đi tàu xe hoặc máy bay

Cài đặt và cấu hình Git

Sau khi đã hiểu Git là gì và vì sao nó xịn xò đến vậy, giờ là lúc bạn setup Git vào máy và cấu hình lần đầu để bắt đầu làm việc. Tùy hệ điều hành bạn dùng, Git có thể được cài rất nhanh qua terminal hoặc tải từ website chính thức:

Linux (Debian/Ubuntu)
```
sudo apt install git
```
Linux (Fedora/RHEL)
```
sudo dnf install git
```
macOS

Mở Terminal và gõ:
```
xcode-select --install
```
hoặc vào git-scm.com để tải
Windows

Tải từ git-scm.com hoặc dùng:
```
choco install git
```

Bạn có thể kiểm tra lại bằng câu lệnh sau trong terminal (hoặc command prompt):

git --version

Nếu Git đã được cài, bạn sẽ thấy kết quả giống như:

git version 2.42.0

Sau khi cài Git, bạn cần thiết lập danh tính để khi commit, Git biết ai là người thực hiện:

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

Một số cấu hình khác giúp bạn làm việc thoải mái hơn:

git config --global core.editor "code --wait" # Dùng VS Code làm editor mặc định
git config --global color.ui auto             # Bật màu khi xem trạng thái Git

Sau đó bạn có thể tự tạo các lệnh tắt cho mình nếu bạn thấy git checkout hay git commit -m dài dòng:

git config --global alias.st status    
# git st = git status
git config --global alias.co checkout   
# git co = git checkout
git config --global alias.br branch     
# git br = git branch
git config --global alias.cm "commit -m"  
# git cm "msg" = git commit -m "msg"

Mẹo nhỏ: Bạn có thể lưu toàn bộ alias yêu thích vào file .gitconfig để dùng lại ở mọi máy. Cách truy cập file **.gitcongif**:

Tìm file .gitconfig
Mở terminal và dùng lệnh (MacOS và Linux):

nano ~/.gitconfig

hoặc

code ~/.gitconfig

Tài liệu hỗ trợ

Học Git có thể hơi choáng ngợp lúc đầu, nhưng không sao, dưới đây là những nguồn tài nguyên cực kỳ hữu ích mà bạn có thể cầu cứu bất cứ khi nào gặp khó:

Tài liệu chính thức

Trang web git-scm.com chính là “chính chủ” của Git. Tại đây, bạn sẽ tìm thấy:
- Hướng dẫn cài đặt và sử dụng Git
- Giải thích chi tiết các lệnh cơ bản đến nâng cao
- Các tài liệu PDF, sách tham khảo, và link học online
Trợ giúp ngay từ terminal

Git có tích hợp sẵn hệ thống trợ giúp cực tiện. Khi quên cú pháp, bạn có thể gõ:
```
git help
git status --help
man git-log
```
Hoặc chỉ cần thêm --help sau bất kỳ lệnh nào là sẽ có mô tả chi tiết, ví dụ:
```
git commit --help
```
Đặt câu hỏi:

Hãy đặt câu hỏi cho người thầy Gia Phúc Trần của chúng ta (Chat GPT) hoặc là các nền tảng sau:
- Stack Overflow
- GitHub Discussions
- Các nhóm Facebook, Discord, Reddit chuyên về Git
Cộng đồng Git cực kỳ năng động, và luôn có người từng gặp lỗi giống bạn!
Sách và tài nguyên học tập

Nếu bạn thích học qua sách, hãy thử “Pro Git” của Scott Chacon – tài liệu miễn phí, chi tiết và cực dễ hiểu.
- Truy cập tại: https://git-scm.com/book

2. Quy trình làm việc Git cơ bản

2.1. Khởi tạo và sao chép kho (Repository)

Nếu bạn bắt đầu một project hoàn toàn mới, hãy dùng lệnh git init để biến thư mục hiện tại thành một repository Git. Điều này tạo ra một thư mục ẩn .git/ – nơi Git lưu toàn bộ lịch sử thay đổi. Các bước:

mkdir <new_project_name>     # Tạo thư mục mới
cd <new_project_name>        # Di chuyển vào thư mục
git init                     # Khởi tạo Git repository

Sau khi git init, bạn sẽ thấy trong thư mục có file .git/ xuất hiện (dạng ẩn) đó chính là bộ não của Git. image 6 2.png Sao chép repository từ xa (clone) Khi bạn muốn làm việc với một dự án đã có sẵn trên GitHub hoặc GitLab, bạn sẽ dùng lệnh git clone để tải toàn bộ repository về máy. Cú pháp clone:

git clone https://github.com/username/repository.git
# hoặc qua SSH:
git clone git@github.com:username/repository.git

Khi bạn clone, Git sẽ tạo một thư mục mới có cùng tên với repository. Nếu muốn đổi tên thư mục khi clone, bạn có thể thêm tên tùy ý ở cuối:

git clone https://github.com/username/repository.git <thu_muc_moi>

image 7 2.png Cách lấy https để clone repo trên GitHub

2.2. Theo dõi và lưu trữ thay đổi

Trạng thái file trong Git

Khi bạn làm việc với Git, mỗi file trong thư mục làm việc (working directory) đều ở một trong bốn trạng thái sau:

Untracked: File mới hoàn toàn, Git chưa biết đến.

➜ Ví dụ: bạn vừa tạo file test.html, Git chưa theo dõi nó.
Modified: File đã bị sửa so với lần commit gần nhất, nhưng chưa được chuẩn bị để lưu.
Staged: File đã được đưa vào vùng chuẩn bị (staging area) bằng git add, sẵn sàng để commit.
Committed: File đã chính thức được Git lưu lại trong lịch sử dự án.

Git sẽ chuyển file qua các trạng thái này tùy theo bạn thao tác thế nào (add, commit, sửa file…).

Thao tác cơ bản

Để xem trạng thái các file hiện tại:

git status

Để đưa file vào vùng chuẩn bị (staging area):

git add tên-file.txt   # Thêm một file cụ thể
git add .              # Thêm tất cả file đã thay đổi

Để lưu các thay đổi đã chuẩn bị:

git commit -m "Mô tả ngắn gọn về thay đổi"

Mỗi lần commit là bạn đã “chụp lại” trạng thái dự án tại thời điểm đó.

Sử dụng `.gitignore`

File .gitignore giúp bạn nói với Git rằng: “Đừng theo dõi những file/thư mục này!” Dùng để bỏ qua:

File tạm, file log (.log)
Thư mục build (/build/)
File cấu hình cá nhân (.env)
Thư viện cài bằng npm hoặc composer (node_modules/, vendor/) Ví dụ nội dung file .gitignore:

# Bỏ qua thư mục build
/build/
# Bỏ qua tất cả file .log
*.log
# Bỏ qua file cấu hình cụ thể
config.ini
.env

Cần tạo file .gitignore trước khi bạn git add các file muốn bỏ qua, nếu không Git vẫn sẽ theo dõi chúng.

2.3. Xem lịch sử commit

Khi làm việc nhóm hoặc phát triển dự án lâu dài, bạn rất cần biết: ai thay đổi gì, khi nào, và tại sao. Đó là lý do lệnh git log trở thành một công cụ không thể thiếu. Cú pháp cơ bản

git log

Mặc định, lệnh này sẽ hiển thị:

Mã commit (SHA)
Tên người commit (Author)
Thời gian
Nội dung mô tả Một số tùy chọn phổ biến | | | |---|---| |Lệnh|Tác dụng| |git log -p|Hiện chi tiết nội dung khác biệt của mỗi commit| |git log --stat|Tóm tắt số file và dòng bị thay đổi| |git log --since="1 week ago"|Lọc commit theo thời gian| |git log --author="Tên"|Lọc commit theo người thực hiện| |git log --oneline --graph --all|Hiển thị lịch sử gọn gàng dạng sơ đồ cây (rất phù hợp để nhìn tổng quát nhiều nhánh)|

Bạn có thể kết hợp nhiều tùy chọn với nhau! Ví dụ minh hoạ: Mẹo: Sử dụng **git log --oneline --graph --all** Lệnh này sẽ hiển thị toàn bộ lịch sử commit một cách gọn gàng và trực quan, đặc biệt hữu ích khi dự án có nhiều nhánh và bạn muốn xem merge, split, hoặc thứ tự commit: Sẽ cho kết quả như sơ đồ commit cây. Các nhánh tách ra, gộp lại rất dễ theo dõi.

2.4. Hoàn tác thay đổi

Khi làm việc với Git, lỗi là điều không thể tránh khỏi: bạn có thể sửa nhầm file, add nhầm, commit sai message… Nhưng đừng lo, Git cho bạn nhiều cách để quay xe, tùy theo trạng thái thay đổi.

Các tình huống hoàn tác phổ biến


Tình huống	Lệnh	Kết quả
Sửa file nhưng chưa `add`	`git restore <file>`	Quay về trạng thái cũ (như chưa sửa gì)
Lỡ `add` file rồi nhưng chưa commit	`git restore --staged <file>`	Gỡ khỏi staged → quay về trạng thái modified
Muốn sửa lại commit gần nhất	`git commit --amend`	Sửa message hoặc thêm file còn thiếu
Muốn hủy 1 commit đã lưu	`git revert <hash>`	Tạo commit mới để đảo ngược thay đổi

Cẩn thận: git restore sẽ xóa hoàn toàn thay đổi chưa commit, không khôi phục lại được nếu chưa stash hoặc commit.

Khi muốn giấu tạm thay đổi: `git stash`

Nếu bạn đang làm dở nhưng phải chuyển qua task khác (ví dụ: fix bug gấp), hãy dùng git stash để lưu lại tạm thời:

git stash        # Lưu tạm các thay đổi chưa commit
git stash pop    # Áp dụng lại sau

Về `git reset` thì sao?

Lệnh git reset rất mạnh – có thể quay về trạng thái trước commit, nhưng đi kèm là rủi ro cao:

git reset --soft → giữ nguyên thay đổi, chỉ xóa commit
git reset --hard → xóa hết thay đổi và commit luôn! Vì vậy, hãy cẩn thận, nhất là khi đã đẩy code lên GitHub!

2.5. Làm việc với remote repository

Trong Git, remote repository là phiên bản lưu trữ dự án trên server như GitHub, GitLab, Bitbucket… Nó cho phép bạn:

Chia sẻ project với người khác
Làm việc nhóm dễ dàng
Đồng bộ hoá thay đổi giữa máy bạn và server

Xem & quản lý các remote

git remote -v         # Xem các remote đang kết nối
git remote add        # Thêm remote mới
git remote remove     # Xoá remote

Thêm remote mới (thường là GitHub)

git remote add origin https://github.com/username/repository.git

Trong đó:

origin là tên quy ước mặc định cho remote (bạn có thể đổi thành upstream, dev-server, v.v.)
URL là địa chỉ repo trên GitHub/GitLab

Push và Pull

Đẩy (push) commit từ local lên server:

git push origin main
git push --force-with-lease  # Dùng khi cần ghi đè commit (cẩn thận!)

Kéo (pull) thay đổi từ remote về local:

git pull origin main
git pull --rebase    # Hạn chế tạo merge commit, gọn lịch sử hơn

Fetch & Merge: khi bạn muốn kiểm soát kỹ hơn

git fetch             # Lấy thông tin mới nhất từ remote, nhưng chưa gộp
git fetch --all       # Fetch từ tất cả remote
git merge origin/main # Gộp các thay đổi thủ công

Tip: pull = fetch + merge, nhưng fetch riêng giúp bạn chủ động hơn trước khi nhập code từ người khác.

2.6. Tagging – Đánh dấu phiên bản

Khi làm việc với một dự án dài hơi, sẽ có những thời điểm quan trọng như:

Phát hành bản chính thức (release)
Giao bài lần 1 cho thầy cô 😅
Gộp tính năng lớn vào nhánh chính → Những lúc như vậy, ta cần đặt một “mốc” trong lịch sử Git để dễ tham chiếu lại. Đó chính là lúc dùng tag.

1. Annotated tag

Lưu thông tin người tạo, ngày tạo và message.
Thường dùng cho các phiên bản phát hành chính thức (release version).

git tag -a v1.0 -m "Version 1.0 - Phát hành chính thức"

2. Lightweight tag

Chỉ đơn giản là một con trỏ tới commit, không có metadata.
Dùng để đánh dấu tạm hoặc cá nhân (VD: v1.0-beta).

git tag v1.0-beta

3. Đẩy tag lên remote (GitHub/GitLab)

Git không tự động đẩy tag khi bạn push commit!

Đẩy tag cụ thể:

git push origin v1.0

Đẩy tất cả tag:

git push origin --tags

Một số thao tác tag hữu ích

Xem nội dung tag:

git show v1.0

Liệt kê tất cả tag:

git tag

Tìm tag theo mẫu:

git tag -l "v1.*"

Gợi ý dùng thực tế:

Trong các dự án nhóm hoặc open source, khi bạn hoàn thành sprint hay milestone, hãy dùng annotated tag để đánh dấu. Điều này giúp mọi thành viên (và chính bạn trong tương lai) dễ quay lại đúng phiên bản đó.

3. Quản lý nhánh và lịch sử

3.1. Khái niệm nhánh (Branch)

Trong Git, nhánh (branch) là cách để bạn phát triển tính năng mới, sửa lỗi, hay thử nghiệm ý tưởng mà không làm ảnh hưởng đến phần code chính.

Nhánh là… một con trỏ
- Mỗi nhánh trong Git chỉ là một con trỏ trỏ đến một commit cụ thể.
- Khi bạn commit mới, con trỏ đó sẽ tự động cập nhật.
- Vì Git chỉ lưu con trỏ nhỏ (SHA-1), nên việc tạo và xoá nhánh cực nhanh, nhẹ hơn cả việc tạo bản sao thư mục!
Phát triển song song – Không va chạm!
- Nhánh giúp bạn tạo môi trường làm việc riêng biệt để:
  - Thêm tính năng mới
  - Sửa bug gấp
  - Thử nghiệm một ý tưởng
- Nhờ đó, bạn (và cả nhóm) có thể làm việc đồng thời mà không ảnh hưởng đến nhánh chính (main, master).
💡 Mẹo làm bài tập nhóm: mỗi người code nhánh phần việc của mình, cuối buổi mới gộp lại (merge) vào nhánh chính.
Lịch sử phân nhánh

Lịch sử Git giống như một cây phát triển: mỗi nhánh là một cành, phát triển riêng.
Sau đó các nhánh sẽ được gộp lại (merge) hoặc làm phẳng (rebase) để tạo một lịch sử liền mạch và rõ ràng.

3.2. Tạo, chuyển và gộp nhánh

Tạo và chuyển sang nhánh mới

Khi bạn muốn bắt đầu phát triển một tính năng mới, hãy tạo một nhánh riêng:

git checkout -b feature/login

Lệnh này đồng thời:

Tạo nhánh feature/login
Chuyển bạn sang nhánh đó luôn Tương đương với:

git branch feature/login
git checkout feature/login

Phát triển tính năng trên nhánh mới

Khi đã ở nhánh feature/login, mọi commit của bạn sẽ không ảnh hưởng gì đến nhánh chính (main). Điều này rất tiện để:

Thử nghiệm thoải mái
Viết code tạm hoặc debug
Làm nhiều nhánh song song mà không lo đụng độ

Gộp nhánh (merge)

Khi bạn đã hoàn thành tính năng, bạn sẽ muốn đưa nó vào nhánh chính:

git checkout main
git merge feature/login

Git sẽ tự động hợp nhất các thay đổi nếu không có xung đột. image 16 2.png

Giải quyết xung đột

Nếu cùng một dòng bị sửa ở cả hai nhánh, Git sẽ báo xung đột:

Git chèn các ký hiệu <<<<< HEAD để bạn thấy phần nào bị conflict

<<<<<<< HEAD
Xin chào các bạn!
=======
Chào mừng bạn đến với Git!
>>>>>>> feature/greeting

Bạn cần mở file lên, tự chỉnh sửa thủ công
Sau đó:
```
git add .
git commit
```

Tip: Dùng các công cụ như VS Code, GitKraken hoặc GitLens để resolve conflict trực quan hơn.

3.3. Quản lý nhánh

Khi làm việc nhiều nhánh (branch), bạn cần biết cách liệt kê, đổi tên, xoá, và tạo nhánh đặc biệt. Đây là những lệnh bạn cần biết:

Liệt kê nhánh

git branch – Hiện các nhánh local. Nhánh hiện tại được đánh dấu bằng
git branch -r – Liệt kê các nhánh remote
git branch -a – Tất cả nhánh (local + remote)
git branch -vv – Xem chi tiết theo dõi remote cho từng nhánh

Đổi tên nhánh

Đổi nhánh hiện tại:

git branch -m ten-moi

Đổi nhánh cụ thể:

git branch -m ten-cu ten-moi

Nếu nhánh đã push lên GitHub, cập nhật tên:

git push origin :ten-cu ten-moi

Lưu ý: Đừng quên cập nhật nhánh mặc định trên GitHub nếu đổi tên main hoặc master.

Xóa nhánh không cần thiết

Xoá nhánh local đã được merge:

git branch -d feature/login

Xoá nhánh local chưa merge (cẩn thận!):

git branch -D feature/login

Xoá nhánh từ GitHub/GitLab:

git push origin --delete feature/login

Nhánh không có lịch sử (`orphan branch`)

Khi bạn muốn tạo nhánh trắng hoàn toàn (không kế thừa lịch sử), dùng:

git checkout --orphan ten-nhanh-moi

Thích hợp để:

Tạo landing page riêng (gh-pages)
Reset repo mà vẫn giữ mã nguồn
Bắt đầu lại mà không ảnh hưởng lịch sử cũ 📌 Tips thêm:
Dùng git switch thay cho checkout nếu muốn cú pháp rõ ràng hơn (Git từ 2.23)
Với teamwork, hãy dọn nhánh cũ định kỳ để tránh rối repository

3.4. Nhánh remote

Khi bạn làm việc với GitHub, GitLab… thì ngoài các nhánh local, Git còn một loại nhánh đặc biệt gọi là Remote-tracking branch

Remote-tracking branch

Là nhánh chỉ đọc, dùng để theo dõi trạng thái nhánh ở repository từ xa (remote).
Có dạng: [remote-name]/[branch-name] ví dụ: origin/main
Bạn không thể chỉnh sửa trực tiếp nhánh này, mà Git sẽ tự động cập nhật thông qua git fetch.

Theo dõi nhánh từ xa (set upstream)

Khi bạn tạo nhánh local mới, bạn có thể thiết lập để Git biết “nhánh local này theo dõi nhánh nào ở remote” bằng:

git branch --track mybranch origin/mybranch

Hoặc nếu bạn muốn thay đổi nhánh remote mà local đang theo dõi:

git branch -u origin/dev-feature

Khi bạn clone repo, Git thường tự set sẵn main local theo origin/main.

Tạo nhánh local từ remote

Giả sử trên GitHub đã có nhánh origin/feature-x, nhưng máy bạn chưa có. Hãy tạo nhánh local tương ứng:

git fetch origin
git checkout -b mybranch origin/feature-x

Hoặc Git hỗ trợ cú pháp rút gọn:

git checkout feature-x

Nếu feature-x là một remote-tracking branch có sẵn (từ git fetch), Git sẽ tự tạo nhánh local feature-x và thiết lập theo dõi luôn.

Push nhánh local mới lần đầu lên remote

Sau khi tạo nhánh mới và muốn đẩy lần đầu lên GitHub:

git push -u origin feature-branch

-u (hoặc -set-upstream) giúp Git nhớ mối liên kết giữa local và remote. Sau này bạn chỉ cần dùng git push và git pull không cần chỉ rõ tên nhánh nữa.

3.5. Rebase

Rebase là một tính năng mạnh trong Git giúp bạn:

Tái áp dụng các commit của nhánh hiện tại lên đầu nhánh khác
Tạo lịch sử tuyến tính, mượt mà, không lằng nhằng commit merge Cách hoạt động cơ bản:

git checkout feature-branch
git rebase main

Git sẽ làm 3 bước:

Tạm thời tách commit của feature-branch
Áp dụng các commit mới từ main
Tái áp dụng lại các commit từ feature-branch trên nền mới Kết quả: Lịch sử như thể mọi thứ được thực hiện liên tiếp, không có rẽ nhánh.

Rebase tương tác (interactive)

Dùng khi muốn sửa, gộp hoặc xoá commit thủ công:

git rebase -i HEAD~3

pick: giữ nguyên
reword: sửa commit message
squash: gộp commit với commit trước
drop: xoá commit khỏi lịch sử Rất hữu ích khi bạn dọn lịch sử trước khi push. ⚠️ Lưu ý cực kỳ quan trọng Không dùng rebase cho nhánh đã push công khai và người khác đang dùng! Chỉ rebase với:
Nhánh local bạn đang code một mình
Nhánh chưa push
Trước khi tạo pull request

So sánh: `merge` vs `rebase`


	`merge`	`rebase`
Lịch sử	Có nhánh rẽ & merge	Gọn, tuyến tính như một dòng
Dễ hiểu	Dễ nhìn thấy dòng thời gian	Gọn gàng, nhưng cần hiểu cơ chế
An toàn	An toàn khi làm nhóm	Nguy hiểm nếu không cẩn thận
![[image 19 2.png	image 19 2.png]]

3.6. Các workflow & mô hình nhánh phổ biến

Tại sao cần mô hình nhánh? Mỗi dự án có thể có hàng chục đến hàng trăm nhánh code hoạt động song song. Nếu không có một quy ước rõ ràng, mọi thứ sẽ trở nên hỗn loạn: dễ đụng code, khó kiểm soát, CI/CD dễ gãy. Mô hình nhánh giúp:

Giao tiếp trong team hiệu quả
Code review, release và rollback dễ hơn
Tích hợp CI/CD trơn tru

GitFlow Branching Model

GitFlow là một mô hình quản lý nhánh trong Git được giới thiệu từ năm 2010 bởi Vincent Driessen. Mô hình này định nghĩa rõ vai trò và quy tắc sử dụng từng loại nhánh, đặc biệt phù hợp với các dự án có chu kỳ phát hành rõ ràng (dự án sản phẩm, phần mềm lớn).

**main** branch – Nhánh chính thức
- Luôn chứa code ổn định đã sẵn sàng để đưa lên production.
- Mỗi lần phát hành, Git sẽ gắn tag phiên bản (v1.0, v2.1…) tại đây.
**develop** branch – Nhánh phát triển tổng hợp
- Là nơi tích hợp các tính năng mới (feature) từ các nhánh khác.
- Luôn chứa code mới nhất, chưa sẵn sàng triển khai, nhưng đã qua unit test.
**feature/*** – Nhánh tính năng
- Mỗi tính năng sẽ tách ra một nhánh riêng từ develop:
```
git checkout -b feature/login develop
```
- Sau khi hoàn thành, merge lại vào develop.
**release/*** – Nhánh chuẩn bị phát hành
- Khi muốn đóng gói để release, bạn tách nhánh từ develop:
```
git checkout -b release/v1.0 develop
```
- Chỉ dùng để fix bug nhỏ, update docs, CI config, không thêm tính năng.
- Merge vào cả main và develop sau khi xong.
**hotfix/*** – Nhánh sửa lỗi khẩn cấp
- Khi production gặp lỗi, tạo nhánh từ main:
```
git checkout -b hotfix/fix-crash main
```
- Sau khi sửa xong, merge lại vào cả main và develop.

Trunk-based Development

Mọi thứ diễn ra gần như trực tiếp trên nhánh main, giống như code chạy đường đua F1.

Commit thường xuyên, tích hợp sớm.
Dùng feature flags để ẩn/hiện tính năng mới.
Cần CI/CD mạnh, tránh gây lỗi production.
Phù hợp với DevOps, startup, microservice, nơi triển khai nhiều lần mỗi ngày.

GitHub Flow

Mỗi tính năng là một nhánh riêng, mở Pull Request rồi merge vào main sau khi đã được review. Quy trình:

git checkout -b feature/login main
Commit, push lên GitHub.
Mở Pull Request.
Code được review, test → merge.
Triển khai ngay sau khi merge.

Dễ học, dễ triển khai.
Rất hợp cho dự án web, ứng dụng triển khai liên tục (CD).
Không rõ ràng khi cần quản lý nhiều môi trường (dev, staging, production) hoặc chu kỳ release chính thức.

GitLab Flow

Kết hợp GitHub Flow và môi trường triển khai thật:

Code sẽ đi qua main → staging → production

Có thêm các nhánh như staging, pre-prod, production
Dễ rollback, dễ kiểm soát nhiều môi trường.
Thay vì chỉ dùng tag để đánh dấu, ta dùng các nhánh đại diện môi trường.
Rất hợp với doanh nghiệp vừa & lớn, làm sản phẩm dài hạn có nhiều team triển khai theo từng môi trường khác nhau.

So sánh các mô hình phổ biến


Mô hình	Mô tả	Phù hợp với
GitFlow	Phân tách `feature`, `develop`, `release`, `hotfix`, `main`	Dự án có chu kỳ phát hành dài, nhiều giai đoạn
GitHub Flow	Nhánh `main` luôn deploy được, mỗi feature tạo nhánh riêng, merge bằng pull request	Dự án triển khai liên tục (CI/CD)
Trunk-Based	Mọi người làm việc trực tiếp với `main` hoặc tạo nhánh nhỏ, merge sớm trong ngày	Team agile, build/test tự động hóa cao
GitLab Flow	Kết hợp GitFlow + GitHub Flow, hỗ trợ triển khai theo môi trường (env/staging/prod)	Dự án cần kiểm soát và tích hợp hệ thống
Cách chọn mô hình cho nhóm

Team nhỏ hoặc học sinh: Dùng GitHub Flow → dễ hiểu, dễ triển khai
Team nhiều thành viên & cần quản lý release: Dùng GitFlow
DevOps/CI-CD mạnh: Dùng Trunk-Based hoặc GitLab Flow Quan trọng nhất: mọi người trong team phải hiểu và tuân thủ cùng một quy ước

4. Cộng tác qua GitHub

4.1. Thiết lập tài khoản

Bước 1 – Đăng ký tài khoản GitHub

Truy cập https://github.com và tạo tài khoản.
Chọn username cẩn thận vì nó sẽ xuất hiện trong mọi URL repo (VD: github.com/username/project-name)
Nhớ xác minh email để được kích hoạt đầy đủ tính năng như push/pull, comment, tạo repo riêng tư… Bước 2 – Thiết lập xác thực (nên dùng SSH) GitHub hỗ trợ:
HTTPS: dễ dùng nhưng hay phải nhập username/password.
SSH: an toàn hơn, không cần nhập lại. Tạo SSH key:

ssh-keygen -t ed25519 -C "email@example.com"

Sau đó:

Đăng nhập vào GitHub trên trình duyệt.
Đi tới Settings → SSH and GPG keys.
Nhấp vào New SSH key hoặc Add SSH key.
Nhập Title (ví dụ: “Máy tính Windows của tôi”).
Dán khóa công khai đã sao chép vào trường Key.
Nhấp Add SSH key. Test thử:

ssh -T git@github.com

Nếu thành công, bạn sẽ thấy thông báo:

Hi your_username! You’ve successfully authenticated, but GitHub does not provide shell access. Bước 3 – Tuỳ chỉnh hồ sơ cá nhân

Cập nhật avatar → tạo dấu ấn chuyên nghiệp.
Thêm bio, link LinkedIn, website nếu có.
Bật chế độ public contributions nếu muốn khoe lịch sử commit trên profile. Bước 4 – Bảo mật tài khoản với 2FA (Xác thực hai lớp)
Vào Settings → Password and Authentication để bật 2FA.
Dùng ứng dụng như:
- Google Authenticator
- Authy
- 1Password hoặc khóa vật lý YubiKey

Đừng quên kiểm soát quyền các app bên thứ ba trong phần Applications → Authorized OAuth Apps.

4.2. Quy trình Fork & Pull Request

Khi bắt đầu tham gia một dự án mã nguồn mở hay muốn đóng góp cho một repo không thuộc sở hữu của mình, Fork & Pull Request là quy trình phổ biến và an toàn nhất mà bạn nên nắm vững. 1. Fork repository – Tạo bản sao riêng cho mình Truy cập GitHub và vào trang chính của repository mà bạn muốn đóng góp. Nhấn nút Fork ở góc phải phía trên. GitHub sẽ tạo cho bạn một bản sao repo đó vào tài khoản cá nhân, cho phép bạn chỉnh sửa một cách độc lập. 2. Clone repo về máy local Sau khi fork, bạn cần tải mã nguồn về máy tính của mình bằng lệnh:

git clone https://github.com/<username-của-bạn>/<tên-repository>.git
cd <tên-repository>

Để đảm bảo bạn vẫn theo dõi repo gốc (repository chính), hãy thêm một remote tên là upstream:

git remote add upstream https://github.com/<tên-chính-chủ>/<tên-repository>.git

3. Tạo nhánh tính năng của bạn (feature branch) Việc tạo nhánh mới giúp bạn tách biệt phần công việc hiện tại với main, tránh ảnh hưởng đến lịch sử commit chính.

git checkout -b fix-login-bug

Tên nhánh nên ngắn gọn, mang ý nghĩa rõ ràng (ví dụ: feature/add-navbar, fix/login-error,…) 4. Thực hiện thay đổi & đẩy code Sau khi chỉnh sửa xong file, bạn cần lưu lại thay đổi và gửi lên GitHub bằng:

git add .
git commit -m "Fix lỗi không đăng nhập khi sai mật khẩu"
git push origin fix-login-bug

5. Tạo Pull Request Truy cập lại GitHub → vào repo bạn vừa push code → chọn “New Pull Request”. Chọn nhánh bạn vừa tạo ở bên trái (source) và nhánh main của repo gốc ở bên phải (target). Hãy điền tiêu đề và phần mô tả rõ ràng:

Tiêu đề: Fix lỗi xác thực khi người dùng nhập sai mật khẩu
Mô tả: Giải thích lỗi, cách bạn sửa, đã test chưa, ảnh hưởng đến phần nào khác không… 6. Thảo luận & cập nhật Chủ repository có thể review và yêu cầu bạn chỉnh sửa thêm. Bạn chỉ cần update code và push lại vào nhánh cũ, pull request sẽ được cập nhật tự động. Nếu được chấp nhận, phần thay đổi của bạn sẽ được merge vào dự án chính.

4.3. Quản lý repository trên GitHub

Sau khi bạn đã làm quen với Git cơ bản, bước tiếp theo là biết cách quản lý một repository trên GitHub. Dù là dự án cá nhân hay làm việc nhóm, việc cấu hình repo đúng cách sẽ giúp quá trình phát triển mượt mà hơn. 1. Tạo và cấu hình repository Bạn có thể bắt đầu từ nút ”+” → New repository để tạo repo mới. Đặt tên, mô tả dự án, chọn chế độ công khai hoặc riêng tư, và chọn tick để khởi tạo với README nếu cần. Nếu bạn làm việc nhóm, hãy:

Truy cập Settings → Collaborators để mời thêm người.
Cấp quyền commit, review hoặc chỉ đọc tuỳ theo vai trò. 2. Tài liệu và hướng dẫn Một dự án chuyên nghiệp không thể thiếu phần tài liệu định hướng:
README.md: Mô tả tổng quan về dự án, cách cài đặt, ví dụ sử dụng.
CONTRIBUTING.md: Hướng dẫn cách đóng góp, quy tắc viết commit, gửi PR.
CODE_OF_CONDUCT.md: Định ra hành vi được chấp nhận trong cộng đồng (đặc biệt quan trọng với dự án mã nguồn mở). Các file này nên được đặt ngay trong thư mục gốc của repository. 3. Tạo mẫu Issue và Pull Request Khi nhóm bạn bắt đầu có nhiều thành viên đóng góp, nên có các mẫu issue và PR chuẩn hóa bằng cách đặt chúng trong thư mục .github/.
Issue template: Cho phép người dùng phân loại lỗi hoặc đề xuất (bug report vs feature request).
Pull request template: Hướng dẫn người tạo PR viết mô tả thay đổi, nêu rõ phần ảnh hưởng, checklist đã test chưa. Điều này giúp bạn quản lý chất lượng dễ dàng và thống nhất quy trình cộng tác. 4. Thiết lập branch và bảo vệ Để bảo vệ nhánh chính (main hoặc master), bạn nên:
Truy cập Settings → Branches
Bật branch protection rules: yêu cầu pull request, chạy CI/CD, review trước khi merge
Vô hiệu hóa push trực tiếp vào nhánh chính nếu cần Việc này đảm bảo chỉ có code đã kiểm tra kỹ mới được merge, giảm thiểu lỗi khi deploy.

4.4. Organization & Teams

Khi làm việc trong một nhóm lớn hoặc dự án nhiều repository, việc quản lý thủ công bằng tài khoản cá nhân là không đủ. GitHub Organization chính là giải pháp được thiết kế để hỗ trợ cộng tác hiệu quả, phân quyền rõ ràng và bảo mật tốt hơn.

Tạo và quản lý Organization

Organization là một “tài khoản tổ chức” có thể quản lý nhiều repository và người dùng cùng lúc. Nó phù hợp cho:

Các công ty, doanh nghiệp công nghệ
Dự án lớn trong học thuật hoặc mã nguồn mở
Nhóm sinh viên đang làm khóa luận, capstone, hoặc sản phẩm startup Các bước tạo:

Nhấn vào dấu ”+” ở góc phải trên GitHub → chọn New organization
Chọn gói Free, Team, hoặc Enterprise
Nhập tên tổ chức, email liên hệ và thông tin chủ sở hữu Nếu bạn đang phát triển dự án cá nhân nhưng muốn chuyển sang tổ chức, hãy vào: Settings → Options → Transfer ownership để chuyển repository sang Organization.

Quản lý Teams & phân quyền

Bên trong một Organization, bạn có thể chia người dùng thành các team khác nhau (như “Backend team”, “UI/UX”, “QA”). Các bước tạo Team:

Vào Organization → Teams → New team
Đặt tên, mô tả, cài đặt quyền riêng tư
Thêm thành viên vào team
Cấp quyền truy cập vào repository với 3 mức:
- Read: Chỉ được xem, clone
- Write: Được push code
- Admin: Quản lý cài đặt repo, cấp quyền, xóa Team lồng nhau: Team con sẽ kế thừa quyền từ team cha – rất tiện cho tổ chức lớn.

Theo dõi hoạt động & bảo mật

GitHub hỗ trợ Audit log – nhật ký hoạt động ghi lại tất cả hành động trong tổ chức:

Ai làm gì, lúc nào (user, action, timestamp)
Theo dõi việc thêm, xoá thành viên
Giám sát truy cập vào các repo
Xuất nhật ký để phân tích Truy cập tại Settings → Audit log Ngoài ra, Dependabot và Security alerts sẽ tự động cảnh báo nếu dự án có dependency chứa lỗ hổng bảo mật – rất hữu ích trong các project học thuật lẫn sản phẩm thật.

4.5. Mẹo làm việc hiệu quả

Làm việc với GitHub không chỉ là biết clone và commit, mà còn là tối ưu hóa quy trình cộng tác sao cho mượt mà, rõ ràng và tránh sai sót. Dưới đây là 3 mẹo nhỏ nhưng cực kỳ hữu ích giúp bạn làm việc chuyên nghiệp hơn, đặc biệt trong môi trường nhóm hoặc open source! 1. Dùng Draft Pull Request để nhận feedback sớm Bạn đang code dang dở nhưng vẫn muốn nhận phản hồi từ mentor hoặc teammate? Thay vì đợi làm xong rồi mới gửi Pull Request, hãy dùng chế độ Draft Pull Request để:

Cho reviewer biết là bạn vẫn đang phát triển
Nhận feedback sớm về hướng đi, logic
Tránh làm mất thời gian review cho những đoạn code chưa hoàn chỉnh → Khi tạo Pull Request, hãy chọn “Create draft pull request” thay vì “Create pull request”. 2. Tạo Checklist khi Review Code Bạn từng gặp tình huống review code mà quên check test? Hay merge một đoạn code nhưng sau đó mới phát hiện lỗi bảo mật? Hãy xây dựng một Review Checklist cho nhóm, ví dụ:
Đã viết test đầy đủ?
Tuân theo coding convention chưa?
Có ảnh hưởng đến performance?
Xử lý lỗi đầu vào tốt không? Gợi ý: Bạn có thể gắn checklist này vào template của Pull Request để mỗi thành viên đều phải tự rà lại trước khi gửi. 3. Luôn đồng bộ fork để tránh xung đột Nếu bạn làm việc trên một bản fork của dự án open source, đừng quên đồng bộ thường xuyên với repository gốc (upstream). Việc này giúp bạn:
Luôn cập nhật với code mới nhất
Giảm thiểu xung đột khi tạo PR
Làm việc như một contributor chuyên nghiệp Cách làm:

git remote add upstream https://github.com/original/repo.git
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

4.6. GitHub Desktop

Nếu bạn không hợp gu với mấy dòng lệnh trên Terminal thì GitHub Desktop sẽ là người bạn đồng hành cực kỳ tuyệt vời. Ứng dụng này giúp bạn thao tác Git trên giao diện đồ họa (GUI) đẹp mắt và dễ dùng – phù hợp cho sinh viên, người học lập trình hoặc ai đang làm project nhóm nhỏ. image 28 2.png GitHub Desktop là ứng dụng chính chủ của GitHub, giúp bạn thao tác như:

Clone / tạo repo
Quản lý commit, pull, push
Quản lý nhánh (branch)
Giải quyết xung đột khi merge

… tất cả đều thông qua giao diện kéo thả, click chuột, không cần gõ dòng lệnh.

[TODO chèn ảnh]

Dưới đây là cách tải về và sử dụng:

Tải về và cài đặt tại desktop.github.com
Đăng nhập bằng tài khoản GitHub
Clone repository có sẵn hoặc tạo mới một repo
Thay đổi code trong máy bạn, rồi commit ngay trên giao diện
Push thay đổi lên GitHub chỉ với một nút bấm

5. Tùy chỉnh và mở rộng Git

5.1. Cấu hình nâng cao (.gitconfig)

Khi bạn đã quen với các lệnh cơ bản, thì .gitconfig chính là nơi để bạn nâng cấp trải nghiệm Git của mình lên một tầm cao mới. 1. Thiết lập nhánh mặc định Từ Git 2.28 trở lên, bạn có thể thay đổi tên nhánh mặc định từ master thành main khi tạo repository mới:

git config --global init.defaultBranch main

Việc này giúp đồng bộ với chuẩn mới của GitHub và nhiều nền tảng khác. 2. Chuẩn hóa commit message với template Một dự án tốt không chỉ có code tốt mà còn cần lịch sử commit rõ ràng. Bạn có thể tạo một file .gitmessage.txt để làm mẫu commit:

git config --global commit.template ~/.gitmessage.txt

Ví dụ nội dung mẫu:

# Tiêu đề: Tóm tắt ngắn gọn (< 50 ký tự)
# Nội dung: Giải thích thay đổi và lý do
# (Tối đa 72 ký tự/dòng)
# Issue liên quan: #123

Với template này, bạn và team sẽ dễ đọc lại commit sau một thời gian dài. 3. Tích hợp VSCode làm công cụ merge & diff Nếu bạn sử dụng VSCode, đây là combo không thể thiếu để xử lý merge conflict hoặc so sánh code:

git config --global merge.tool vscode
git config --global diff.tool vscode
git config --global difftool.vscode.cmd "code --wait --diff $LOCAL $REMOTE"
git config --global mergetool.vscode.cmd "code --wait $MERGED"

Từ giờ mỗi khi có conflict, Git sẽ mở VSCode với giao diện dễ nhìn, dễ chọn. 4. Thiết lập proxy và lưu thông tin đăng nhập Với những bạn làm việc trong mạng nội bộ (ví dụ công ty, trường học có tường lửa), bạn có thể cần cấu hình proxy như sau:

git config --global http.proxy http://proxy.example.com:8080
git config --global https.proxy https://proxy.example.com:8080

Ngoài ra, để không phải nhập mật khẩu GitHub mỗi lần, bạn có thể:

git config --global credential.helper store    # Lưu vĩnh viễn
git config --global credential.helper cache    # Lưu tạm
git config --global credential.helper 'cache --timeout=3600' # Timeout 1 giờ

5.1. Git Attributes (.gitattributes)

.gitattributes cho phép bạn quy định hành vi của Git với từng loại file theo pattern. Cú pháp rất đơn giản:

pattern attr1 attr2 ...

Ví dụ:

# Tự động chuẩn hóa line ending
* text=auto
# Đánh dấu file nhị phân
*.png binary
*.jpg binary
# Giữ bản local khi merge file cấu hình
config.xml merge=ours

Kiểm soát line ending giữa các hệ điều hành Nếu bạn đang làm việc nhóm với người dùng Windows, Mac, Linux cùng lúc, line ending (CRLF vs LF) sẽ gây đau đầu. Git Attributes có thể giúp:

# Chuẩn hóa về LF trong repository
*.txt text
*.java text
*.md text
# Nhưng khi checkout trên Windows thì dùng CRLF
*.bat text eol=crlf
# Hoặc giữ nguyên LF
*.sh text eol=lf

💡 Mẹo: Sử dụng * text=auto để Git tự động phát hiện và xử lý. Đánh dấu file binary và tránh merge nhầm Đối với file nhị phân như ảnh hoặc file nén, Git không nên merge nội dung:

*.png binary
*.zip binary

Bạn cũng có thể thiết lập cách merge cụ thể:

# Giữ cấu hình local (ưu tiên của bạn)
config.xml merge=ours
# Giữ phiên bản từ người khác (nhánh đang merge)
generated-code.js merge=theirs

Clean/Smudge Filters Clean/smudge filters cho phép bạn biến đổi file khi thêm vào Git hoặc khi lấy ra. Một vài ví dụ thú vị:

# File .c sẽ được định dạng trước khi commit
*.c filter=indent
# Thêm ngày tháng vào file source code Java
*.java filter=keyword

Thiết lập trong .gitconfig:

[filter "indent"]
  clean = indent
  smudge = cat
[filter "keyword"]
  clean = sed "s/\\$Date[^\\$]*\\$/\\$Date\\$/"
  smudge = sed "s/\\$Date\\$/\\$Date: $(date)\\$/"

5.1. Git Hooks – Tự động hóa

Git Hooks là các đoạn script được Git tự động chạy tại những thời điểm nhất định, như trước khi commit, khi push code, hoặc khi server nhận được thay đổi. Các file hook nằm trong thư mục .git/hooks/, thường đi kèm file .sample. Để kích hoạt:

# Bỏ đuôi .sample và cấp quyền thực thi
mv pre-commit.sample pre-commit
chmod +x pre-commit

Client-side Hooks (chạy trên máy cá nhân)


Tên Hook	Thời điểm chạy và mục đích
`pre-commit`	Chạy trước khi commit, thường dùng để lint, chạy test
`prepare-commit-msg`	Chạy trước khi hiển thị ô nhập commit message
`commit-msg`	Kiểm tra nội dung message, format, prefix…
`post-commit`	Chạy ngay sau khi commit, ví dụ để gửi thông báo
`pre-push`	Kiểm tra code hoặc test lại trước khi push
💡 Rất hữu ích để kiểm tra chất lượng code mà không cần nhờ CI từ xa!
Server-side Hooks (chạy trên máy chủ)

---	---
Tên Hook	Mô tả
`pre-receive`	Chạy khi server nhận yêu cầu push
`update`	Chạy riêng cho từng ref được cập nhật
`post-receive`	Chạy sau khi push thành công, dùng để kick CI/CD
💡 Server-side hooks không thể bị người dùng bỏ qua, nhưng chỉ cài đặt được nếu bạn có quyền quản trị server Git.
Một số ứng dụng phổ biến của Git Hooks

Từ chối commit nếu không có ticket ID
Kiểm tra định dạng message: “feat: add search bar”
Tự động chạy unit test trước khi push
Trigger build hoặc CI/CD sau khi code được push
Gửi thông báo Slack hoặc email khi commit mới được tạo Ví dụ: pre-commit để kiểm tra code Python bằng **flake8**

#!/bin/sh
echo "👉 Checking Python style with flake8..."
flake8 .
[ $? -ne 0 ] && echo "❌ Style errors found! Commit aborted." && exit 1

5.1. Alias & Scripts

Gõ git status, git checkout -b, git log --oneline --graph lặp đi lặp lại mỗi ngày? Bạn hoàn toàn có thể rút gọn chỉ còn vài ký tự với Git Alias – một tính năng đơn giản nhưng cực kỳ hữu dụng cho mọi lập trình viên muốn tăng hiệu suất làm việc. Git Alias cho phép bạn đặt tên rút gọn cho những lệnh Git dài hoặc phức tạp. Các alias này được cấu hình trong file ~/.gitconfig, ví dụ:

[alias]
  st = status
  co = checkout
  br = branch -v
  cm = commit -m
  l  = log --oneline --graph --decorate
  unstage = restore --staged
  last = log -1 HEAD
  visual = !gitk

Sau khi cấu hình, bạn chỉ cần gõ git st thay vì git status – vừa nhanh, vừa dễ nhớ. Alias nâng cao với hàm shell Git Alias không chỉ dừng lại ở việc rút gọn lệnh đơn. Bạn hoàn toàn có thể định nghĩa một chuỗi lệnh hoặc hàm shell để làm nhiều việc hơn nữa. Ví dụ:

[alias]
  # Tạo nhánh mới và chuyển sang nhánh đó
  nb = "!f() { git checkout -b $1; }; f"
  # Xoá tất cả nhánh đã merge vào nhánh hiện tại
  cleanup = "!git branch --merged | grep -v '\\*' | xargs -n 1 git branch -d"
  # Kéo thay đổi từ upstream về nhánh hiện tại
  sync = "!f() { git pull upstream $(git rev-parse --abbrev-ref HEAD); }; f"
  # Log đẹp hơn, dễ nhìn hơn
  graph = log --graph --pretty=format:'%C(red)%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset'

Chú ý: Những alias bắt đầu bằng ! được hiểu là shell command. Tips nhỏ, lợi ích to


Trước alias	Sau alias	Tiết kiệm
`git status`	`git st`	6 ký tự mỗi lần
`git checkout -b login`	`git nb login`	Tự động hóa
`git log --graph ...`	`git graph`	Nhìn dễ hơn, đỡ gõ lại
Alias sẽ đặc biệt hữu ích khi bạn thao tác nhiều nhánh, debug lỗi, hoặc làm việc nhóm – vừa thống nhất, vừa tiết kiệm thời gian.
Mẹo thử nhanh
Bạn có thể tự tạo ngay alias mà không cần chỉnh `.gitconfig` bằng lệnh:

git config --global alias.st status

6. Thực hành với Git

Sau khi tìm hiểu toàn bộ các khái niệm quan trọng về Git – từ thao tác commit, branch, rebase đến GitHub Flow và GitHub Desktop – giờ là lúc bạn áp dụng chúng vào thực tế. Dưới đây là ba phần bài tập thực hành theo mức độ từ cơ bản đến nâng cao, giúp bạn củng cố kiến thức một cách hệ thống.

Thực hành 1: Làm quen với Git cơ bản

1. Cài đặt và cấu hình Git

Mục tiêu: Cài đặt Git và cấu hình cá nhân cơ bản

Cài đặt Git theo hệ điều hành của bạn (Windows/macOS/Linux)

Cấu hình tên và email để gắn vào các commit:

git config --global user.name "Tên của bạn"
git config --global user.email "email@example.com"

Tạo alias để tiết kiệm thời gian gõ lệnh:

git config --global alias.st status
git config --global alias.l "log --oneline"

Kiểm tra toàn bộ cấu hình:
```
git config --list
```

2. Tạo và chuẩn bị repository

Mục tiêu: Khởi tạo một repo Git mới và thực hiện commit đầu tiên

Tạo thư mục dự án:
```
mkdir git-practice && cd git-practice
```
Khởi tạo Git repository:
```
git init
```
Tạo file README.md và viết một đoạn giới thiệu ngắn.
Kiểm tra trạng thái repo:
```
git status
```

Đưa file vào staging area và commit:

git add README.md
git commit -m "Khởi tạo dự án và thêm README"

3. Thực hành với commit và lịch sử

Mục tiêu: Làm quen với commit, xem lại lịch sử thay đổi

Tạo file read_data.py đơn giản:

print("Đọc dữ liệu từ file...")

Commit file:

git add read_data.py
git commit -m "Thêm file read_data.py"

Chỉnh sửa README.md để bổ sung mô tả dự án, sau đó commit tiếp.

Xem lại lịch sử commit bằng các lệnh:

git log
git log --oneline
git show <commit-id>

4. Thực hành hoàn tác thay đổi

Mục tiêu: Biết cách phục hồi và điều chỉnh khi lỡ tay thay đổi hoặc commit sai

Thay đổi file read_data.py nhưng chưa add vào stage.
Hoàn tác thay đổi về phiên bản cũ:
```
git restore read_data.py
```
Thêm một thay đổi mới, đưa vào stage, rồi loại bỏ khỏi stage:
```
git restore --staged read_data.py
```
Cuối cùng, sửa lại nội dung commit gần nhất (nếu quên ghi message chẳng hạn):
```
git commit --amend -m "Sửa lại nội dung commit gần nhất"
```

Thực hành 2: Branch, Merge & GitFlow

1. Thực hành phân nhánh cơ bản

Mục tiêu: Hiểu cách tạo, chuyển và làm việc trên nhánh Git

Sử dụng lại repo git-practice từ bài trước hoặc khởi tạo mới
Tạo nhánh mới:
```
git branch feature-a
```
Chuyển sang nhánh:
```
git checkout feature-a
```
Tạo file feature-a.txt, ghi nội dung tuỳ chọn rồi commit
Quay lại nhánh main và quan sát sự khác biệt
Thử lệnh rút gọn:
```
git checkout -b new-feature
```

2. Gộp nhánh và xử lý xung đột

Mục tiêu: Làm quen với merge và giải quyết xung đột

Trên nhánh main, tạo file common.txt với nội dung “Dòng 1: Nội dung từ main” và commit
Chuyển sang feature-a, tạo lại common.txt với nội dung khác và commit
Quay lại main, thực hiện merge:
```
git merge feature-a
```
Nếu xảy ra xung đột, Git sẽ đánh dấu các phần khác biệt – bạn cần chỉnh sửa file thủ công để giữ lại nội dung mong muốn
Sau khi sửa, hoàn tất merge bằng:
```
git add .
git commit
```

3. Thực hành với rebase

Mục tiêu: Làm quen với git rebase và so sánh với merge

Tạo nhánh feature-b từ main và thực hiện 2-3 commit
Quay lại main, tạo thêm 1-2 commit khác
Trở lại feature-b, thực hiện rebase:
```
git rebase main
```
Nếu có xung đột, chỉnh sửa và tiếp tục rebase:
```
git add .
git rebase --continue
```
Dùng lệnh sau để xem lịch sử:
```
git log --graph --oneline
```
So sánh sự khác biệt trong lịch sử commit khi dùng merge và rebase

4. Mô phỏng quy trình GitFlow

Mục tiêu: Mô phỏng quy trình GitFlow gồm develop, feature, release và hotfix

Tạo repository mới gitflow-practice
Tạo nhánh develop từ main
Tạo nhánh feature/login, commit thay đổi nhỏ, merge vào develop:
```
git merge --no-ff feature/login
```
Tạo nhánh release/v1.0 từ develop, sửa lỗi và merge vào main + develop, đồng thời tạo tag:
```
git tag v1.0
```
Mô phỏng tình huống khẩn cấp bằng cách tạo nhánh hotfix, sửa lỗi và merge lại cả main lẫn develop

Thực hành 3: Làm việc nhóm và GitHub

1. Fork và Clone dự án mã nguồn mở

Mục tiêu: Làm quen quy trình đóng góp vào dự án người khác

Tìm một dự án mã nguồn mở phù hợp (ví dụ: thư viện JS, template HTML…)
Nhấn nút Fork để tạo bản sao về tài khoản GitHub của bạn

Clone dự án về máy:

git clone https://github.com/your-username/project-name.git

Thiết lập remote upstream để cập nhật từ repository gốc:

git remote add upstream https://github.com/original/project.git
git remote -v

2. Tạo và đóng góp Pull Request

Mục tiêu: Gửi pull request cải thiện nhỏ vào repo đã fork

Tạo nhánh mới từ main để sửa lỗi/tính năng:
```
git checkout -b fix-typo
```
Chỉnh sửa nội dung (ví dụ sửa lỗi chính tả, cập nhật README, thêm comment)

Commit và push:

git add .
git commit -m "Fix typo in README"
git push origin fix-typo

Truy cập GitHub, tạo Pull Request từ nhánh fork về repository gốc
Viết mô tả chi tiết trong PR – đây là nơi thể hiện trách nhiệm và chuyên nghiệp ✨

3. Thực hành Code Review

Mục tiêu: Biết cách đánh giá, phản hồi Pull Request của người khác

Tìm một Pull Request đang mở trong dự án bạn quan tâm
Đọc kỹ code, hiểu các thay đổi
Thêm comment trực tiếp vào dòng code (nếu thấy điểm cần góp ý)
Viết nhận xét tổng thể ở cuối PR (Approve/Request Changes/Comment)
Nếu học nhóm, review PR của nhau để luyện phản biện kỹ thuật và giao tiếp nhóm

🛠️ 4. Quản lý dự án với GitHub

Mục tiêu: Thiết lập một dự án GitHub cá nhân đầy đủ cấu trúc

Tạo một repository mới như "my-cv-site", "blog-template", "mini-app"…
Viết file README.md mô tả dự án và hướng dẫn cài đặt
Thêm file CONTRIBUTING.md để hướng dẫn cách tham gia đóng góp
Tạo Issue templates cho báo lỗi và đề xuất tính năng
Tạo một vài issue mẫu để làm quen với việc quản lý task
Kích hoạt GitHub Pages (nếu là dự án tài liệu/website) để xuất bản trực tuyến!

Tổng kết

Chúc mừng bạn đã đi đến chặng cuối trong hành trình tìm hiểu Git & GitHub! Từ những bước cơ bản như cài đặt Git, tạo repository, commit file, đến các thao tác nâng cao như phân nhánh, gộp nhánh, rebase, xử lý xung đột hay đóng góp vào dự án mã nguồn mở – bạn đã dần hình thành được tư duy làm việc chuyên nghiệp với Git. Bên cạnh đó, bạn cũng đã được thực hành cách sử dụng GitHub trong môi trường thực tế: tạo Pull Request, review code, quản lý nhóm và tổ chức dự án bằng README, Issue templates, và thậm chí là mô phỏng GitFlow hay sử dụng GitHub Pages. Git không chỉ là công cụ quản lý mã nguồn, mà còn là nền tảng giúp bạn cộng tác, chia sẻ trách nhiệm và phát triển kỹ năng làm việc nhóm. Khi đã quen thuộc với các thao tác thường ngày, bạn có thể khám phá sâu hơn về Git alias, Git hook hay cấu hình .gitconfig, .gitattributes để tùy biến trải nghiệm. Việc luyện tập thường xuyên sẽ giúp bạn không chỉ sử dụng Git thành thạo mà còn trở nên chuyên nghiệp hơn trong mọi dự án lập trình. Từ đây, bạn có thể tự tin tham gia vào các dự án mã nguồn mở nhỏ, tạo một repository showcase để làm đẹp CV, hoặc đơn giản là giúp bạn học cùng lớp làm quen với Git để teamwork hiệu quả hơn. Nếu bạn đam mê xây dựng sản phẩm thực tế, việc học thêm về CI/CD, Test Automation hay DevOps là những bước đi tiếp theo cực kỳ tiềm năng. Cảm ơn bạn đã học cùng mình! Chúc bạn thành công và hẹn gặp lại trong những chủ đề công nghệ thú vị khác.

Tài liệu tham khảo

Bài giảng về Git & Github for version control của Ph.D Nguyễn Thái Hà trong khóa học AIO25 của AI VietNam Pro Git Book: https://gitscm.com/book/en/v2 Git: https://git-scm.com/doc GitHub: https://docs.github.com GitHub Guides: https://guides.github.com Atlassian Git Tutorials – Các bài học thực hành về Git theo mô hình làm việc nhóm. GitHub Learning Lab – Khoá học tương tác miễn phí từ GitHub để thực hành với Pull Request, Issues và Actions.

An Hoai Thai's Notes

Trong bài này

M01W2.5_Git & Github for version control

Table of contents