Develop Branch trong Git — nó là gì, mục đích và nguyên tắc hoạt động

Develop Branch trong Git là gì

Develop Branch (nhánh phát triển) là một nhánh tồn tại lâu dài trong Git Flow, đóng vai trò là trung tâm tích hợp mã từ tất cả các nhà phát triển. Các nhánh feature được hợp nhất vào nó sau khi hoàn thành phát triển và đánh giá mã.

Mã trong develop luôn ở trạng thái sẵn sàng tạo bản phát hành, mặc dù chưa được triển khai vào sản xuất. Điều này có nghĩa là tất cả các tính năng trong develop đã qua đánh giá, kiểm thử và kiểm tra tích hợp, nhưng vẫn đang chờ chu kỳ phát hành.

Không giống như main, nơi mỗi phiên bản mã là một bản phát hành, develop chứa một luồng thay đổi liên tục. Các commit trong develop xuất hiện khi các nhánh feature được hợp nhất, điều này có thể xảy ra nhiều lần trong ngày.

Theo Vincent Driessen, 2010, develop là yếu tố then chốt của mô hình nhánh thành công, vì nó tách biệt công việc nháp khỏi các phiên bản sẵn sàng phát hành.

Sự khác biệt giữa develop và main branch

Hiểu sự khác biệt giữa develop và main là rất quan trọng để có quy trình Git Flow đúng đắn. Các nhánh này phục vụ các chức năng khác nhau và có yêu cầu ổn định khác nhau.

Việc phân chia thành develop và main cho phép nhóm liên tục tích hợp mã mới mà không gây rủi ro cho sự ổn định của phiên bản sản xuất. Các nhà phát triển có thể thấy mã của họ trong develop ngay sau khi PR được chấp thuận, ngay cả trước khi phát hành chính thức.

Vai trò của develop trong Git Flow

Trong mô hình Git Flow, develop chiếm vị trí trung tâm giữa các nhánh feature (nguồn thay đổi) và nhánh release (chuẩn bị phát hành). Hiểu hệ thống phân cấp này là nền tảng của việc phân nhánh hiệu quả.

• Feature → Develop — mỗi tính năng hoàn thành được hợp nhất vào develop qua Pull Request với đánh giá mã.
• Develop → Release — khi tích lũy đủ thay đổi cho một bản phát hành, một nhánh release được tạo từ develop.
• Release → Main + Develop — sau khi chuẩn bị cuối cùng, nhánh release được hợp nhất vào main (phát hành) và trở lại develop (sửa lỗi).
• Hotfix → Main + Develop — các bản sửa lỗi quan trọng được tạo từ main và hợp nhất vào cả hai nhánh.

Cấu trúc này đảm bảo rằng develop luôn chứa mã mới nhất với tất cả các tính năng mới, trong khi main chỉ chứa mã sản xuất đã được xác minh. Điều này đặc biệt quan trọng đối với các dự án di động có chu kỳ đánh giá dài trên App Store và Google Play.

Mối quan hệ của develop với các nhánh Git Flow khác

Develop đóng vai trò là liên kết trung tâm giữa các nhánh feature, release và hotfix. Hiểu hướng hợp nhất là rất cần thiết để ngăn ngừa xung đột và mất commit.

Yêu cầu chất lượng mã trong develop

Chất lượng mã trong develop phải cao, nhưng không tuyệt đối. Không giống như main, nơi mỗi lỗi có nghĩa là một hotfix khẩn cấp, develop cho phép những thiếu sót nhỏ sẽ được sửa trước khi phát hành.

Yêu cầu tối thiểu đối với mã trước khi hợp nhất vào develop:

• Biên dịch — mã phải biên dịch không lỗi. Bản dựng hỏng trong develop chặn công việc của toàn bộ nhóm.
• Kiểm thử đơn vị — tất cả các kiểm thử hiện có phải vượt qua. Mã mới phải được kiểm thử bao phủ ít nhất 70%.
• Phong cách mã — mã phải tuân thủ các tiêu chuẩn định dạng và đặt tên được nhóm chấp nhận.
• Không có API lỗi thời — không được phép sử dụng các phương thức lỗi thời trong mã mới.

Các kiểm tra tự động trong pipeline CI/CD phải chạy trên mọi push vào develop. Nếu bản dựng hỏng, nhà phát triển chịu trách nhiệm phải sửa vấn đề trong vòng một giờ hoặc hoàn tác commit của họ.

Kiểm tra CI/CD cho develop

