Làm thế nào để bạn quản lý các thay đổi nhỏ mà bạn muốn giữ cục bộ trong đồng bóng?

Tôi đang xem xét việc chuyển một kho lưu trữ cvs 14 tuổi (nguyên vẹn lịch sử) sang đồng bóng. Tôi nghĩ rằng tôi đã giảm tất cả các bit chuyển đổi kỹ thuật, nhưng tôi vẫn có một số câu hỏi về hoạt động hiệu quả trong đồng bóng.

Một trong những điều tôi thấy rất nhiều trong các hộp cát cvs của các nhà phát triển cá nhân (bao gồm cả của tôi) là những thay đổi không được cam kết cục bộ không sẵn sàng được đẩy lên tuyến chính. Hiểu biết của tôi là đây là một điều xấu. Hầu hết các thí nghiệm của tôi với hg cho thấy những thay đổi không được cam kết là một điều tồi tệ cần phải có. Không có khả năng hợp nhất với họ là đủ cho điều đó. Vì vậy, những gì tôi muốn biết là làm thế nào những người khác sử dụng đồng bóng hàng ngày đối phó với nó. Làm thế nào để bạn đối phó với các thay đổi không đầy đủ đối với mã khi đến lúc cập nhật kho lưu trữ của bạn? Làm thế nào để bạn đối phó với những thay đổi cục bộ mà bạn chưa (chưa) muốn chia sẻ với các nhà phát triển khác?

Tôi xử lý nó theo cách này:

Trong kho lưu trữ cục bộ của mình, tôi cam kết mọi thay đổi, ngay cả khi tôi đang thử nghiệm. Nếu tôi ổn với thử nghiệm và thử nghiệm, tôi sẽ đẩy nó vào kho lưu trữ từ xa. Nếu không, nó sẽ nằm trong kho lưu trữ cục bộ của tôi (hoặc quay lại bản sửa đổi cũ hơn).

Ý tưởng là kho lưu trữ từ xa chỉ chứa các phiên bản làm việc, đã thử nghiệm của các dự án của tôi.

Có một vài điều tôi sẽ thêm.

Một là để đề nghị một công việc mà làm cho sử dụng khôn ngoan của xiên , mà tàu như là tiêu chuẩn với TortoiseHg .

Bất cứ khi nào tôi muốn cam kết một phần trong thư mục làm việc hiện tại của mình, tôi sẽ tạm gác những thay đổi mà tôi không muốn cam kết, biên dịch lại (để đảm bảo rằng tôi đã không sử dụng các bit dẫn đến việc biên dịch bị hỏng) và sau đó chạy thử nghiệm . Sau đó, tôi sẽ cam kết đầy đủ, làm việc và thử nghiệm thiết lập. Cuối cùng tôi sẽ chạy unsh 12 để khôi phục các thay đổi của tôi.

Nếu tôi có các thay đổi lâu dài hơn, giả sử tôi muốn một tệp cấu hình trên máy phát triển của mình luôn luôn trỏ đến cổng localhost 3333 chứ không phải máy chủ sản xuất, thì tôi sẽ xem xét sử dụng tiện ích mở rộng Mercurial Queues, được cung cấp với cả Mercurial và TortoiseHg .

Tôi không tin rằng những thay đổi không được cam kết thực chất là một điều xấu. Bạn đề cập đến "không thể hợp nhất với chúng" - nếu bạn có một thay đổi không được cam kết đối với một số tệp và bạn kéo và cập nhật một thay đổi cho tệp đó, Mercurial sẽ bắt đầu quá trình hợp nhất giống như bạn đã cam kết, sau đó yêu cầu hợp nhất. Ý của bạn là gì?

Vì vậy, đối với những thay đổi cục bộ mà bạn chưa muốn chia sẻ với các nhà phát triển khác, bạn có hai cách tiếp cận. Đầu tiên là giữ các thay đổi trong bản sao làm việc của bạn, nhưng không đẩy chúng ra, và cách khác là đặt chúng sang một bên, ra khỏi bản sao làm việc. Việc bạn chọn tùy thuộc vào việc bạn có muốn có những thay đổi này khi bạn làm việc hay không.

Nếu bạn giữ chúng trong bản sao làm việc, các thay đổi đến sẽ hoạt động tốt, vì vậy bạn chỉ cần tránh tạo ra các thay đổi gửi đi, và điều đó có nghĩa là tránh cam kết chúng. Nếu các tệp là mới, điều đó thật dễ dàng - đừng bỏ qua hg addchúng. Nếu chúng đã được theo dõi, thì bạn có thể loại trừ chúng ra khỏi cam kết một cách cụ thể hg commit --exclude foo.txt. Nếu bạn có một số lượng lớn tệp để loại trừ hoặc sẽ loại trừ chúng khỏi nhiều cam kết (ví dụ: thay đổi vĩnh viễn thành tệp cấu hình cục bộ), hãy xem phần mở rộng loại trừ .

Nếu bạn chuẩn bị chuyển các thay đổi sang một bên, bạn có một bộ tùy chọn khác. Điều đơn giản nhất chỉ đơn giản là sử dụng hg difftrên các tệp để tạo ra một bản vá mô tả chúng, mà bạn giữ ở đâu đó an toàn, sau đó hg patch --no-commitáp dụng lại bản vá đó khi bạn muốn thay đổi trở lại. Bạn có thể làm cho điều này mượt mà hơn bằng cách cài đặt phần mở rộng giá đỡ , phần mở rộng gác mái hoặc một số họ hàng khác. Bạn cũng có thể sử dụng tiện ích mở rộng hàng đợi , nhưng đó là sử dụng búa tạ để bẻ đai ốc. Bạn thậm chí có thể chỉ thực hiện các thay đổi, sau đó cập nhật lại cho phụ huynh và cam kết các công việc khác ở đó, để lại các thay đổi trong một nhánh ẩn danh cứng đầu - hg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}')(mặc dù có thể dễ dàng thực hiện thủ công hơn!). Sau đó, bạn sẽ phải cẩn thận không đẩy thay đổi đó.

Hai phương pháp cơ bản được sử dụng để phân tách các luồng phát triển.

• Đặt tên chi nhánh. Ý tưởng là, bạn làm việc trên chi nhánh của riêng bạn, nmichaels_branch_of_awemme. Bằng cách đó bạn có thể cam kết thay đổi của mình mà không cần phải làm việc với người khác. Sau đó, bạn hợp nhất từ ​​những người khác khi bạn cần công việc của họ và khi đến lúc có tính năng, bạn chuyển sang chi nhánh ổn định hơn để tích hợp. Tôi ủng hộ các chi nhánh được đặt tên.

• Bản sao vô danh. Điều này tạo ra một kho lưu trữ riêng cho hộp cát của bạn. Ở đây bạn chơi xung quanh cho đến khi bạn có được những gì bạn muốn, sau đó (có thể) thực hiện một bản vá MQ cho các cam kết của bạn và chuyển qua nơi bạn bắt đầu. Tôi không thích cách tiếp cận này, vì nó yêu cầu quản lý thư mục và có khả năng MQ hoạt động, có thể rất khó. Và với một số repos, họ có thể bắt đầu chỉ lớn hơn một chút cho việc này. Điều đó nói rằng, điều này dường như được ưa thích bởi các nhà phát triển Kiln.