Natecue Knowledge Hub🚀 GitHub 101: Làm việc nhóm hiệu quả cho Dev & Marketing
Khi bắt đầu làm việc nhóm trên GitHub, việc hiểu cách quản lý code và nội dung là cực kỳ quan trọng để tránh “đè” lên nhau. Dưới đây là những khái niệm cốt lõi ông cần nắm.
🌳 1. Branch (Nhánh) là gì?
Hãy tưởng tượng dự án là một cái cây:
- Main Branch (Thân chính): Nơi chứa phiên bản đang chạy chính thức (Production).
- Branch (Nhánh): Một bản copy tách ra từ thân chính để ông làm việc riêng.
TIP
Hoạt động: Khi tạo nhánh mới, ông có một không gian riêng để đục đẽo, thêm bớt. Nếu nhánh đó bị hỏng, thân chính (Main) vẫn hoàn toàn bình thường.
🤝 2. Ai quyết định “Phiên bản chính thức”?
Trong team, chúng ta dùng quy trình Pull Request (PR):
- Bạn hoàn thành công việc trên branch cá nhân.
- Bạn gửi một yêu cầu “Pull Request” để gộp code vào
main. - Reviewer (Tech Lead/Owner): Sẽ kiểm tra xem code có lỗi không, có phá vỡ giao diện không.
- Nếu ổn, họ nhấn Merge (Gộp). Lúc này, thay đổi mới chính thức trở thành “bản gốc”.
🛠️ 3. Quy tắc vàng: Đừng bao giờ Push thẳng lên Main
- Tại sao? Nếu ông sửa thẳng lên
mainvà lỡ tay làm lỗi (dù chỉ là một dấu phẩy), toàn bộ hệ thống/website có thể bị sập ngay lập tức. - Giải pháp: Luôn tạo Branch → Làm việc → Tạo PR → Review → Merge.
📂 4. Setup Team hiệu quả (Marketing + Dev)
Để Marketing và Product phối hợp nhịp nhàng, hãy cấu trúc như sau:
Cấu trúc đặt tên Branch
dev/feature-name: Dành cho các tính năng mới của lập trình viên.mkt/blog-update: Dành cho Marketing cập nhật nội dung, hình ảnh.fix/bug-id: Dành cho việc sửa các lỗi gấp.
Phân quyền thông minh
- Developer: Sử dụng VS Code/Terminal để can thiệp sâu vào logic.
- Marketing: Nên sử dụng GitHub Desktop (Giao diện trực quan) hoặc sửa file Markdown trực tiếp trên giao diện Web của GitHub.
IMPORTANT
Nên bật tính năng “Branch protection rule” trong Settings của Repo. Yêu cầu mọi thay đổi vào
mainđều phải qua Pull Request và có ít nhất 1 người duyệt.
Xem thêm về các buổi thảo luận tại Danh sách Session.