Hướng dẫn sử dụng GitHub: Từ cơ bản đến nâng cao

Chào các bạn,

Quản lý mã nguồn là một phần quen thuộc trong công việc phát triển phần mềm. Trong đó, GitHub là một nền tảng phổ biến giúp chúng ta lưu trữ, theo dõi sự thay đổi của mã nguồn và phối hợp làm việc cùng nhau.

Bài viết này sẽ giới thiệu cách sử dụng GitHub đi từ các thao tác cơ bản đến một số kỹ thuật mở rộng, giúp bạn vận hành dự án một cách trơn tru.

0. Chuẩn bị ban đầu

Trước khi bắt đầu, hãy chắc chắn bạn đã chuẩn bị những điều cơ bản.

Cài đặt Git:

Truy cập git-scm.com và tải Git cho hệ điều hành của bạn.

Tạo tài khoản GitHub:

Đăng ký tại github.com nếu chưa có tài khoản.

Cấu hình Git cục bộ:

Sau khi cài đặt Git, bạn cần thiết lập tên người dùng và email (những thông tin này sẽ được gắn vào mỗi commit):

1
2
3
4
5

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

# Để kiểm tra cấu hình
git config --list

1. Các khái niệm cốt lõi

Trước khi đi vào các dòng lệnh, chúng ta điểm qua một vài khái niệm thường gặp:

• Repository (Kho lưu trữ): Nơi chứa toàn bộ mã nguồn, tài liệu và lịch sử thay đổi của dự án. Có thể là công khai (public) hoặc riêng tư (private).

• Commit: Một điểm lưu trạng thái của mã nguồn. Mỗi commit đi kèm với một thông điệp (message) mô tả sự thay đổi và một mã định danh (hash) duy nhất.

• Branch (Nhánh): Một phiên bản độc lập của repository. Nhánh giúp bạn phát triển tính năng mới hoặc sửa lỗi mà không làm ảnh hưởng đến mã nguồn chính (thường là nhánh main hoặc master).

• Remote: Một phiên bản của repository nằm trên máy chủ (như GitHub). Mặc định, repository được sao chép về máy địa phương được kết nối với một remote có tên origin.

• Pull Request (PR): Yêu cầu gộp (merge) các thay đổi từ nhánh này vào nhánh khác. PR cho phép các thành viên nhóm xem xét (review) mã trước khi gộp.

2. Các thao tác cơ bản

Đây là những lệnh bạn sẽ sử dụng thường xuyên trong quá trình làm việc cá nhân.

2.1 Khởi tạo hoặc tải dự án

1
2
3
4
5
6
7
8
9

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

# Tải một repository từ GitHub về máy tính
git clone <địa_chỉ_repository>

# Ví dụ:
git clone https://github.com/username/my-project.git
cd my-project

2.2 Lưu lại các thay đổi

Sau khi chỉnh sửa mã nguồn, bạn cần đưa các file thay đổi vào trạng thái chờ (staging) và lưu chúng lại (commit).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Xem trạng thái hiện tại
git status

# Đưa một hoặc nhiều file vào staging area
git add <tên_file>

# Hoặc đưa toàn bộ thay đổi vào staging
git add .

# Tạo commit với thông điệp rõ ràng
git commit -m "Mô tả thay đổi của bạn"

2.3 Viết commit messages hiệu quả

Commit message tốt giúp bạn và nhóm hiểu rõ tại sao sự thay đổi được thực hiện. Thay vì viết vội vã, hãy dành thời gian cho mô tả rõ ràng.

1
2
3
4
5
6
7
8

# Không nên: Viết tóm tắt không rõ ràng
git commit -m "fix"
git commit -m "update"

# Nên: Viết chi tiết và cụ thể
git commit -m "Fix email validation in login form"
git commit -m "Add dark mode toggle to settings page"
git commit -m "Update dependencies to latest stable version"

Quy tắc commit message tốt:

• Dòng đầu: Tóm tắt ngắn gọn (50 ký tự), sử dụng dạng mệnh lệnh (ví dụ: “Fix” thay vì “Fixed” hoặc “Fixes”)
• Dòng thứ 2: Để trống
• Dòng thứ 3 trở đi: Mô tả chi tiết (nếu cần), giải thích tại sao thay đổi được thực hiện

