Tại sao DVCS dường như tất cả đều có một nỗi ám ảnh phi lý về những thay đổi không được cam kết?


10

Xuất thân từ nền tảng SVN, một trong những điều khó nhất để làm quen khi làm việc với các hệ thống DVCS là cách mà tất cả họ dường như coi bất kỳ thay đổi không được cam kết nào giống như một quả bom hẹn giờ.

Trong Mercurial, nếu bạn cố gắng tìm nạp các thay đổi và bạn có bất kỳ thay đổi không được cam kết nào trong bản sao làm việc của mình, bạn phải nhảy qua các vòng để có được nó để hợp nhất các thay đổi đến. Hãy thử chuyển nhánh? Nó sẽ buộc bạn phải gác lại mọi thứ và sau đó bạn phải lập tức hủy bỏ tất cả mọi thứ ở đầu bên kia. (SVN không gặp rắc rối với một trong hai kịch bản này.)

Git là về cùng một cách. Tôi đang làm việc cùng với một nhà phát triển khác trong một dự án và tôi chỉ cố gắng chọn một trong những cam kết của anh ấy vào ngã ba của mình. Nó từ chối cho tôi vì tôi có những thay đổi không được cam kết trong bản sao làm việc của mình, trên các tệp hoàn toàn khác với những thay đổi trong cam kết của anh ấy. Thậm chí không có tùy chọn hợp nhất; Rõ ràng là tôi phải bỏ những thay đổi của mình trước!

Nếu một người đối xử với một thứ hoàn toàn vô hại với sự thận trọng cao độ như vậy, tôi sẽ gọi đó là "nỗi ám ảnh", một nỗi sợ phi lý nên được coi là một rối loạn tâm thần. Nhưng Git và Mercurial được thiết kế bởi hai nhóm nhà phát triển thông minh, hợp lý khác nhau, vì vậy tôi phải tự hỏi liệu họ có biết điều gì mà tôi không biết không.

Có một lý do kỹ thuật nào biện minh cho thái độ này đối với những thay đổi không được cam kết? Và nếu vậy, tại sao vấn đề trong câu hỏi dường như chỉ tồn tại trên DVCSes?


7
Không phải toàn bộ quan điểm của những điều này mà bạn có thể kiểm tra vào chi nhánh địa phương của mình một cách tầm thường sao? Hợp nhất từ ​​nhà phát triển khác sau đó trở thành hợp nhất thực tế thay vì cố gắng giải quyết ba nguồn (phiên bản của bạn, thay đổi của bạn, phiên bản của họ). Tôi không phải là chuyên gia trong lĩnh vực này, vì vậy có thể không có cơ sở.
Telastyn

3
Tôi đồng ý với Telastyn. Tôi nghĩ lý do bạn gặp phải những hạn chế có vẻ phi lý là vì bạn không sử dụng Git theo cách thành ngữ. Một trong những thế mạnh chính của Git là bạn có thể cam kết tại địa phương. Nếu tôi phải hợp nhất mã của người khác vào bản sao làm việc của mình, tôi sẽ chắc chắn là địa ngục cam kết đầu tiên tại địa phương. Cam kết địa phương là rẻ, dễ dàng để làm sạch, và một mạng lưới an toàn tuyệt vời. Tôi không ngạc nhiên khi quy trình làm việc của Git xoay quanh nó (và do đó, các cảnh báo và hạn chế cho rằng bạn muốn cam kết hơn là làm việc trên các tệp không được cam kết).
MetaFight

3
@Telastyn: Không, bạn không thể, vì việc đăng ký - ngay cả với chi nhánh địa phương của bạn - yêu cầu một lý do cam kết và tạo một bản ghi trong lịch sử. Vì vậy, nếu bạn kiểm tra thứ gì đó chưa sẵn sàng để cam kết, cuối cùng khi bạn sẵn sàng đẩy các thay đổi vào kho lưu trữ từ xa, lịch sử đó sẽ ở đó trừ khi bạn trải qua các hoạt động bổ sung để viết lại lịch sử. Điều đó không phù hợp với bất kỳ định nghĩa "tầm thường" nào mà tôi nhận ra, và dường như đối với tôi có rất nhiều sự phức tạp thêm mà không có bất kỳ lợi ích rõ ràng nào.
Mason Wheeler

