Có phải quy tắc vàng của Git Hồi là rất cần thiết?

Gần đây tôi đã có một cuộc thảo luận với những người hoàn toàn trái ngược với chiến lược rebase của các nhánh tính năng trên GIT. Nó dường như là một mô hình được chấp nhận để chỉ sử dụng rebase cho các chi nhánh địa phương, tư nhân nhưng không bao giờ sử dụng nó khi có một số người làm việc trên cùng một tính năng & chi nhánh, theo cái gọi là "Quy tắc nổi loạn vàng" này (như được giải thích ở đây: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

Tôi chỉ ngạc nhiên khi có sự đồng thuận về điều này. Tôi đã làm việc 3 năm với một chiến lược nổi loạn hoàn toàn, với khoảng 20 nhà phát triển làm việc cùng nhau và đoán xem, nó đã hoạt động như thế nào.

Quá trình cơ bản là:

• Bạn tạo nhánh tính năng của mình, hãy gọi nó là "myfeature" và đẩy nó về nguồn gốc / myfeature
• Những người khác có thể kiểm tra và làm việc với nó
• Đôi khi bạn có thể rebase nó từ master: từ "myfeature", git rebase origin / master ; và sau đó, vâng, bạn phải đẩy nó.
• Điều gì xảy ra khi những người khác muốn đẩy mạnh cam kết của họ? Họ chỉ rebase nó: git rebase origin / myfeature . Vì vậy, bây giờ họ đang tiến nhanh và có thể đẩy nó mà không cần ép buộc.

Nguyên tắc duy nhất để tôn trọng là nhánh tính năng thuộc sở hữu của một ai đó . Chủ sở hữu là người duy nhất có thể đẩy.

Vì vậy, tôi thừa nhận: ngay khi có lực đẩy, có nguy cơ mắc lỗi. Đung. Nhưng cũng có nhiều cách để khắc phục lỗi và thực sự, trong 3 năm phát triển, tôi đã không thấy nhiều sai lầm về lực lượng và khi nó xảy ra, chúng tôi luôn tìm ra cách phục hồi đúng cách.

Vậy, tại sao "Nguyên tắc vàng nổi loạn" này lại được chấp nhận rộng rãi như vậy? Có điều gì khác tôi đã bỏ lỡ với điều đó? Tôi hiểu rằng nó yêu cầu tối thiểu tổ chức (mọi chiến lược đều yêu cầu một số tổ chức), nhưng nó hoạt động.

Vấn đề với lực đẩy không phải là về nhánh tính năng và chủ của bạn, mà là về việc đẩy chủ của bạn sang chủ nhân của người khác - sự đồng bộ hóa đó sẽ ghi đè lên chủ nhân của họ bằng các thay đổi của bạn, bỏ qua mọi thứ trên đầu họ.

Xem xét mối nguy hiểm này, có một lý do tại sao bạn không nên sử dụng nó trừ khi mọi thứ đã bị hỏng và bạn hoàn toàn cần phải sử dụng nó để sửa chữa. Một hệ thống SCM không cần phải bị ép buộc như thế này, nếu nó xảy ra vì có gì đó không ổn (và cách tiếp cận đầu tiên của tôi trong những trường hợp như vậy sẽ là khôi phục lại các bản sao lưu và lặp lại các hoạt động để giữ nguyên lịch sử).

Vì vậy, có lẽ câu hỏi là tại sao bạn lại nổi loạn? Vì lịch sử 'sạch' khi đưa các tính năng trở lại thành chủ? Nếu vậy, bạn đang ném ra tất cả lịch sử tốt liên quan đến việc phân nhánh vì lý do phong cách hoàn toàn. Sáp nhập nhanh IMHO cũng không phải là một cách tốt nhất, bạn nên giữ tất cả lịch sử để bạn có thể thấy những gì bạn thực sự đã làm, không phải là một phiên bản vệ sinh sau đó.

Rebase không cần thiết, như bạn nói nó chủ yếu là mỹ phẩm. Đôi khi nó đơn giản hơn rất nhiều sau đó là một sự hợp nhất. Vì vậy, nó có thể có một số giá trị "thực tế", nhưng chỉ "đôi khi"

Sử dụng rebase không đúng cách có thể tốn kém. Không có khả năng mất dữ liệu nếu bạn biết đủ để không hoảng loạn và tìm kiếm các quy trình phục hồi, nhưng "không ai cố gắng trong một thời gian tôi phải sửa ..." không phải là tuyệt vời. Cũng không có ai đốt thời gian để phục hồi nghiên cứu và thử nghiệm khi họ có thể đã thêm các tính năng hoặc xóa lỗi (hoặc ở nhà với gia đình).

Với sự đánh đổi đó, kết quả của "rất ít người thực hiện một cuộc nổi loạn và thúc ép" không có gì đáng ngạc nhiên.

Một số quy trình công việc có thể làm giảm rủi ro, ví dụ như giảm nó xuống "không miễn là bạn nhớ những nhánh nào bạn được phép buộc và những gì bạn không thể". Trong thực tế, chúng có thể đủ an toàn để biện minh cho rủi ro, nhưng mọi người thường đưa ra lựa chọn dựa trên văn hóa dân gian lớn hơn. Sau đó, một lần nữa trong thực tế, lợi ích là khá nhỏ, vậy rủi ro thực sự cần phải nhỏ đến mức nào?

Để thêm một giọng nói khác:

Có, nếu bạn làm việc như bạn mô tả, không có vấn đề gì với việc sử dụng rebasevà đẩy mạnh. Điểm quan trọng là: Bạn có một thỏa thuận trong nhóm của bạn.

Các cảnh báo về rebasevà bạn bè là cho trường hợp không có thỏa thuận đặc biệt. Thông thường, git bảo vệ bạn tự động, ví dụ, bằng cách không cho phép đẩy không nhanh về phía trước. Sử dụng rebasevà lực đẩy đè lên sự an toàn đó. Điều đó ổn nếu bạn có một cái gì đó khác.

Trong nhóm của tôi, đôi khi chúng tôi cũng phản ứng lại các nhánh tính năng nếu lịch sử đã trở nên lộn xộn. Chúng tôi hoặc xóa chi nhánh cũ và tạo một cái mới với một tên mới hoặc chúng tôi chỉ phối hợp không chính thức (điều này là có thể bởi vì chúng tôi là một nhóm nhỏ và không ai khác làm việc trong kho lưu trữ của chúng tôi).

Lưu ý rằng bản thân dự án git cũng thực hiện một điều tương tự: Họ có một nhánh tích hợp thường xuyên được tạo lại, được gọi là "pu" ("cập nhật được đề xuất"). Nó được ghi nhận rằng chi nhánh này được tạo lại thường xuyên, và bạn không nên dựa trên công việc mới.

Vì vậy, tôi thừa nhận: ngay khi có lực đẩy, có nguy cơ mắc lỗi. Đung. Nhưng cũng có nhiều cách để khắc phục lỗi và thực sự, trong 3 năm phát triển, tôi đã không thấy nhiều sai lầm về lực lượng và khi nó xảy ra, chúng tôi luôn tìm ra cách phục hồi đúng cách.

Lý do mà người dùng Git có xu hướng tránh lịch sử có thể thay đổi được chia sẻ là vì không có tự động tránh hoặc sửa chữa các vấn đề này. Bạn phải biết những gì bạn đang làm, và bạn phải sửa chữa mọi thứ bằng tay nếu bạn làm hỏng. Cho phép chính xác một người thực hiện lực đẩy là không trực quan và trái với thiết kế phân tán của Git. Điều gì xảy ra nếu người đó đi nghỉ? Có ai khác tạm thời sở hữu chi nhánh? Làm thế nào để bạn biết họ sẽ không đi bộ trên tất cả những gì chủ sở hữu ban đầu đang làm? Và trong thế giới nguồn mở, điều gì xảy ra nếu chủ sở hữu chi nhánh dần dần rời khỏi cộng đồng mà không chính thức rời đi? Bạn có thể mất rất nhiều thời gian chờ đợi để trao quyền sở hữu chi nhánh cho người khác.

Nhưng vấn đề thực sự là đây: Nếu bạn gây rối và không nhận ra ngay lập tức, những cam kết cũ cuối cùng sẽ biến mất sau khi đủ thời gian trôi qua. Tại thời điểm đó, vấn đề có thể không thể phục hồi (hoặc ít nhất, có khả năng rất khó phục hồi, tùy thuộc vào câu chuyện sao lưu của bạn trông như thế nào - bạn có sao lưu các bản sao cũ của kho Git của mình không, không chỉ là bản sao?).

Tương phản điều này với công việc tiến hóa Changeet của Mercurial (mà tôi cần lưu ý, vẫn chưa kết thúc hoặc ổn định). Mọi người đều có thể thực hiện bất kỳ thay đổi nào đối với lịch sử mà họ thích, miễn là các thay đổi không được đánh dấu công khai. Những sửa đổi và nổi loạn này có thể được đẩy và kéo với hoàn toàn không bị trừng phạt, không cần chủ sở hữu chi nhánh. Không có dữ liệu nào bị xóa; toàn bộ kho lưu trữ cục bộ chỉ là phụ lục. Những thay đổi không còn cần thiết được đánh dấu lỗi thời, nhưng được giữ vô thời hạn. Cuối cùng, khi bạn làm rối tung lịch sử của mình (được coi là một phần bình thường trong quy trình làm việc hàng ngày của bạn), sẽ có một lệnh tiện lợi để tự động dọn dẹp nó cho bạn. Đây là loại người UX mong đợi trước khi họ đi sửa đổi lịch sử chia sẻ.