Thiết lập GitHub Actions cho develop đảm bảo rằng mọi PR đều trải qua kiểm tra tự động trước khi hợp nhất. Một pipeline điển hình bao gồm xây dựng, kiểm thử và linting.

# GitHub Actions — kiểm tra develop sau khi hợp nhất
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Quy tắc hợp nhất vào develop

Hợp nhất vào develop phải tuân theo các quy tắc nghiêm ngặt để duy trì sự ổn định của nhánh tích hợp. Vi phạm các quy tắc này dẫn đến xung đột, bản dựng hỏng và lãng phí thời gian của nhóm.

• Chỉ qua Pull Request — push trực tiếp vào develop bị cấm. Tất cả các thay đổi đều qua đánh giá mã.
• Tối thiểu một phê duyệt — PR phải được phê duyệt bởi ít nhất một nhà phát triển không tham gia vào nhiệm vụ.
• Squash merge — nên kết hợp tất cả các commit của nhánh feature thành một khi hợp nhất vào develop để có lịch sử sạch sẽ.
• PR phải cập nhật — trước khi hợp nhất, PR phải được cập nhật so với commit develop mới nhất (rebase hoặc merge).

Quy tắc PR phải cập nhật đặc biệt quan trọng. Nếu một nhánh feature được tạo một tuần trước và develop đã tiến 50 commit, việc hợp nhất trực tiếp có thể dẫn đến xung đột, tốt nhất nên giải quyết trong bối cảnh PR hơn là trong develop.

Bảo vệ develop khỏi hợp nhất không đúng

Quy tắc bảo vệ nhánh là các cài đặt ở cấp GitHub, GitLab hoặc Bitbucket ngăn chặn các thay đổi không đúng vào develop. Chúng đảm bảo rằng ngay cả một push tình cờ cũng không làm hỏng nhánh tích hợp.

Các quy tắc bảo vệ được khuyến nghị cho develop:

• Yêu cầu pull request — cấm push trực tiếp vào develop. Mọi thay đổi chỉ qua PR.
• Yêu cầu phê duyệt — tối thiểu 1-2 phê duyệt trước khi hợp nhất PR.
• Yêu cầu kiểm tra trạng thái — chặn hợp nhất nếu pipeline CI/CD chưa vượt qua.
• Yêu cầu cập nhật — nhánh PR phải được cập nhật so với develop trước khi hợp nhất.
• Hạn chế quyền push — giới hạn quyền push vào develop chỉ dành cho nhà phát triển cấp cao.

Thiết lập bảo vệ develop mất 10 phút nhưng ngăn chặn nhiều tuần gián đoạn liên quan đến nhánh tích hợp bị hỏng. Đối với các dự án di động với nhóm đa nền tảng, điều này đặc biệt phù hợp.

Ví dụ lệnh làm việc với develop

Hãy xem xét một ngày điển hình của nhà phát triển: buổi sáng họ cập nhật develop, tạo một nhánh feature mới và sau khi hoàn thành nhiệm vụ, hợp nhất các thay đổi trở lại develop.

# Đồng bộ develop buổi sáng
git checkout develop
git pull origin develop

# Tạo nhánh feature mới từ develop
git checkout -b feature/add-push-notifications

# Đang làm việc trên tính năng...
git add . && git commit -m "Add FCM integration"

# Cập nhật develop trong quá trình phát triển
git fetch origin develop
git rebase origin/develop

# Sau khi PR được chấp thuận — cập nhật develop cục bộ
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Lệnh git pull trong develop thực hiện đồng thời hai thao tác: git fetch (lấy commit mới từ máy chủ) và git merge (hợp nhất chúng với nhánh cục bộ). Đối với develop, đây là phương pháp đồng bộ tiêu chuẩn.

Khôi phục develop sau khi hợp nhất hỏng

Nếu mã làm hỏng bản dựng vào được develop, cần hành động nhanh chóng. Mỗi giờ develop ngừng hoạt động là công việc bị chặn của toàn bộ nhóm phát triển.

Nếu mã làm hỏng bản dựng vào được develop, hãy sử dụng git revert để tạo commit mới hoàn tác các thay đổi có vấn đề. Không sử dụng git reset trong develop — nó ghi đè lịch sử mà các thành viên khác trong nhóm đã có.

# Tìm commit có vấn đề
git log --oneline develop

# Hoàn tác commit qua revert (an toàn)
git revert a1b2c3d

# Gửi bản sửa đến develop từ xa
git push origin develop

# Xem thay đổi trong một commit cụ thể
git show a1b2c3d --stat