Làm cách nào tôi có thể sử dụng git rebase mà không cần phải đẩy mạnh?

Trong nỗ lực đạt được niết bàn git, tôi đang dành cả ngày để học cách tận dụng rebase cho các tình huống mà tôi hiện đang hợp nhất.

Khi chạy qua những gì tôi coi là luồng git 101 (mà tôi trình bày bên dưới), tôi phải thực hiện push --forcekhi đẩy các thay đổi của mình trở lại nguồn gốc.

Tôi không phải là người duy nhất - tôi biết rằng đây là mặt đất có mái che (xem 1 , 2 , 3 , 4 , 5 ) và tôi hiểu các lý do kỹ thuật tại sao lực lượng là cần thiết. Vấn đề của tôi là điều này --- có rất nhiều (nhiều) mục blog ca ngợi rebase và cách nó đã thay đổi cuộc sống của họ (xem 1 , 2 , 3 , 4 để liệt kê một số), nhưng không ai trong số họ đề cập đó push --forcelà một phần của dòng chảy của chúng. Tuy nhiên, gần như mọi câu trả lời cho các câu hỏi stackoverflow hiện tại đều nói những câu như "vâng, nếu bạn định rebase, bạn phải sử dụng push --force".

Với số lượng và mức độ tin cậy của những người ủng hộ rebase, tôi phải tin rằng việc sử dụng 'push --force' không phải là một phần cố hữu của quy trình rebase và nếu ai đó thường xuyên phải thúc đẩy thì họ đang làm sai .

push --forcelà một điều tồi tệ .

Vì vậy, đây là dòng chảy của tôi. Bằng cách nào tôi có thể đạt được kết quả tương tự mà không cần đến sức mạnh?

Ví dụ đơn giản

Hai chi nhánh:

• v1.0 - một nhánh phát hành, chỉ chứa các bản vá lỗi
• master - mọi thứ cho bản phát hành lớn tiếp theo.

Tôi có một vài cam kết về bản vá và một vài cam kết cho bản phát hành tiếp theo.

Tôi muốn kết hợp các bản vá vào tổng thể của mình để chúng không bị mất cho bản phát hành tiếp theo. Tiền khai sáng, tôi chỉ đơn giản là:

git checkout master
git merge v1.0

Nhưng bây giờ tôi đang cố gắng

git checkout master
git rebase v1.0

Vì vậy, bây giờ tôi ở đây:

Thời gian cho:

git push

Không có con xúc xắc.

Rebasing là một công cụ tuyệt vời, nhưng nó hoạt động tốt nhất khi bạn sử dụng nó để tạo các hợp nhất tua đi nhanh chóng cho các nhánh chủ đề vào chính. Ví dụ: bạn có thể căn cứ lại nhánh tiện ích bổ sung mới của mình so với nhánh phụ:

git checkout add-new-widget
git rebase -i master

trước khi thực hiện hợp nhất tua đi nhanh nhánh thành cái. Ví dụ:

git checkout master
git merge --ff-only add-new-widget

Lợi ích của việc này là lịch sử của bạn sẽ không có nhiều cam kết hợp nhất phức tạp hoặc xung đột hợp nhất, bởi vì tất cả các thay đổi của bạn sẽ được hoàn nguyên vào đầu tổng thể trước khi hợp nhất. Một lợi ích phụ là bạn đã giảm giá, nhưng bạn không cần phải sử dụng git push --forcevì bạn không làm tắc nghẽn lịch sử trên nhánh chính.

Đó chắc chắn không phải là trường hợp sử dụng duy nhất cho rebase hoặc quy trình làm việc duy nhất, nhưng đó là một trong những cách sử dụng hợp lý hơn cho nó mà tôi đã thấy. YMMV.

@CodeGnome nói đúng. Bạn không nên rebase master trên nhánh v1.0 mà là nhánh v1.0 trên master, điều đó sẽ tạo nên sự khác biệt.

git checkout -b integrate_patches v1.0
git rebase master
git checkout master
git merge integrate_patches

Tạo một nhánh mới trỏ đến v1.0, di chuyển nhánh mới đó lên trên cái chính và sau đó tích hợp phiên bản mới của các bản vá lỗi V1.0 vào nhánh chính. Bạn sẽ kết thúc với một cái gì đó như:

