Posted inGit

Git Patch & Git Apply: Chia sẻ code “chớp nhoáng” mà không làm bẩn Commit Log

Git tutorial - IT technology blog
Git tutorial - IT technology blog

Chuyện cái “Branch rác” và nỗi ám ảnh Push/Pull

Đang mải mê code thì ông bạn cùng team nhắn tin: “Gửi tui đoạn logic chỗ này cái, máy tui đang chạy bản cũ không test được”. Nếu lúc đó bạn commit đống code dở dang, đầy lỗi syntax rồi đẩy lên branch chung, lịch sử Git sẽ trông như một bãi chiến trường với đủ thứ “temp commit” hay “fix bug 1, 2, 3″… Nhìn cực kỳ thiếu chuyên nghiệp.

Tôi từng nếm mùi mất code vì force push nhầm branch. Từ đó, tôi cực kỳ dị ứng với việc push --force hay đẩy những thứ chưa hoàn thiện lên server. Sau 6 tháng đưa Git Patch vào workflow dự án thực tế, tôi nhận ra đây chính là bí kíp bỏ túi để làm việc team-work mượt mà, nhất là khi cần review nhanh hoặc chuyển code giữa các máy mà không muốn thông qua remote repository.

Tại sao chúng ta nên “né” Push khi chưa xong việc?

Thực tế là Git cực kỳ “khó tính” trong việc quản lý lịch sử. Mỗi lần bạn push, bạn đang ghi một dấu ấn vĩnh viễn vào dòng thời gian của dự án. Nếu dự án có CI/CD, việc push tùy tiện còn làm lãng phí tài nguyên khi kích hoạt hàng tá pipeline chạy vô ích.

  • Làm bẩn Commit Log: Những commit tạm bợ khiến việc git log sau này trở thành ác mộng cho người sau.
  • Xung đột (Conflict) vô duyên: Đẩy code dở dang dễ khiến đồng nghiệp pull về bị lỗi chéo cánh, tốn thời gian fix không đáng có.
  • Lộ bí mật: Đôi khi bạn đang debug và thêm vài dòng console.log hoặc biến môi trường tạm thời. Bạn chắc chắn không muốn chúng xuất hiện trên GitHub.
  • Mạng lag: Những ngày cáp quang gặp sự cố hoặc VPN công ty chậm như rùa, việc chờ đợi push/pull chỉ để gửi vài dòng code là một cực hình.

Những cách “chữa cháy” thủ công thường gặp

Trước khi biết đến Patch, tôi thường thấy anh em xoay xở bằng vài cách khá cồng kềnh:

  1. Copy paste qua Slack: Chỉ dùng được với vài dòng code ngắn. Nếu thay đổi nằm ở 10 file khác nhau thì coi như bó tay. Chưa kể định dạng code rất dễ bị nhảy lung tung.
  2. Nén folder gửi Mail: Một file nén chứa cả node_modules có thể nặng tới 200MB, trong khi thay đổi thực sự chỉ vài KB. Quá lãng phí!
  3. Dùng Git Stash: git stash chỉ có tác dụng cục bộ trên máy bạn. Không có cách nào trực tiếp để “bê” cái stash đó sang máy đồng nghiệp một cách dễ dàng.

Git Patch – Tuyệt chiêu cho workflow chuyên nghiệp

Nôm na thì file Patch là một bản “tổng phổ” chứa mọi thay đổi (diff) giữa các file. Nó cực nhẹ, dễ đọc và là ngôn ngữ mẹ đẻ mà Git cực kỳ ưa thích.

Cách 1: Git Diff (Mì ăn liền cho code chưa commit)

Nếu bạn chưa commit gì, chỉ mới sửa file và muốn gửi ngay đi, hãy dùng git diff.

# Tạo file patch từ những thay đổi hiện tại
git diff > my_changes.patch

# Gom cả những file mới tạo (untracked files)
git add -N . 
git diff > full_changes.patch

File my_changes.patch này thường chỉ nặng vài KB. Bạn có thể ném qua Telegram hay Slack trong tích tắc. Người nhận chỉ cần một lệnh duy nhất là có nguyên si đống code của bạn.

Cách 2: Git Format-Patch (Giữ nguyên lịch sử commit)

Tôi thường dùng cách này khi đã commit vài thứ ở local và muốn chia sẻ cả tên tác giả lẫn ngày giờ commit. format-patch sẽ xuất ra các file .patch riêng biệt cho từng commit.

# Tạo patch cho commit gần nhất
git format-patch -1 HEAD

# Tạo patch so sánh giữa 2 branch
git format-patch main..feature-branch

Kết quả bạn nhận được là file có tên kiểu 0001-fix-bug-logic.patch. File này “xịn” hơn hẳn vì nó chứa đầy đủ metadata, giúp người nhận biết chính xác ai đã viết code này.

Cách áp dụng Patch vào dự án

Tùy vào cách file patch được tạo ra, chúng ta sẽ có cách “hấp thụ” nó vào codebase tương ứng.

Sử dụng Git Apply (Cho file từ git diff)

Lệnh này đưa các thay đổi vào mã nguồn hiện tại nhưng không tạo commit mới.

# Kiểm tra xung đột trước khi áp dụng
git apply --check my_changes.patch

# Nếu ổn áp thì tiến hành apply
git apply my_changes.patch

Nếu gặp lỗi do code hiện tại đã khác quá nhiều, bạn hãy dùng thêm --reject. Git sẽ cố gắng apply những phần không lỗi và xuất ra file .rej để bạn xử lý thủ công các phần xung đột.

Sử dụng Git AM (Cho file từ format-patch)

AM là viết tắt của “Apply Mailbox”. Lệnh này cực kỳ bá đạo vì nó tự động tạo commit luôn cho bạn với thông tin y hệt máy gốc.

# Áp dụng patch và tạo commit tự động
git am < 0001-fix-bug-logic.patch

# Nếu chẳng may gặp xung đột:
# Sửa file xong rồi chạy:
git add .
git am --continue

Kinh nghiệm xương máu để tránh “ăn hành”

Sau nửa năm dùng Patch liên tục, tôi rút ra được vài lưu ý để anh em áp dụng mượt mà hơn:

  • Đừng quên file Binary: Patch mặc định chỉ hiểu văn bản. Nếu bạn thay đổi ảnh hay file nén, hãy nhớ thêm flag --binary khi tạo patch.
  • Luôn chạy –check trước: Đừng bao giờ apply thẳng tay. Một lệnh check mất chưa tới 1 giây nhưng cứu bạn khỏi hàng giờ ngồi undo code.
  • Cứu cánh cho Hotfix: Có lần server production gặp lỗi nhưng tôi không có quyền truy cập Git trực tiếp. Tôi tạo patch ở local, gửi cho đội Ops apply thẳng vào server. Chỉ mất 2 phút thay vì chờ pipeline build mất 15 phút.
  • Review code ngoại tuyến: Thay vì nhìn giao diện web, tôi thích đọc file patch bằng IDE. Cách này giúp tôi chạy thử code ngay lập tức để kiểm tra logic.

Tóm lại, nếu chỉ cần chuyển code nhanh, cứ git diff cho lẹ. Còn muốn giữ giá trị từng commit, git format-patch là chân ái. Hãy thử áp dụng ngay hôm nay, workflow của bạn chắc chắn sẽ chuyên nghiệp và linh hoạt hơn nhiều.

Share:
Tags: