Khi tôi làm việc trên một nhánh tính năng, tôi có xu hướng muốn dọn sạch các cam kết trong nhánh bằng cách sử dụng một rebase tương tác trước khi công việc của tôi được xem xét và tích hợp trong nhánh chính.

Trong quá trình phát triển tính năng, tôi muốn đẩy công việc trung gian của mình đến kho lưu trữ từ xa như một biện pháp dự phòng. Tức là khi ổ cứng của tôi gặp sự cố, tôi không muốn toàn bộ nhánh tính năng của mình bị mất.

Tuy nhiên, điều này dẫn đến thực tế là tôi thường phải thực hiện một git push --forcekho lưu trữ từ xa sau một cuộc nổi loạn, một hành động thường được tán thành. Hoặc như trang github được liên kết nói:

Vì việc thay đổi lịch sử cam kết của bạn có thể gây khó khăn cho những người khác khi sử dụng kho lưu trữ, nên nó được coi là thực hành xấu để phản hồi lại các cam kết khi bạn đã bị đẩy vào kho lưu trữ.

Có một chính sách (thường được chấp nhận) để giải quyết xung đột này?

Tại sao đây không phải là bản sao của "Nguyên tắc vàng nổi loạn" rất cần thiết?

Câu hỏi của tôi ở đây yêu cầu một chính sách để giải quyết xung đột giữa việc muốn sao lưu công việc của bạn trong kho lưu trữ từ xa và từ chối công việc của bạn , trong khi câu hỏi khác cố gắng phủ nhận rằng có một cuộc xung đột và hỏi tại sao một số người nghĩ rằng xung đột tồn tại, và do đó hỏi tại sao "nó là thiết yếu" không đẩy lực lượng nổi dậy?

Câu hỏi chính để tự hỏi:

• Bạn có giữ chi nhánh từ xa của bạn sau khi hợp nhất trở lại thành chủ?

Nếu bạn xóa nhánh tính năng từ xa sau khi hợp nhất thành chủ, bạn đã mất lịch sử. Giả sử bạn squash / rebase chi nhánh trước khi thực hiện hợp nhất / PR, bạn sẽ mất lịch sử này. Tất cả lực đẩy của bạn đang làm trong trường hợp này là cho phép bạn sử dụng github làm dự phòng.

Tình huống mà bạn muốn giữ lịch sử và không ép buộc là nếu chi nhánh từ xa của bạn vẫn tồn tại sau khi được sáp nhập và không chỉ tồn tại trong một khoảng thời gian tạm thời.

Tôi cho rằng bạn đang hỏi liệu tôi có giữ được chi nhánh không bị cấm không? Không, AFAIC. Tuy nhiên, việc ép buộc về mặt lý thuyết có thể dẫn đến việc mất các cam kết từ những người dùng khác đã đẩy đến cùng chi nhánh

Có vẻ như bạn có nhiều người đẩy đến chi nhánh đó cùng một lúc. Đây có nghĩa là bạn làm quan tâm đến lịch sử trên các chi nhánh.

Thay vào đó, những gì bạn có thể làm cho công việc trung gian của mình là tạo một nhánh của nhánh đó. Bạn có thể đẩy sang điều này và sau đó khởi động lại tất cả các cam kết của bạn thành một cam kết duy nhất trước khi hợp nhất, vì vậy khi bạn hợp nhất chúng vào nhánh tính năng của mình, bạn chỉ có 1 cam kết (với lịch sử bị từ chối của toàn bộ chi nhánh của bạn).

Tôi đang liệt kê một số khả năng ở đây mà vượt qua tâm trí của tôi.

Luôn nổi loạn trên một nhánh mới

Khi có một nhánh lộn xộn some-feature, hãy khởi động lại nó trên một nhánh mới. Ví dụ

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

Sau đó đã some-feature-rebasexem xét và tích hợp.

Vấn đề: Một nhược điểm lớn ở đây là, nói đúng ra, bạn cần một nhánh mới cho mỗi cuộc nổi loạn. (Chẳng hạn, bạn có thể có nhiều lần nổi loạn nếu bạn thực hiện thay đổi sau khi xem xét mã)

Sử dụng git push --force-with-lease

Tôi vừa tìm hiểu về sự git push --force-with-leasethay thếgit push --force ,

từ chối cập nhật một chi nhánh trừ khi đó là trạng thái mà chúng ta mong đợi; tức là không ai cập nhật chi nhánh ngược dòng.

Vấn đề : Điều này dường như cải thiện trực tiếp tình huống chúng ta chỉ sử dụng --force, nhưng vẫn có một số cảnh báo, đáng chú ý nhất là khi tôi thực hiện git fetchthay vì git pullcập nhật các nhánh ngược dòng cục bộ của chúng tôi, đánh lừa --force-with-leaserằng không có thay đổi nào không được thực hiện trên điều khiển từ xa chi nhánh.