Mercurial - trở lại phiên bản cũ và tiếp tục từ đó


249

Tôi đang sử dụng Mercurial tại địa phương cho một dự án (đó là repo duy nhất không có sự thúc đẩy / kéo đến / từ bất kỳ nơi nào khác).

Đến nay nó đã có một lịch sử tuyến tính. Tuy nhiên, điều hiện tại tôi đang làm việc bây giờ tôi nhận ra là một cách tiếp cận tồi tệ và tôi muốn quay lại phiên bản trước khi tôi bắt đầu và thực hiện nó theo một cách khác.

Tôi là một chút nhầm lẫn với branch/ revert/ update -Clệnh trong Mercurial. Về cơ bản, tôi muốn trở lại phiên bản 38 (hiện tại là 45) và các cam kết tiếp theo của tôi có 38 là cha mẹ và tiếp tục từ đó. Tôi không quan tâm nếu bản sửa đổi 39-45 bị mất vĩnh viễn hoặc kết thúc trong một nhánh chết của chính họ.

Tôi cần lệnh / bộ lệnh nào?


6
Đối với bất kỳ ai quan tâm, điều này đã xuất hiện trên thanh bên liên quan, đó là một lời giải thích tuyệt vời về hoàn nguyên so với cập nhật: stackoverflow.com/questions/2506804/ Lỗi
Paolo

Câu trả lời:


150
hg update [-r REV]

Nếu sau này bạn cam kết, bạn sẽ tạo ra một chi nhánh mới một cách hiệu quả. Sau đó, bạn có thể tiếp tục chỉ làm việc trên nhánh này hoặc cuối cùng hợp nhất cái hiện có vào nó.


6
cam kết tiếp theo sẽ tạo ra một chi nhánh mới. Nếu bạn không chắc chắn, chỉ cần tạo một bản sao lưu của kho lưu trữ của bạn (với bản sao đang hoạt động), hãy dùng thử - không thích kết quả -> bắt đầu lại từ đầu miễn phí
van

Đây là một câu trả lời đáng ngờ vì nó hợp nhất các thay đổi hiện tại của bạn với bản sửa đổi cũ có lẽ là điều bạn không muốn làm. Câu trả lời đúng phải là hg hoàn nguyên.
Trevor de Koekkoek

Câu trả lời là tốt, ngoại trừ bit về hợp nhất (Tôi không nghĩ người hỏi sẽ muốn hợp nhất).
ctrl-alt-delor

3
@NeonWarge REV chỉ đơn giản là một trình giữ chỗ cho bản sửa đổi. Nó có thể là số của nó, hàm băm của nó, một dấu trang và vân vân. Trevor: điều này không đáng ngờ vì nó không hợp nhất bất cứ điều gì. Không cần.
Danman

401

Đây là bảng cheat trên các lệnh:

  • hg updatethay đổi bản sửa đổi bản sao làm việc của bạn và cũng thay đổi nội dung tệp để phù hợp với bản sửa đổi phụ huynh mới này. Điều này có nghĩa là các cam kết mới sẽ được thực hiện từ bản sửa đổi mà bạn cập nhật.

  • hg revertchỉ thay đổi nội dung tệp và để lại bản sửa đổi cha mẹ bản sao làm việc. Bạn thường sử dụng hg revertkhi bạn quyết định rằng bạn không muốn giữ những thay đổi không được cam kết mà bạn đã thực hiện đối với một tệp trong bản sao làm việc của mình.

  • hg branchbắt đầu một chi nhánh mới được đặt tên. Hãy nghĩ về một nhánh được đặt tên như là một nhãn bạn gán cho các bộ thay đổi. Vì vậy, nếu bạn làm như vậy hg branch red, thì các thay đổi sau đây sẽ được đánh dấu là thuộc về nhánh "đỏ". Đây có thể là một cách hay để tổ chức các bộ thay đổi, đặc biệt là khi những người khác nhau làm việc trên các nhánh khác nhau và sau này bạn muốn xem một bộ thay đổi bắt nguồn từ đâu. Nhưng bạn không muốn sử dụng nó trong tình huống của bạn.

Nếu bạn sử dụng hg update --rev 38, thì bộ thay đổi 39 Pha45 sẽ bị bỏ lại như một ngõ cụt - một cái đầu lơ lửng như chúng ta gọi. Bạn sẽ nhận được cảnh báo khi bạn đẩy vì bạn sẽ tạo "nhiều đầu" trong kho lưu trữ mà bạn đẩy tới. Cảnh báo là có vì nó là bất lịch sự khi để những người như vậy xung quanh vì họ đề nghị ai đó cần phải hợp nhất. Nhưng trong trường hợp của bạn, bạn chỉ có thể đi trước và hg push --forcevì bạn thực sự muốn để nó treo.

Nếu bạn chưa đẩy bản sửa đổi 39-45 ở một nơi khác, thì bạn có thể giữ chúng ở chế độ riêng tư. Điều đó rất đơn giản: với hg clone --rev 38 foo foo-38bạn sẽ có một bản sao cục bộ mới chỉ chứa tối đa phiên bản 38. Bạn có thể tiếp tục làm việc foo-38và đẩy các thay đổi mới (tốt) mà bạn tạo. Bạn vẫn sẽ có bản sửa đổi cũ (xấu) trong foobản sao của mình . (Bạn có thể tự do đổi tên các bản sao theo cách bạn muốn, ví dụ, foothành foo-badfoo-38sang foo.)