Có thật không? "XYZ ổn định để hợp nhất từ ​​chính" là một gánh nặng, hoặc sẽ đi vào lịch sử quá lịch sự?
Telastyn

1
Bạn sẽ gửi một bài báo để xuất bản mà ít nhất là chỉnh sửa cho rõ ràng? Sau đó, không gửi loạt cam kết dự thảo đầu tiên của bạn để xuất bản. Có phải tất cả những người sẽ đọc mã của bạn rất có ích: quay lại và tạo ra chuỗi cam kết mà bạn sẽ viết nếu bạn có tầm nhìn xa để thực hiện theo cách đó ngay từ đầu.
Rebase

Câu trả lời:


4
  1. Trong DVCS - thế giới cam kết là rẻ và lịch sử là có thể thay đổi. WIP có thể là "bẩn", như bạn muốn: và tôi không thể thấy bất kỳ lý do nào chống lại "thả trạng thái hiện tại của tôi trong bộ thay đổi để lưu trữ"
  2. Lịch sử SVN là tuyến tính, do đó - bạn phải hợp nhất các bản nháp của bạn với các thay đổi từ các phiên bản mới. Sử dụng DVCS (tự nhiên) DAG và đầu bổ sung (cam kết + kéo + lên) cho lịch sử chuyển hướng sẽ an toàn hơn so với việc hợp nhất trên thư mục làm việc được sửa đổi bay với các thay đổi bên ngoài được tìm nạp
  3. Khi bạn chuyển đổi (sang một số nút ) đã sửa đổi WC trong Subversion, bạn sẽ thoát khỏi một hợp nhất bổ sung tiềm năng (trái với "cam kết cũ" - "chuyển đổi" - "hợp nhất phạm vi 1 vòng quay") ... và chúng tôi biết: hợp nhất trong SVN không phải là khía cạnh hoàn hảo của công cụ, trong khi đó không phải là vấn đề đối với DVCSes

Sơ yếu lý lịch

Đó không phải là một nỗi ám ảnh, đó là (đôi khi rất khắc nghiệt) việc tuân theo cách cư xử tốt "thường xuyên cam kết" (người dùng SVN đôi khi sợ phong cách này)

Và, cuối cùng, hg qnew|qpop|qpushlà giá hợp lý nhỏ cho sự gọn gàng và trật tự


1

Khi bạn hợp nhất hoặc chọn anh đào git, bạn đang tạo một cam kết ngay lập tức. Hoạt động không hoàn thành cho đến khi cam kết đó kết thúc và là một phần của lịch sử.

Bây giờ, điều gì sẽ xảy ra nếu gitcho phép bạn che đậy những thay đổi không được cam kết trong thư mục làm việc của bạn? Bạn sẽ có một thời gian (ít nhiều) khó phân biệt giữa các xung đột thay đổi / hợp nhất mà bạn cần quan tâm để hợp nhất / chọn cherry và những thay đổi mà bạn tự giới thiệu. Ngoài ra, gần như bạn không thể kiểm tra những gì bạn thực sự cam kết.

Do đó, việc buộc một thư mục làm việc sạch sẽ cho các tình huống hợp nhất sẽ giúp mọi thứ đơn giản và dễ quản lý. Rốt cuộc, tất cả những gì bạn cần làm là bỏ bớt những thay đổi không được cam kết của bạn trước khi hợp nhất và hủy bỏ chúng sau đó. Lưu ý rằng trong quy trình làm việc

git stash
git pull
git stash pop

bạn có hai thao tác hợp nhất (!). Một trong đó hợp nhất cam kết cuối cùng của bạn với các thay đổi đến và một thay đổi hợp nhất các thay đổi không được cam kết của bạn với cam kết hợp nhất kết quả. Theo cách này, bạn chỉ cần hợp nhất hai thứ thành một, tránh sự nhầm lẫn có thể xảy ra do cố gắng hợp nhất ba thứ thành một trong một thao tác trong khi cố gắng bỏ qua ba điều này. Các git stash/ git stash poplàm cho nó dễ dàng và rõ ràng rằng bạn đang bỏ qua những thay đổi không bị giam cho việc hợp nhất.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.