Tại sao tôi muốn làm git rebase?

Question

Tôi đã nhìn thấy rất nhiều người nói về git rebase và những gì nó làm, ví dụ: Hg: How to do a rebase like git's rebase và mọi người nói về những gì nó đạt được (cung cấp lịch sử tuyến tính), ví dụ: Ở đây Git rebase loses history, then why rebase? Nhưng tôi không thể hiểu tại sao bạn lại muốn làm điều này.

Có vẻ như chi phí lớn, để quay lại và sửa lại lịch sử cam kết của bạn (chắc chắn phải liên quan đến một số kết hợp xấu xí với xung đột n-way). Và tôi có thể tưởng tượng những trường hợp nó có thể gây hiểu nhầm, (ví dụ, nếu hai người giải quyết cùng một vấn đề theo nhiều cách khác nhau, nhưng lịch sử không cho thấy công việc của họ như đã xảy ra song song, dường như có thể dễ dàng dẫn đến những lời chỉ trích và oán giận trong một số môi trường mã hóa áp suất cao).

Điều bạn đạt được là biểu đồ lịch sử dễ hiểu hơn nhưng không chính xác. Điều gì làm cho điều đó đáng giá?

Xin cảm ơn trước.

Answer 1

Rebase hữu ích nhất khi đẩy một cam kết hoặc một số lượng nhỏ các cam kết được phát triển trong một khung thời gian ngắn (giờ hoặc phút).

Trước khi chuyển sang máy chủ được chia sẻ, trước tiên, bạn phải kéo các cam kết được thực hiện cho HEAD gốc trong thời gian chờ đợi — không làm như vậy sẽ tạo một cú đẩy không tiến nhanh. Khi làm như vậy, người ta có thể chọn giữa thao tác hợp nhất (git pull) hoặc hoạt động rebase (git pull --rebase). Tùy chọn hợp nhất, trong khi kỹ thuật hấp dẫn hơn, tạo ra một cam kết hợp nhất bổ sung. Đối với một cam kết nhỏ, sự xuất hiện của hai cam kết cho mỗi thay đổi thực sự làm cho lịch sử ít hơn có thể đọc được vì thao tác hợp nhất tách khỏi thông báo của cam kết.

Trong một cây phát triển được chia sẻ điển hình, mọi nhà phát triển đều kết thúc bằng cách chuyển sang một nhánh được chia sẻ bằng cách thực hiện một số biến thể của git pull; <resolve conflicts>; git push. Nếu họ đang sử dụng git pull mà không cần --rebase, điều gì xảy ra là gần như mỗi cam kết kết thúc bằng việc cam kết hợp nhất, mặc dù không có sự phát triển song song nào thực sự xảy ra. Điều này tạo ra một lịch sử đan xen từ những gì trong thực tế là một chuỗi tuyến tính của các cam kết. Vì lý do này, git pull --rebase là một lựa chọn tốt hơn cho những thay đổi nhỏ do phát triển ngắn, trong khi hợp nhất được dành riêng để tích hợp các chi nhánh tính năng tồn tại lâu dài.

Tất cả điều này áp dụng để rebasing local cam kết hoặc rebasing một chi nhánh ngắn ngủi được chia sẻ bởi các đồng nghiệp được kết nối chặt chẽ (ngồi trong cùng một phòng). Sau khi một cam kết được đẩy đến một chi nhánh thường xuyên theo sau bởi những người khác, nó nên không bao giờ được rebased.

Answer 2

Thực hiện rebase thường không bao gồm độ phân giải xung đột nhiều hơn hợp nhất, vì vậy chi phí so với số tiền đó là tối thiểu (chỉ cần thời gian để thực hiện lại các cam kết của bạn).

Như với hầu hết mọi thứ liên quan đến git, bạn chỉ nên rebase nếu bạn biết những gì bạn đang làm, và tại sao bạn đang làm việc đó. Dưới đây là một số lý do của tôi cho việc rebasing:

• Tôi đã làm việc trên một loạt bản vá chưa từng chạm vào bất kỳ thành phần nào đã bị thay đổi ngược dòng trong thời gian chờ đợi. Cam kết hợp nhất sẽ không chứa bất kỳ thông tin hữu ích nào trong trường hợp này.
• Tôi sắp gửi yêu cầu kéo trên GitHub và cam kết hợp nhất bắt buộc sẽ có nhiều công việc.Bằng cách rebasing đầu tiên, tôi thực hiện yêu cầu pull dễ dàng hơn cho chủ sở hữu ngược dòng để xử lý. Chắc chắn tôi có thể hợp nhất thay vào đó, nhưng vì họ chưa bao giờ thấy mã của tôi trước đây, điều đó sẽ làm cho chuỗi bản vá khó đọc hơn.
• Tôi đang hợp nhất các thay đổi từ phía trên và có nhiều xung đột. git rebase cho phép tôi giải quyết các xung đột này về cam kết tại một thời điểm, làm cho nó dễ hiểu hơn và kiểm tra khi tôi đi. Nếu tôi quan tâm đến việc duy trì một cam kết hợp nhất, tôi có thể quay trở lại sau đó với một phiên bản không được rebased của nhánh, hợp nhất nó với upstream, sau đó sử dụng diff so với phiên bản rebased khi xung đột giải quyết commit merge.