Phân nhánh, Gộp nhánh và Giải quyết xung đột
Mục lục
Branching, Merging, and Conflict Resolution
(Phân nhánh, Gộp nhánh và Giải quyết xung đột)
So sánh Branching và Merging
Bảng dưới đây so sánh phân nhánh và gộp nhánh theo nhiều khía cạnh:
| Khía cạnh | Branching (Phân nhánh) | Merging (Gộp nhánh) |
|---|---|---|
| Mục đích | Cho phép phát triển độc lập tính năng/sửa lỗi | Tích hợp thay đổi từ nhiều nhánh |
| Lệnh | git branch <branch_name> | git merge <branch_name> |
| Cô lập | Công việc tách biệt khỏi main | Kết hợp công việc vào code chung |
| Trường hợp sử dụng | Phát triển tính năng, sửa lỗi | Gộp feature vào main |
| Ảnh hưởng | Không ảnh hưởng main branch | Thay đổi nhánh đích |
| Quy trình | Tạo nhánh để làm việc | Merge khi hoàn thành |
| Phát triển song song | Có | Có nhưng cần xử lý xung đột |
| Quản lý xung đột | Không phát sinh ngay | Có thể phát sinh |
| Độ ổn định | Main branch ổn định | Có thể gây lỗi nếu merge sai |
| CI/CD | Hỗ trợ phát triển song song | Hỗ trợ deploy tự động |
| Hoàn tác | Xóa nhánh | git revert <merge_commit> |
| Ví dụ | Tạo feature branch | Merge feature vào main |
Các loại Branching trong Git
1. Feature Branching
Feature branching là việc tạo một nhánh mới cho mỗi tính năng hoặc nhiệm vụ. Nhánh này được cô lập khỏi codebase chính, cho phép developer làm việc độc lập mà không ảnh hưởng đến phiên bản ổn định của dự án.
Lợi ích của Feature Branching:
- Cô lập tính năng mới khỏi codebase chính
- Cho phép phát triển song song nhiều tính năng
- Hỗ trợ code review và testing trước khi merge
Lệnh:
git checkout -b feature/feature-name
2. Release Branching
(Phân nhánh phát hành)
Release branching là việc tạo một nhánh mới khi dự án chuẩn bị phát hành phiên bản. Nhánh này giúp ổn định phiên bản phát hành bằng cách sửa lỗi và thực hiện các điều chỉnh cuối cùng, trong khi việc phát triển mới vẫn tiếp tục trên nhánh main.
Lợi ích của Release Branching:
- Cô lập quá trình ổn định bản phát hành khỏi việc phát triển đang diễn ra
- Đảm bảo quy trình phát hành sạch và ổn định
- Cho phép sửa lỗi nhanh trên nhánh release mà không ảnh hưởng đến phát triển mới
Lệnh:
git checkout -b release/version-number
Usage:
Release branch được tạo khi chuẩn bị phát hành phần mềm. Mọi sửa lỗi cuối cùng, cập nhật tài liệu và công việc chuẩn bị phát hành đều được thực hiện trên nhánh này. Khi mọi thứ sẵn sàng, nhánh release sẽ được merge vào main branch và được gắn tag để triển khai.
Hotfix Branching
(Phân nhánh sửa lỗi khẩn cấp)
Hotfix branching được sử dụng để xử lý nhanh các lỗi nghiêm trọng trong môi trường production. Nhánh hotfix được tạo trực tiếp từ main branch để sửa lỗi và sau đó merge lại vào cả main branch và các nhánh release liên quan.
Lợi ích của Hotfix Branching:
- Cho phép xử lý nhanh các sự cố nghiêm trọng
- Giảm thiểu gián đoạn đối với quá trình phát triển đang diễn ra
- Đảm bảo các bản sửa lỗi được áp dụng cho tất cả các nhánh liên quan
Lệnh:
git checkout -b hotfix/issue-number
Usage:
Hotfix branch được tạo để sửa các lỗi nghiêm trọng trên production. Sau khi sửa và kiểm thử, nhánh hotfix được merge lại vào main branch và develop branch để đảm bảo bản sửa có mặt ở cả production và quá trình phát triển tiếp theo.
Development Branching (Git Flow)
(Phân nhánh phát triển – Git Flow)
Development branching, thường được gọi là Git Flow, sử dụng nhiều nhánh cho các mục đích khác nhau:
- main branch: chứa code ổn định, sẵn sàng production
- develop branch: nhánh tích hợp cho các tính năng và sửa lỗi
- feature branches: phát triển tính năng
- release branches: chuẩn bị phát hành
- hotfix branches: sửa lỗi khẩn cấp
Lợi ích của Development Branching:
- Cung cấp workflow rõ ràng và có cấu trúc
- Tách biệt các giai đoạn phát triển và phát hành
- Hỗ trợ phát triển song song và CI/CD hiệu quả
Lệnh:
git checkout -b develop
Usage:
Nhánh develop đóng vai trò là nhánh tích hợp trung gian. Các nhánh feature và bugfix được merge vào develop để kiểm thử tập trung trước khi được merge vào main branch cho production.
Maintenance Branching
(Phân nhánh bảo trì)
Maintenance branching được sử dụng để duy trì và hỗ trợ các phiên bản cũ của phần mềm. Các nhánh này cho phép backport các bản vá bảo mật và sửa lỗi cho các bản phát hành trước đó.
Lợi ích của Maintenance Branching:
- Hỗ trợ lâu dài cho các phiên bản cũ
- Cô lập công việc bảo trì khỏi phát triển mới
- Đảm bảo tính ổn định và bảo mật
Lệnh:
git checkout -b maintenance/version-number
Usage:
Maintenance branch được tạo từ phiên bản phát hành tương ứng. Các bản vá được áp dụng và kiểm thử trên nhánh này, sau đó merge lại để đảm bảo các phiên bản đang được hỗ trợ luôn cập nhật.
Merging Strategies
(Các chiến lược gộp nhánh)
Có nhiều chiến lược merge khác nhau trong Git, mỗi chiến lược phù hợp với các kịch bản khác nhau.
Fast Forward Merge
Fast forward merge là kiểu merge mà con trỏ của nhánh gốc được di chuyển thẳng tới commit mới nhất của nhánh cần merge. Không tạo merge commit mới.
Đặc điểm:
- Chỉ xảy ra khi không có commit phân kỳ
- Lịch sử commit tuyến tính và đơn giản
- Thường dùng khi feature branch chưa bị thay đổi song song
Quy trình:
git checkout main
git merge <feature-branch>
Automatic Merge
Automatic merge xảy ra khi Git tự động kết hợp các thay đổi từ hai nhánh mà không có xung đột. Git sẽ tạo một merge commit mới.
Đặc điểm:
Không cần can thiệp thủ công
Dùng khi các thay đổi không chồng chéo
Phù hợp khi nhiều developer làm việc song song
Các bước:
Step 1: Đảm bảo nhánh được cập nhật
git checkout main
git pull origin main
Step 2: Merge feature branch
git merge <feature-branch>
Recursive Merge
Recursive Merging
(Merge đệ quy – chiến lược mặc định của Git)
Recursive merging là chiến lược merge mặc định của Git khi các nhánh đã phân kỳ. Chiến lược này được thiết kế để xử lý các tình huống merge phức tạp với nhiều thay đổi độc lập.
Ưu điểm chính của Recursive Merging:
- Preserve complete history (giữ toàn bộ lịch sử)
- Accurate integration records (ghi nhận chính xác quá trình merge)
- Handles multiple levels of divergence (xử lý nhiều mức phân kỳ)
- Robust conflict detection (phát hiện xung đột mạnh mẽ)
- Enhanced traceability (tăng khả năng truy vết)
📌 [ảnh minh họa]
Steps to Perform Recursive Merging
(Các bước thực hiện Recursive Merge)
Chúng ta sẽ lần lượt thảo luận các bước để thực hiện recursive merging.
Step 1: Setup the Repository
(Thiết lập repository)
Thiết lập một repository mới như đã được trình bày trong Session 01.
Step 2: Create an Initial Commit
(Tạo commit ban đầu)
Tạo một file mới và commit nó vào repository.
Command Syntax:
echo "Initial content" > file.txt
git add file.txt
git commit -m "Initial commit"
Step 3: Create Divergent Branches
(Tạo các nhánh bị phân kỳ)
Tạo và chuyển sang một nhánh mới (feature).
Command Syntax:
git checkout -b feature
Step 4: Make Changes in the Feature Branch
(Thực hiện thay đổi trên nhánh feature)
Chỉnh sửa file và commit các thay đổi.
Example:
echo "Feature branch change 1" >> file.txt
git add file.txt
git commit -m "Add change 1 to feature branch"
echo "Feature branch change 2" >> file.txt
git add file.txt
git commit -m "Add change 2 to feature branch"
Outcome:
Sau khi thực hiện các lệnh trên, file file.txt sẽ chứa hai dòng được thêm vào:
Feature branch change 1Feature branch change 2
Lịch sử Git sẽ có hai commit liên tiếp trên nhánh feature, mỗi commit ghi lại một thay đổi riêng biệt.
Commit đầu tiên thêm nội dung Feature branch change 1 với message “Add change 1 to feature branch”.
Commit thứ hai thêm Feature branch change 2 với message “Add change 2 to feature branch”.
Nhánh feature lúc này phản ánh đầy đủ cả hai cập nhật, với mỗi thay đổi được ghi nhận trong commit tương ứng.
Step 5: Make Changes in the Main Branch
(Thực hiện thay đổi trên nhánh main)
Chuyển về nhánh main bằng lệnh:
git checkout main
Tương tự như Step 4, chỉnh sửa file và commit các thay đổi vào nhánh main.
Step 6: Perform the Recursive Merge
(Thực hiện Recursive Merge)
Merge nhánh feature vào nhánh main. Git sẽ sử dụng recursive strategy để gộp các thay đổi.
git merge feature
Step 7: Verify the Merge
(Xác minh kết quả merge)
Kiểm tra lịch sử commit bằng cách sử dụng lệnh git log để xác minh merge commit.
git log --graph --oneline --all
Merge Conflicts
(Xung đột khi merge)
Một merge conflict xảy ra khi các thay đổi từ các nhánh khác nhau:
- Ảnh hưởng đến cùng một phần của file
- Hoặc khi các thay đổi ở nhánh này mâu thuẫn trực tiếp với thay đổi ở nhánh khác
Trong các trường hợp này, Git không thể tự động merge, và cần sự can thiệp thủ công của người dùng để giải quyết xung đột.
Causes of Merge Conflicts
(Nguyên nhân gây ra merge conflicts)
- Concurrent Changes (Thay đổi đồng thời):
Xung đột thường xảy ra khi nhiều developer chỉnh sửa cùng một dòng trong cùng một file.
Tình huống này rất phổ biến trong các dự án cộng tác, nơi nhiều thành viên làm việc đồng thời trên cùng file. - Conflicting File Renames (Đổi tên file mâu thuẫn):
Nếu cùng một file bị đổi tên khác nhau ở hai nhánh, Git sẽ không thể hòa giải các thay đổi và sẽ đánh dấu là xung đột.
Trường hợp này thường xảy ra khi việc quản lý nhánh và phối hợp chưa chặt chẽ. - Contradictory Changes (Thay đổi đối nghịch):
Xung đột xảy ra khi thay đổi ở một nhánh đối lập về mặt logic với thay đổi ở nhánh khác.
Ví dụ: một nhánh xóa file trong khi nhánh khác lại chỉnh sửa file đó, Git sẽ không thể tự động giải quyết.
Conflict Markers
(Dấu hiệu đánh dấu xung đột)
Khi xảy ra xung đột, Git sẽ chèn conflict markers vào file bị ảnh hưởng để chỉ ra các đoạn cần được xử lý.
Các marker có dạng như sau:
<<<<<<< HEAD
Changes from the current branch
=======
Changes from the branch being merged
>>>>>>>
Steps to Resolve Merge Conflicts
(Các bước giải quyết merge conflicts)
Step 1: Identify Conflicted Files
(Xác định các file bị xung đột)
Sau khi merge thất bại, Git sẽ liệt kê các file đang có xung đột.
Có thể kiểm tra bằng lệnh:
git status
Step 2: Open and Edit Conflicted Files
(Mở và chỉnh sửa file bị xung đột)
Mở từng file bị xung đột bằng trình soạn thảo văn bản và tìm các conflict markers.
Chỉnh sửa file thủ công để giải quyết xung đột bằng cách:
- Chọn thay đổi cần giữ
- Hoặc kết hợp thay đổi từ cả hai nhánh
Người dùng bắt buộc sử dụng GNU Nano để giải quyết xung đột.
Nano là trình soạn thảo văn bản đơn giản, thân thiện, thường được cài sẵn trên các hệ điều hành giống Unix, và cung cấp giao diện trực quan để chỉnh sửa file từ command line.
Command:
nano <filename>
Conflicted File – Unresolved
(File còn xung đột)
Conflicted File – Resolved
(File đã được giải quyết xung đột)
Step 4: Stage Resolved Files and Commit the Merge
(Đưa file đã giải quyết vào staging và commit merge)
Sau khi giải quyết xong xung đột, thêm các file đã chỉnh sửa vào staging area:
git add <filename>
Commit để hoàn tất quá trình merge:
git commit -m "Resolved merge conflicts"
Avoiding Merge Conflicts
(Tránh merge conflicts)
Merge conflicts có thể làm gián đoạn workflow và làm chậm tiến độ phát triển. Tuy nhiên, bằng cách tuân theo các best practices, developer có thể giảm thiểu khả năng gặp xung đột.
Best Practices to Avoid Merge Conflicts
(Các thực hành tốt nhất để tránh merge conflicts)
| Best Practices | Description |
|---|---|
| Frequent Pulls | Thường xuyên pull thay đổi từ nhánh main vào feature branch để luôn đồng bộ với các cập nhật mới nhất, giảm nguy cơ xung đột khi merge cuối cùng. |
| Clear Communication | Duy trì giao tiếp rõ ràng giữa các thành viên. Sử dụng các công cụ cộng tác như Slack, Microsoft Teams hoặc phần mềm quản lý dự án để tránh trùng lặp công việc. |
| Smaller Commits | Thực hiện các commit nhỏ và thường xuyên thay vì commit lớn, giúp dễ phát hiện và giải quyết xung đột sớm. |
| Branch Naming Conventions | Sử dụng quy ước đặt tên nhánh rõ ràng để các thành viên hiểu mục đích của từng nhánh. |
| Code Reviews | Thực hiện code review thường xuyên thông qua Pull Requests để phát hiện và xử lý xung đột trước khi merge vào main. |
| Rebasing | Rebase feature branch thường xuyên lên main branch để cập nhật thay đổi mới nhất và giữ lịch sử commit gọn gàng. |
| Modular Development | Phát triển theo hướng module, cô lập thay đổi vào các file/thành phần cụ thể để giảm chồng chéo. |
| Pair Programming | Hai developer cùng làm việc trên một codebase giúp giảm rủi ro xung đột và tăng chất lượng tích hợp. |
| Feature Flags | Sử dụng feature flags để merge code vào main mà chưa kích hoạt ngay tính năng, giảm nguy cơ xung đột. |
| Automated Testing | Áp dụng kiểm thử tự động và CI để phát hiện sớm lỗi hoặc xung đột trước khi ảnh hưởng hệ thống. |
| Documenting Changes | Ghi chép đầy đủ các thay đổi giúp team hiểu rõ ngữ cảnh và tránh chỉnh sửa mâu thuẫn. |