1
2
3
4
5
6
7

# Ví dụ commit message tốt
git commit -m "Refactor authentication module

- Simplify token validation logic
- Improve error handling for expired tokens
- Add unit tests for edge cases
- Update API documentation"

2.4 Đồng bộ với GitHub

1
2
3
4
5
6
7
8
9

# Đưa các commit từ máy tính lên GitHub
git push origin <tên_nhánh>

# Lấy các cập nhật mới nhất từ GitHub về máy tính
git pull origin <tên_nhánh>

# Ví dụ:
git push origin main
git pull origin main

2.5 Xem lịch sử commit

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Xem danh sách commit gần đây
git log

# Xem lịch sử dưới dạng compacted (một dòng mỗi commit)
git log --oneline

# Xem lịch sử với biểu đồ nhánh
git log --oneline --graph --all

# Xem chi tiết của một commit cụ thể
git show <mã_commit>

2.6 Tệp .gitignore

Một số file không nên commit vào repository (file tạm, biến môi trường, thư viện được tải về, v.v.). Tạo file .gitignore trong thư mục gốc của repository để loại bỏ các file này.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# File .gitignore
node_modules/
dist/
build/
.env
.env.local
.DS_Store
*.log
*.swp
.vscode/
.idea/
coverage/

Một khi file đã được commit, .gitignore không thể làm cho nó biến mất. Nếu bạn muốn bỏ qua một file đã được commit:

1
2

git rm --cached <tên_file>
git commit -m "Remove <tên_file> from version control"

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

Khi tham gia vào một nhóm, việc phân chia và gộp mã nguồn diễn ra thường xuyên. Quy trình làm việc với Pull Request là tiêu chuẩn trong hầu hết các dự án.

3.1 Tạo và quản lý nhánh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Tạo một nhánh mới và chuyển sang nhánh đó
git checkout -b <tên_nhánh_mới>

# Hoặc cách viết mới (Git 2.23+)
git switch -c <tên_nhánh_mới>

# Chuyển đến nhánh đã tồn tại
git checkout <tên_nhánh>
git switch <tên_nhánh>

# Xem danh sách các nhánh cục bộ
git branch

# Xem tất cả các nhánh (kể cả trên GitHub)
git branch -a

# Xóa nhánh (nếu đã merge)
git branch -d <tên_nhánh>

Quy ước đặt tên nhánh:

1
2
3
4
5

feature/user-authentication    # Tính năng mới
bugfix/login-validation        # Sửa lỗi
hotfix/critical-security-patch # Sửa cấp tốc
refactor/code-cleanup          # Tái cấu trúc
docs/update-readme             # Cập nhật tài liệu

3.2 Quy trình Pull Request (PR)

Pull Request (PR) là cách thông dụng để gộp mã nguồn trong các nhóm. Nó cho phép đồng đội xem xét và thảo luận về mã trước khi gộp vào nhánh chính.

Các bước:

1. Tạo nhánh mới từ main:

1
2
3

git checkout main
git pull origin main
git checkout -b feature/new-feature

2. Commit các thay đổi:

1
2
3

git add .
git commit -m "Implement new feature"
git push origin feature/new-feature

3. Tạo Pull Request trên GitHub:

   • Truy cập repository trên GitHub
   • Nhấp nút “Compare & pull request”
   • Viết tiêu đề và mô tả PR
   • Liên kết đến issue nếu có: fixes #123 hoặc closes #456
   • Nhấp “Create pull request”

4. Chờ code review:

   • Đồng đội sẽ xem xét mã
   • Có thể yêu cầu thay đổi (request changes)
   • Bạn tiếp tục commit vào nhánh để cập nhật PR

5. Merge vào main:

   • Sau khi được phê duyệt (approved), PR có thể merge
   • Thường sử dụng “Squash and merge” hoặc “Create a merge commit”

6. Xóa nhánh:

1
2

git branch -d feature/new-feature
git push origin --delete feature/new-feature

3.3 Cập nhật nhánh từ main

Trong quá trình PR, nhánh main có thể có cập nhật từ đồng đội khác. Cập nhật nhánh của bạn để tránh xung đột:

1
2
3
4
5