Cuối cùng, bạn cũng có thể sử dụng hg revert --all --rev 38và sau đó cam kết. Điều này sẽ tạo ra một bản sửa đổi 46 trông giống hệt với bản sửa đổi 38. Sau đó, bạn sẽ tiếp tục làm việc từ bản sửa đổi 46. Điều này sẽ không tạo ra một ngã ba trong lịch sử theo cách rõ ràng như hg updateđã làm, nhưng mặt khác bạn sẽ không phàn nàn về việc có nhiều đầu. Tôi sẽ sử dụng hg revertnếu tôi cộng tác với những người khác đã thực hiện công việc của họ dựa trên phiên bản 45. Mặt khác, hg updaterõ ràng hơn.


2
Câu trả lời TUYỆT VỜI. Tôi đã sử dụng hg Revert --all --rev ## và nó đã lưu ass của tôi: D
Van Thoai Nguyen

1
Không phải tốt hơn là đóng chi nhánh của cái đầu lơ lửng sao? Điều này sẽ ngăn chặn các cảnh báo trong tương lai trên kho lưu trữ. Xem stackoverflow.com/a/3688320/900130
Zoltán

lưu ý: hg Revert --all --rev xxx sẽ sửa đổi các tệp cục bộ cần thiết để hoàn nguyên từ vị trí của bạn trong repo cục bộ của bạn. Vì vậy, bạn cần cập nhật trước khi đến nơi bạn muốn hoàn nguyên.
Vincent

Để phân nhánh một phiên bản trước đó, trước tiên tôi phải thực hiện hoàn nguyên và sau đó cập nhật. Điều đó đang được nói, một lời giải thích ít mờ đục hơn hầu hết.
CodeLurker

30

Tôi vừa gặp phải một trường hợp cần hoàn nguyên chỉ một tệp để sửa đổi trước đó, ngay sau khi tôi đã thực hiện cam kết và đẩy. Cú pháp tốc ký để chỉ định các sửa đổi này không nằm trong các câu trả lời khác, vì vậy đây là lệnh để thực hiện điều đó

hg revert path/to/file -r-2

Điều đó -2sẽ trở lại phiên bản trước lần cam kết cuối cùng, sử dụng -1sẽ chỉ hoàn nguyên các thay đổi không được cam kết hiện tại.


1
Tôi thấy điều này cực kỳ hữu ích. Tất nhiên, đối với tùy chọn -r, bạn chỉ cần cung cấp số sửa đổi
Alex

Bạn cũng có thể chọn một phiên bản cụ thể. ví dụhg revert path/to/file -r478
Matt

7

IMHO, hg strip -r 39phù hợp với trường hợp này tốt hơn.

Nó yêu cầu tiện ích mở rộng mq phải được bật và có cùng các giới hạn như "phương pháp nhân bản vô tính" được đề xuất bởi Martin Geisler: Nếu thay đổi được xuất bản bằng cách nào đó, có thể nó sẽ quay lại repo của bạn vào một lúc nào đó vì bạn chỉ thay đổi repo địa phương của bạn.


Không biết về cái này. Dễ dàng và sạch sẽ hơn là xóa và sao chép lại repo. Cảm ơn.
Tái lập lại Monica - notmaynard 31/12/14

6

Sau khi sử dụng hg update -r REV, câu trả lời không rõ ràng về cách thực hiện thay đổi đó để bạn có thể đẩy.

Nếu bạn chỉ cố gắng cam kết sau khi cập nhật, Mercurial không nghĩ có bất kỳ thay đổi nào.

Trước tiên tôi phải thực hiện thay đổi đối với bất kỳ tệp nào (giả sử trong README) để Mercurial nhận ra rằng tôi đã thực hiện một thay đổi mới, sau đó tôi có thể cam kết điều đó.

Điều này sau đó tạo ra hai cái đầu như đã đề cập.

Để thoát khỏi cái đầu khác trước khi đẩy, tôi sau đó làm theo bước No-Op Merges để khắc phục tình trạng đó.

Tôi đã có thể đẩy.


bạn có thể làm một commit --close-branchnhánh cũ. Bạn cũng có thể push -fđẩy những cái đầu mới, nhưng điều này có thể gây nhầm lẫn với cái đầu hiện tại.
ctrl-alt-delor

5

Các câu trả lời ở trên là hữu ích nhất và tôi đã học được rất nhiều. Tuy nhiên, đối với nhu cầu của tôi, câu trả lời ngắn gọn là:

hg revert --all --rev ${1}

hg commit -m "Restoring branch ${1} as default"

trong đó ${1}số lượng sửa đổi hoặc tên của chi nhánh. Hai dòng này thực sự là một phần của tập lệnh bash, nhưng chúng tự hoạt động tốt nếu bạn muốn thực hiện thủ công.

Điều này rất hữu ích nếu bạn cần thêm một bản sửa lỗi nóng cho một nhánh phát hành, nhưng cần phải xây dựng từ mặc định (cho đến khi chúng tôi có được các công cụ CI của chúng tôi và có thể xây dựng từ các nhánh và sau đó cũng loại bỏ các nhánh phát hành).


1

Tôi sẽ cài đặt Rùa Hg (GUI miễn phí cho Mercurial) và sử dụng nó. Sau đó, bạn có thể nhấp chuột phải vào bản sửa đổi mà bạn có thể muốn quay lại - với tất cả các thông báo cam kết ở trước mắt - và 'Hoàn nguyên tất cả các tệp'. Làm cho nó trực quan và dễ dàng cuộn qua lại giữa các phiên bản của một tập tin, điều này có thể thực sự hữu ích nếu bạn đang tìm cách thiết lập khi một vấn đề xuất hiện lần đầu tiên.

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.