Push — nó là gì, git push hoạt động thế nào và khi nào cần

Push trong Git là gì

Git push là lệnh truyền commit từ kho lưu trữ cục bộ đến kho lưu trữ từ xa. Không giống như commit, chỉ lưu thay đổi trên máy cục bộ của nhà phát triển, push công bố những thay đổi đó cho toàn nhóm. Push là bước bắt buộc trước khi tạo Pull Request và triển khai.

Kiến trúc Git giả định rằng mỗi nhà phát triển làm việc trong kho lưu trữ cục bộ của riêng họ. Các commit được tạo cục bộ và tích lũy cho đến khi nhà phát triển quyết định push. Điều này mang lại sự tự do: bạn có thể tạo nhiều commit cục bộ, thử nghiệm và viết lại lịch sử mà không ảnh hưởng đến đồng nghiệp.

# Push lên remote origin, nhánh main
git push origin main

# Push nhánh hiện tại lên remote với upstream
git push -u origin feature/new-dashboard

# Push tất cả nhánh có tên khớp
git push --all origin

# Force push với lease (force push an toàn)
git push --force-with-lease

Sau khi push, kho lưu trữ từ xa cập nhật refs (tham chiếu nhánh) để trỏ đến các commit mới. Các nhà phát triển khác có thể lấy những thay đổi này thông qua git pull hoặc git fetch. Sự trao đổi commit này tạo thành nền tảng của phát triển cộng tác.

Cách git push hoạt động

Lệnh git push so sánh nhánh cục bộ và nhánh từ xa, chỉ truyền các commit bị thiếu. Git không gửi lại tất cả tệp — chỉ truyền delta, giúp push nhanh ngay cả với kho lưu trữ lớn. Giao thức Git sử dụng truyền thông minh, giảm thiểu lượng dữ liệu được truyền.

Nếu nhánh từ xa chứa các commit không có ở cục bộ, push sẽ bị từ chối. Đây là cơ chế bảo vệ ngăn mất thay đổi. Trong tình huống này, nhà phát triển phải chạy git pull trước, hợp nhất các thay đổi, sau đó mới push lại. Một giải pháp thay thế là force push, ghi đè lên nhánh từ xa, nhưng phải được sử dụng thận trọng.

Hiểu về kho lưu trữ từ xa là chìa khóa để push đúng cách. Thông thường, origin là tên kho lưu trữ từ xa mặc định. Lệnh git remote -v hiển thị danh sách các kho lưu trữ từ xa và URL của chúng. Bạn có thể thêm nhiều remote (ví dụ: origin cho kho chính và upstream cho fork).

Khi nào cần push thay đổi

Nguyên tắc chính: push sau mỗi giai đoạn công việc hoàn thành về mặt logic. Nếu nhà phát triển đã hoàn thành một nhiệm vụ hoặc một phần của nó — đã đến lúc push. Tuy nhiên, không nên push công việc chưa hoàn thành làm hỏng bản dựng. Bản dựng không hỏng là yêu cầu tối thiểu để push vào bất kỳ nhánh nào.

Trong phát triển nhóm, nhịp điệu sau được áp dụng: buổi sáng — git pull để lấy thay đổi của đồng nghiệp, trong ngày — vài commit và một hoặc hai lần push, buổi tối — push cuối cùng của tất cả các nhiệm vụ đã hoàn thành. Nhà phát triển càng push thường xuyên thì nguy cơ xung đột hợp nhất càng thấp và tiến độ công việc càng minh bạch.

• Sau khi hoàn thành nhiệm vụ — commit và push giải pháp cuối cùng vào nhánh tính năng
• Trước khi về — push công việc chưa hoàn thành vào nhánh tính năng (không phải main!)
• Trước khi tạo PR — đảm bảo tất cả commit đã được push và sẵn sàng cho đánh giá
• Sau khi rebase — push với --force-with-lease vào nhánh tính năng của bạn

Quy tắc push an toàn

Push an toàn là một tập hợp các quy tắc ngăn mất dữ liệu và xung đột trong nhóm. Quy tắc đầu tiên và quan trọng nhất: không bao giờ push trực tiếp vào nhánh main hoặc master nếu dự án chưa cấu hình triển khai trực tiếp. Trong các nhóm hiện đại, bảo vệ nhánh main được cấu hình ở cấp độ bảo vệ nhánh GitHub.

Quy tắc thứ hai: đồng bộ với nhánh từ xa trước khi push. Chạy git pull --rebase để tránh commit hợp nhất khi gộp. Điều này đơn giản hóa lịch sử và làm cho nó tuyến tính. Nếu push bị từ chối — không sử dụng force push đơn thuần, mà trước hết hãy tìm hiểu commit nào đã xuất hiện trên nhánh từ xa.

Quy tắc thứ ba: thiết lập hook pre-push tự động chạy kiểm thử và lint trước khi gửi. Nếu kiểm thử thất bại — push bị chặn. Các hook này được cấu hình qua Husky hoặc Git hook (tệp pre-push trong .git/hooks).

Quy tắc thứ tư: không push tệp nhị phân lớn. Git không được thiết kế để lưu trữ tạo phẩm nhị phân — chúng làm phình kho lưu trữ và làm chậm các thao tác. Đối với tệp lớn, hãy sử dụng Git LFS (Large File Storage). Nếu một tệp nhị phân đã được push và nằm trong lịch sử, nó phải được xóa qua git filter-branch.

Làm gì nếu push thất bại

Nguyên nhân phổ biến nhất của push thất bại là nhánh từ xa chứa các commit không có ở cục bộ. Điều này xảy ra khi nhà phát triển khác đã push thay đổi của họ vào cùng nhánh. Giải pháp: chạy git pull, giải quyết mọi xung đột và push lại.

# Push bị từ chối — fetch và rebase trước
git fetch origin
git rebase origin/main
# Giải quyết xung đột, sau đó:
git push --force-with-lease

# Hoặc đơn giản là hợp nhất các thay đổi từ xa
git pull origin main
git push

Nguyên nhân thứ hai — thiếu quyền ghi vào nhánh. Nếu nhánh main được bảo vệ bởi quy tắc bảo vệ nhánh, push trực tiếp bị cấm. Giải pháp: push vào nhánh tính năng và tạo Pull Request. Cài đặt bảo vệ thường được quản lý qua cài đặt GitHub hoặc nhánh được bảo vệ của GitLab.

Nguyên nhân thứ ba — vấn đề xác thực. Thông tin đăng nhập cũ, chuyển sang SSH hoặc thay đổi mã thông báo truy cập cá nhân. Giải pháp: kiểm tra URL từ xa (git remote -v) và cập nhật thông tin đăng nhập. Từ năm 2021, GitHub đã ngừng xác thực bằng mật khẩu cho HTTPS — sử dụng mã thông báo cá nhân hoặc khóa SSH.