# Cách 1: Pull và merge
git pull origin main

# Cách 2: Rebase (tuyến tính hơn, xem phần 4)
git rebase main

3.4 Xử lý Merge Conflicts

Khi gộp nhánh, Git đôi khi không thể tự động giải quyết vì cùng một dòng mã được chỉnh sửa ở hai nhánh khác nhau.

Nhận biết xung đột:

1
2

git status
# Kết quả: Unmerged paths hoặc CONFLICT

Giải quyết xung đột:

Mở file có xung đột. Git sẽ đánh dấu như sau:

1
2
3
4
5

<<<<<<< HEAD
// Phần code từ nhánh hiện tại
=======
// Phần code từ nhánh khác
>>>>>>> <tên_nhánh>

Chỉnh sửa file để giữ phần code đúng:

1
2
3
4

# Sau khi sửa
git add .
git commit -m "Resolve merge conflict"
git push origin <tên_nhánh>

4. Một số kỹ thuật mở rộng

Khi đã quen thuộc với các thao tác trên, bạn có thể áp dụng thêm một vài kỹ thuật để xử lý các tình huống phức tạp hơn.

4.1 Rebase

Giống như merge, rebase dùng để tích hợp các thay đổi từ nhánh này sang nhánh khác. Điểm khác biệt là rebase viết lại lịch sử commit để trở nên liền mạch (tuyến tính) hơn, làm cho log trông sạch hơn.

Khi nào sử dụng:

• Khi nhánh của bạn chưa được chia sẻ (chỉ trên máy địa phương hoặc nhánh cá nhân)
• Muốn giữ lịch sử commit sạch và dễ đọc

Cách sử dụng:

1
2
3
4
5
6
7
8
9

# Đứng tại nhánh hiện tại, rebase với nhánh main
git rebase main

# Nếu có xung đột, giải quyết rồi:
git add .
git rebase --continue

# Hoặc hủy rebase nếu cần
git rebase --abort

Lưu ý quan trọng: Không sử dụng rebase trên các nhánh đã được chia sẻ chung với người khác. Rebase viết lại lịch sử, khiến việc đồng bộ mã của nhóm trở nên khó khăn. Chỉ rebase trên các nhánh cá nhân hoặc chưa được push.

Ví dụ:

1
2
3
4
5
6
7

# An toàn: Nhánh cá nhân, chưa share
git checkout feature/my-feature
git rebase main
git push origin feature/my-feature --force  # --force vì lịch sử thay đổi

# Không nên: Nhánh đã share với nhóm
# (Thay vào đó, dùng git pull hoặc merge)

4.2 Stash

Nếu bạn đang làm dở một tính năng nhưng cần chuyển sang nhánh khác để xử lý việc khác (ví dụ: sửa bug cấp tốc), stash giúp bạn cất tạm các thay đổi chưa được commit.

Khi nào sử dụng:

• Cần chuyển nhánh nhưng không muốn commit công việc chưa hoàn thiện
• Muốn lưu tạm công việc để làm việc khác

Cách sử dụng:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Cất tạm thay đổi hiện tại
git stash

# Danh sách các stash
git stash list

# Lấy lại thay đổi đã cất (xóa từ stash)
git stash pop

# Hoặc áp dụng lại mà không xóa
git stash apply stash@{0}

# Xóa một stash cụ thể
git stash drop stash@{0}

Ví dụ thực tế:

1
2
3
4
5
6

# Đang làm feature, nhưng phát hiện bug cấp tốc
git stash                    # Cất lại công việc hiện tại
git checkout hotfix/bug      # Chuyển sang nhánh sửa bug
# ... sửa bug, commit ...
git checkout feature/my-feature
git stash pop                # Lấy lại công việc cũ

4.3 Cherry-pick

Kỹ thuật này cho phép bạn chọn một (hoặc một vài) commit cụ thể từ nhánh khác và áp dụng nó vào nhánh hiện tại, mà không cần merge toàn bộ nhánh đó.

Khi nào sử dụng:

• Bạn cần một bug fix từ nhánh khác mà chưa sẵn sàng merge toàn bộ
• Cần áp dụng một commit vào nhiều nhánh khác nhau
• Nhân bản một commit từ nhánh này sang nhánh khác

