Git Team Collaboration Workflow

Part 1 (English): Git Team Collaboration Workflow

Working effectively with Git in a software team requires discipline and clear conventions. This comprehensive guide covers the end-to-end lifecycle of a feature: from branching out, syncing ongoing code safely, resolving merge conflicts, to opening and refining pull requests.

1. Starting a New Task (Branching from the Latest Code)

Always make sure your local main branch is clean and fully synchronized with the remote repository before creating a new feature branch.

# Switch to main branch
git checkout main

# Pull the latest commits from the remote repository
git pull origin main

# Create and switch to your new feature branch
git checkout -b feature/your-feature-name

Best Practice: Use clear, descriptive branch names such as feature/user-auth, fix/navbar-overflow, or refactor/api-client.

2. Syncing Upstream Changes While You Are Still Coding

When a teammate merges a new pull request into main, you should regularly sync those updates into your working branch to avoid large conflicts later.

Step 2.1: Save your current progress (WIP)

git add .
git commit -m "wip: working on [your-feature-name]"

Step 2.2: Fetch and update the main branch

git checkout main
git pull origin main

Step 2.3: Merge the updated main into your feature branch

git checkout feature/your-feature-name
git merge main

Handling Merge Conflicts: If Git reports conflict markers, open the highlighted files in VS Code or your editor, pick the correct version (Accept Current, Incoming, or Both), save the file, and then run:

git add .
git commit -m "fix: resolve merge conflicts with main"

3. Completing the Feature (Pushing & Creating Pull Request)

Once your feature implementation and local testing are complete, push your branch to GitHub and request reviews.

git add .
git commit -m "feat: complete [your-feature-name]"
git push origin feature/your-feature-name

Next, visit your GitHub repository on the browser, click "Compare & pull request", write a concise description of what was changed, and assign team members as Reviewers.

4. Scenario: Reviewer Requests Changes

If your peers request updates during the code review, do not close or create a new pull request. Simply make the necessary edits on your current local branch and push again:

# Make edits to files and stage them
git add .

# Commit your changes with a descriptive message
git commit -m "fix: update logic based on code review feedback"

# Push to your existing feature branch
git push origin feature/your-feature-name

GitHub will automatically detect the new commits and update the existing Pull Request.

5. Quick Reference & Emergency Commands

• git status — View working tree status (untracked files, modified files, current branch).
• git branch — List all local branches and see which branch is active.
• git log — View commit history (press q to exit the log viewer).
• git diff — Inspect unstaged changes before committing.

Phần 2 (Tiếng Việt): Quy Trình Làm Việc Git Team (Chi Tiết & Đầy Đủ)

Làm việc nhóm bằng Git đòi hỏi sự phối hợp nhịp nhàng giữa các lập trình viên nhằm hạn chế tối đa xung đột mã nguồn (conflict) và giữ cho nhánh chính (main/master) luôn ổn định. Dưới đây là quy trình chuẩn từ lúc nhận task đến khi merge code.

1. Bắt Đầu Task Mới (Tạo nhánh từ bản cập nhật mới nhất)

Luôn đảm bảo đang đứng ở nhánh main và kéo về toàn bộ code mới nhất của cả nhóm trước khi tạo nhánh mới:

# Đứng về nhánh chính
git checkout main

# Kéo code mới nhất từ kho chung về
git pull origin main

# Rẽ nhánh mới cho tính năng cần làm
git checkout -b feature/ten-chuc-nang-cua-ban

Quy ước đặt tên nhánh: Hãy đặt tên nhánh rõ ràng như feature/login-modal, fix/payment-error, chore/update-dependencies để cả nhóm dễ theo dõi.

2. Đang Code Dở Nhưng Cần Kéo Code Team Về (Cập nhật an toàn)

Khi có thành viên vừa merge tính năng mới vào main, bạn nên chủ động cập nhật những thay đổi đó vào nhánh của mình ngay để kiểm tra tính tương thích.

Bước 2.1: Lưu nháp tiến độ đang làm dở (WIP)

git add .
git commit -m "wip: dang code do [ten-chuc-nang]"

Bước 2.2: Tải code mới nhất từ kho chung về máy

git checkout main
git pull origin main

Bước 2.3: Mang code mới trộn vào nhánh cá nhân đang làm

git checkout feature/ten-chuc-nang-cua-ban
git merge main

Xử lý xung đột (Conflict): Nếu terminal báo xung đột và file trong VS Code bị bôi đỏ:

1. Mở các file bị xung đột trong VS Code.
2. Xem kỹ phần code của mình và code của đồng nghiệp (chọn Accept Current Change, Accept Incoming Change hoặc kết hợp cả hai).
3. Lưu file lại và gõ lệnh:

   git add .
   git commit -m "fix: resolve conflict"

3. Hoàn Thành Tính Năng (Đẩy lên GitHub tạo Pull Request)

Khi đã code xong tính năng và kiểm thử kỹ càng trên máy cá nhân:

git add .
git commit -m "feat: hoan thanh [ten-chuc-nang]"
git push origin feature/ten-chuc-nang-cua-ban

Sau khi push thành công:

• Mở trình duyệt vào trang repository GitHub của dự án.
• Bấm nút "Compare & pull request" xuất hiện ở đầu trang.
• Viết tóm tắt ngắn gọn những gì đã làm và gắn thẻ đồng nghiệp vào mục Reviewers để được duyệt code.

4. Tình Huống: Đồng Nghiệp Yêu Cầu Sửa Lỗi (Request Changes)

Nếu đồng nghiệp review và yêu cầu chỉnh sửa, bạn không cần đóng hay tạo Pull Request mới. Hãy sửa trực tiếp trên nhánh hiện tại và đẩy tiếp lên GitHub:

# Sửa code trên máy và lưu lại
git add .

# Commit với thông điệp rõ ràng
git commit -m "fix: cap nhat logic theo gop y cua dong nghiep"

# Đẩy tiếp lên nhánh tính năng
git push origin feature/ten-chuc-nang-cua-ban

Hệ thống GitHub sẽ tự động cập nhật các commit mới vào chính Pull Request đang mở mà không làm mất lịch sử thảo luận.

5. Bộ Lệnh Tra Cứu & Cứu Hộ Nhanh

• git status — Xem trạng thái hiện tại (biết file nào đã lưu, file nào chưa, đang đứng ở nhánh nào).
• git branch — Xem toàn bộ danh sách nhánh trên máy cá nhân (nhánh có dấu * là nhánh hiện hành).
• git log — Xem lịch sử các lần commit gần nhất (nhấn phím q để thoát màn hình log).
• git diff — So sánh chi tiết từng dòng thay đổi trước khi commit.