o [master] [integrate_patches] Another patch on v1.0
o A patch on v1.0
o Another change for the next major release
o Working on the next major release
|  o [v1.0] Another path on v1.0
|  o A patch on v1.0
| /
o Time for the release

Cách sử dụng rebase này được khuyến nghị bởi tài liệu git chính thức .

Tôi nghĩ rằng bạn đã đúng về việc git push --force: bạn chỉ nên sử dụng nó nếu bạn đã phạm sai lầm và đẩy một cái gì đó bạn không muốn.

Bạn phải thúc đẩy nếu bạn rebase và bạn đã xuất bản các thay đổi của mình, phải không?

Tôi sử dụng rebase rất nhiều, nhưng tôi hoặc xuất bản lên một cái gì đó riêng tư mà lực đẩy không quan trọng (ví dụ: bản sao của riêng tôi trên GitHub, như một phần của yêu cầu kéo) hoặc tôi rebase trước khi đẩy lần đầu tiên.

Đây là trọng tâm của quy trình làm việc mà bạn sử dụng rebase, nhưng đừng ép quá nhiều: không xuất bản mọi thứ cho đến khi chúng sẵn sàng, không rebase sau khi bạn đẩy.

Tôi nghĩ rằng có một trường hợp sử dụng tốt cho mô hình rebase-then-force-push này không phải là kết quả của một sự thúc đẩy nhầm lẫn: tự bạn làm việc trên một nhánh tính năng từ nhiều vị trí (máy tính). Tôi làm việc này thường xuyên, vì đôi khi tôi làm việc tại văn phòng trên máy tính để bàn và đôi khi ở nhà / trang web của khách hàng trên máy tính xách tay của mình. Đôi khi tôi cần rebase để theo kịp với nhánh chính và / hoặc để làm cho các hợp nhất sạch hơn, nhưng tôi cũng cần phải đẩy mạnh khi tôi rời một máy để bắt đầu làm việc trên máy khác (nơi tôi chỉ kéo). Hoạt động như một cái duyên, miễn là tôi là người duy nhất làm việc trên chi nhánh.

Đây là những gì tôi sử dụng (giả sử tên chi nhánh của bạn là foobar ):

git checkout master              # switch to master
git rebase   foobar              # rebase with branch
git merge -s ours origin/master  # do a basic merge -- but this should be empty
git push origin master           # aaand this should work

tl; dr hợp nhất với các nhánh chia sẻ, rebase với các nhánh riêng lẻ. --force-with-leaselà một sự thay thế an toàn hơn cho vũ lực và sẽ giúp bạn đạt được niết bàn đã nói mà không có bản chất hủy diệt của vũ lực.

Một nguyên tắc chung mà tôi đã thấy làm việc cho các quy trình làm việc của các nhóm khác nhau là sử dụng mergecho các nhánh chia sẻ (tức là làm chủ hoặc phát triển) và sử dụng rebasekhi làm việc trên nhánh tính năng của riêng bạn. Đây là vòng đời điển hình của một nhánh tính năng

git checkout master
git checkout -b new-feature
git commit -am "commit new work"
git push -u origin new-feature
# have code reviewed, run CI, etc.,
# meanwhile master has new commits
git checkout master
git pull
git rebase -i master # -i for interactive rebase allows you to squash intermediate commits
git push --force-with-lease
git merge master

Một phiên bản tiếng Anh đơn giản của những gì chúng tôi đã làm ở đây:

1. Đã tạo một nhánh mới ngoài tổng thể
2. Hoàn thành công việc trên nhánh và được đẩy sang điều khiển từ xa
3. từ bỏ chủ nhân
4. Đẩy công việc sang điều khiển từ xa với force-with-lease
5. hợp nhất thành cái chính với một nhật ký git rất rõ ràng, giảm sự lộn xộn từ nhiều lần hợp nhất từ ​​nhánh chia sẻ của chúng tôi để nhánh của chúng tôi "bắt kịp" với cái chính mới nhất (nhánh chia sẻ)

Bước thứ 4 THỰC SỰ rất quan trọng và là một trong những lý do chính khiến tôi bắt đầu ủng hộ việc sử dụng rebase. force-with-leasekiểm tra điều khiển từ xa để xem có bất kỳ cam kết mới nào đã được thêm vào hay không. Nếu của bạn git pushđã được chứng minh là phá hoại, nó sẽ không thúc đẩy!

Tôi hy vọng điều này giúp ai đó tự tin hơn để sử dụng rebase.