Cách sử dụng:

1
2
3
4
5
6
7
8
9

# Tìm mã commit cần cherry-pick
git log <nhánh_khác> --oneline

# Áp dụng commit đó vào nhánh hiện tại
git cherry-pick <mã_commit>

# Nếu có xung đột
git add .
git cherry-pick --continue

Ví dụ:

1
2
3
4
5
6
7

# main có bug fix từ develop
git log develop --oneline
# ab12345 Fix critical authentication bug

git checkout main
git cherry-pick ab12345
# Bug fix từ develop hiện đã có trên main

Lưu ý: Cherry-pick tạo commit mới, vì vậy nó không phải là “áp dụng” commit ban đầu mà là “sao chép” commit. Sử dụng một cách có chủ ý vì nó có thể gây nhầm lẫn về lịch sử.

4.4 Reset và Revert

Đôi khi bạn cần phải hoàn tác các thay đổi. Git cung cấp hai cách khác nhau:

git revert (An toàn, tạo commit mới):

1
2
3
4
5

# Tạo commit mới để hoàn tác commit cũ
git revert <mã_commit>

# Ví dụ: Hoàn tác commit cuối cùng
git revert HEAD

Dùng khi: Commit đã được push lên GitHub hoặc chia sẻ với nhóm.

git reset (Viết lại lịch sử, cẩn thận):

1
2
3
4
5
6
7
8

# Soft reset: Hoàn tác commit nhưng giữ thay đổi
git reset --soft HEAD~1

# Mixed reset: Hoàn tác commit và unstage (mặc định)
git reset --mixed HEAD~1

# Hard reset: Hoàn tác toàn bộ (mất dữ liệu!)
git reset --hard HEAD~1

Dùng khi: Commit chỉ ở máy địa phương, chưa push.

So sánh:

4.5 Reflog: Công cụ cứu rỗi

Nếu bạn vô tình mất một commit hoặc thao tác sai, reflog sẽ giúp bạn tìm lại nó.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Xem lịch sử tất cả thao tác trên HEAD
git reflog

# Ví dụ:
# ab12345 HEAD@{0}: reset: moving to HEAD~1
# cd67890 HEAD@{1}: commit: My last commit
# ef01234 HEAD@{2}: merge: Merge pull request

# Quay lại commit đã "mất"
git reset --hard cd67890

5. Mẹo và best practices

5.1 Trước khi push

1
2
3
4

# Luôn kiểm tra thay đổi trước khi push
git status
git diff           # Xem chi tiết thay đổi
git log --oneline -5  # Xem 5 commit gần đây

5.2 Cập nhật thường xuyên

1
2
3

# Giữ nhánh của bạn cập nhật với main
git fetch origin
git rebase origin/main  # hoặc git pull

5.3 Lên kế hoạch commit

1
2
3
4
5
6
7
8

# Thay vì một commit lớn, chia thành nhiều commit nhỏ
# Tốt:
git commit -m "Add login form component"
git commit -m "Add login validation"
git commit -m "Add unit tests for login"

# Không nên:
git commit -m "Add login feature, fix bugs, update docs, refactor code"

5.4 Đọc trước khi merge

• Luôn xem xét (review) mã trước khi merge.
• Chạy tests cục bộ trước khi push.
• Hỏi đồng đội nếu không chắc.

Tổng kết

Sử dụng tốt Git và GitHub sẽ giúp quá trình phát triển phần mềm của bạn trở nên có tổ chức, dễ dàng tra cứu, và thuận lợi cho phối hợp nhóm.

Lộ trình học tập:

1. Bắt đầu với các lệnh cơ bản (add, commit, push, pull).
2. Thành thạo workflow Pull Request.
3. Dần áp dụng các kỹ thuật mở rộng khi dự án lớn hơn.
4. Tìm hiểu Git Flow hoặc GitHub Flow cho quy mô lớn hơn.

Hy vọng bài viết này cung cấp một góc nhìn tổng quan và hữu ích cho công việc của bạn. Hãy thực hành thường xuyên, vì Git là công cụ càng dùng càng quen!

Tài liệu tham khảo:

• Git Official Documentation
• GitHub Docs
• Atlassian Git Tutorials