Lực lượng cho người dùng Git? [đóng cửa]


173

Có rất nhiều tài liệu "Git for Perforce" ngoài kia, nhưng dường như rất ít điều ngược lại.

Tôi mới chỉ sử dụng Git trước đây và gần đây đã bắt đầu một công việc mà tôi phải sử dụng Perforce rất nhiều và thấy mình rất bối rối rất nhiều thời gian. Các khái niệm tôi đã sử dụng từ Git dường như không ánh xạ tới Perforce.

Có ai quan tâm đến việc kết hợp một vài mẹo sử dụng Perforce cho người đã quen sử dụng Git không?

Câu trả lời:


334

Đây là điều mà tôi đã làm việc trong vài tuần qua và tắt. Nó vẫn đang phát triển, nhưng nó có thể hữu ích. Xin lưu ý tôi là nhân viên của Perforce.

Giới thiệu về Perforce cho người dùng Git

Có thể nói, việc chuyển từ Git sang Perforce hoặc từ Perforce sang Git là không tầm thường là một cách nói nhỏ. Đối với hai công cụ bề ngoài có thể làm cùng một việc, cách tiếp cận của họ không thể khác hơn. Bài viết ngắn này sẽ cố gắng giúp những người dùng Perforce mới đến từ Git hiểu được thế giới mới mà họ đang ở.

Một đường vòng ngắn trước khi chúng tôi lặn xuống; nếu bạn thích Git, bạn có thể sử dụng Git với Perforce khá tốt. Chúng tôi cung cấp một công cụ có tên Git Fusion để tạo các kho Git được giữ đồng bộ với máy chủ Perforce. Người Git và Perforce có thể sống hài hòa khi làm việc trên cùng một mã, hầu như không bị ảnh hưởng bởi sự lựa chọn kiểm soát phiên bản của đồng nghiệp. Git Fusions 13.3 có sẵn từ trang web Perforce . Nó không cần phải được cài đặt bởi quản trị viên Perforce, nhưng nếu bạn cài đặt nó, bạn sẽ thấy rằng tính năng cắt kho lưu trữ của nó có thể khá tiện dụng như một người dùng Git.

Nếu bạn không thể thuyết phục quản trị viên của mình cài đặt Git Fusion, thì chính Git đi kèm với ràng buộc Perforce có tên là Git-P4 cho phép bạn sử dụng Git để thay đổi và gửi tệp trong không gian làm việc của Perforce. Thông tin thêm về điều đó có thể được tìm thấy tại: https://git.wiki.kernel.org/index.php/GitP4

Vẫn ở đây? Tốt, hãy nhìn vào Perforce.

Một số thuật ngữ khác nhau để sắp xếp

Trước khi chúng tôi đi vào chi tiết, chúng tôi cần đề cập ngắn gọn về một số khác biệt về thuật ngữ giữa Git và Perforce.

Đầu tiên là thanh toán . Trong Git, đây là cách bạn lấy một bản sao của mã từ một nhánh nhất định vào khu vực làm việc của bạn. Trong Perforce, chúng tôi gọi đây là đồng bộ hóa từ dòng lệnh hoặc từ GUI P4V của chúng tôi "Nhận bản sửa đổi mới nhất". Perforce sử dụng tính năng kiểm tra từ từ P4V hoặc p4 edittừ dòng lệnh để có nghĩa là bạn dự định thay đổi một tệp từ hệ thống kiểm soát phiên bản. Trong phần còn lại của tài liệu này, tôi sẽ sử dụng thanh toán theo nghĩa Perforce của từ này.

Thứ hai là Git commit so với Perforce nộp . Nơi bạn sẽ cam kết trong Git, bạn sẽ gửi trong Perforce. Do tất cả các hoạt động xảy ra đối với dịch vụ phiên bản Perforce được chia sẻ, Perforce không có tương đương git push. Tương tự như vậy, chúng ta không có một pull; lệnh đồng bộ từ phía trên đảm nhiệm việc nhận tệp cho chúng tôi. Không có khái niệm nào về việc gửi cục bộ thuần túy trong Perforce trừ khi bạn chọn sử dụng công cụ P4Sandbox của chúng tôi được mô tả ngắn gọn dưới đây.

Các khái niệm chính trong Perforce

Nếu tôi đơn giản hóa Perforce thành hai khái niệm chính, tôi sẽ tập trung vào kho và không gian làm việc. Kho chứa Perforce là kho lưu trữ các tệp nằm trong máy chủ Perforce. Một máy chủ Perforce có thể có bất kỳ số lượng kho và mỗi kho có thể chứa bất kỳ số lượng tệp nào. Thường thì bạn sẽ nghe người dùng Perforce sử dụng kho và máy chủ thay thế cho nhau, nhưng chúng khác nhau. Trang web Perforce có thể chọn có nhiều máy chủ, nhưng phổ biến nhất là tất cả các tệp nằm trong một máy chủ.

Không gian làm việc hoặc máy khách Perforce là một đối tượng trong hệ thống ánh xạ một tập hợp các tệp trong máy chủ Perforce đến một vị trí trên hệ thống tệp của người dùng. Mỗi người dùng có một không gian làm việc cho mỗi máy họ sử dụng và người dùng thường xuyên sẽ có nhiều không gian làm việc cho cùng một máy. Phần quan trọng nhất của không gian làm việc là ánh xạ hoặc khung nhìn không gian làm việc.

Khung nhìn không gian làm việc chỉ định tập hợp các tệp trong kho nên được ánh xạ tới máy cục bộ. Điều này rất quan trọng vì có nhiều khả năng bạn không muốn tất cả các tệp có sẵn trên máy chủ. Một khung nhìn không gian làm việc cho phép bạn chọn chỉ bộ mà bạn quan tâm. Điều quan trọng cần lưu ý là một không gian làm việc có thể ánh xạ nội dung từ nhiều kho, nhưng chỉ có thể ánh xạ nội dung từ một máy chủ.

Để so sánh Perforce với Git về vấn đề này, với Git, bạn chọn và chọn bộ repo Git mà bạn quan tâm. Mỗi repo thường có phạm vi chặt chẽ để chỉ chứa các tệp liên quan. Ưu điểm của việc này là không có cấu hình để thực hiện về phía bạn; bạn thực hiện một bản sao của những điều bạn quan tâm và bạn đã hoàn thành. Điều này đặc biệt tốt nếu bạn chỉ làm việc với một hoặc hai kho lưu trữ. Với Perforce, bạn cần dành một chút thời gian để chọn và chọn các đoạn mã bạn muốn.

Nhiều cửa hàng Perforce sử dụng các luồng có thể tự động tạo chế độ xem không gian làm việc hoặc họ tạo chế độ xem bằng cách sử dụng tập lệnh hoặc không gian làm việc mẫu. Tương tự nhiều người rời bỏ người dùng của họ để tạo ra không gian làm việc của họ. Một lợi thế của việc có thể ánh xạ một số mô-đun trong một không gian làm việc là bạn có thể dễ dàng sửa đổi nhiều mô-đun mã trong một lần đăng ký; bạn có thể được đảm bảo rằng bất kỳ ai có chế độ xem khách hàng tương tự đồng bộ hóa với đăng ký của bạn sẽ có tất cả mã ở trạng thái chính xác. Điều này cũng có thể dẫn đến mã phụ thuộc quá mức mặc dù; sự phân tách bắt buộc của Git có thể dẫn đến mô đun tốt hơn. Rất may, Perforce cũng có thể hỗ trợ mô đun nghiêm ngặt. Đó là tất cả một câu hỏi về cách bạn chọn sử dụng công cụ.

Tại sao không gian làm việc?

Tôi nghĩ rằng đến từ Git, thật dễ dàng để cảm thấy như toàn bộ khái niệm không gian làm việc là rắc rối hơn đáng kể. So với nhân bản một vài repo Git thì điều này chắc chắn là đúng. Không gian làm việc tỏa sáng và lý do Perforce vẫn hoạt động sau nhiều năm, đó là không gian làm việc là một cách tuyệt vời để giảm bớt hàng triệu dự án tệp cho các nhà phát triển trong khi vẫn dễ dàng xây dựng và phát hành để kết hợp tất cả các nguồn từ đó một nguồn có thẩm quyền. Không gian làm việc là một trong những lý do chính khiến Perforce có thể mở rộng quy mô như nó.

Không gian làm việc cũng tốt ở chỗ cách bố trí các tệp trong kho và bố cục trên máy của người dùng có thể thay đổi nếu cần. Nhiều công ty tổ chức kho của họ để phản ánh tổ chức của công ty để mọi người dễ dàng tìm thấy nội dung theo đơn vị kinh doanh hoặc dự án. Tuy nhiên, hệ thống xây dựng của họ không thể quan tâm ít hơn về hệ thống phân cấp này; không gian làm việc cho phép họ sắp xếp lại hệ thống phân cấp kho của mình theo bất kỳ cách nào có ý nghĩa với các công cụ của họ. Tôi cũng đã thấy điều này được sử dụng bởi các công ty đang sử dụng các hệ thống xây dựng cực kỳ không linh hoạt, yêu cầu mã phải có cấu hình rất cụ thể gây khó hiểu cho con người. Không gian làm việc cho phép các công ty này có một hệ thống phân cấp nguồn có thể điều hướng được con người trong khi các công cụ xây dựng của họ có được cấu trúc họ cần.

Không gian làm việc trong Perforce không chỉ được sử dụng để ánh xạ tập hợp các tệp mà người dùng muốn làm việc mà còn được máy chủ sử dụng để theo dõi chính xác các phiên bản của từng tệp mà người dùng đã đồng bộ hóa. Điều này cho phép hệ thống gửi tập hợp tệp chính xác cho người dùng khi đồng bộ hóa mà không phải quét các tệp để xem tệp nào cần được cập nhật. Với số lượng lớn dữ liệu, đây có thể là một chiến thắng hiệu suất khá lớn. Điều này cũng rất phổ biến trong các ngành có quy tắc kiểm toán rất nghiêm ngặt; Quản trị viên Perforce có thể dễ dàng theo dõi và ghi nhật ký nhà phát triển đã đồng bộ hóa tệp nào.

Để biết thêm thông tin về toàn bộ sức mạnh của không gian làm việc Perforce, hãy đọc Định cấu hình P4 .

Thanh toán rõ ràng so với Thanh toán ngầm

Một trong những thách thức lớn nhất đối với người dùng khi chuyển từ Git sang Perforce là khái niệm thanh toán rõ ràng. Nếu bạn đã quen với quy trình thay đổi tệp Git / SVN / CVS và sau đó báo cho hệ thống kiểm soát phiên bản tìm kiếm những gì bạn đã làm, thì đó có thể là một quá trình chuyển đổi cực kỳ đau đớn.

Tin vui là nếu bạn chọn như vậy, bạn có thể làm việc với quy trình làm việc theo kiểu Git trong Perforce. Trong Perforce, bạn có thể đặt tùy chọn "allwrite" trên không gian làm việc của mình. Điều này sẽ cho Perforce biết rằng tất cả các tệp nên được ghi vào đĩa với tập bit có thể ghi. Sau đó, bạn có thể thay đổi bất kỳ tệp nào bạn muốn mà không cần thông báo rõ ràng cho Perforce. Để Perforce điều hòa những thay đổi bạn đã thực hiện, bạn có thể chạy "trạng thái p4". Nó sẽ mở các tệp để thêm, chỉnh sửa và xóa nếu thích hợp. Khi làm việc theo cách này, bạn sẽ muốn sử dụng "cập nhật p4" thay vì "đồng bộ p4" để nhận bản sửa đổi mới từ máy chủ; "Cập nhật p4" kiểm tra các thay đổi trước khi đồng bộ hóa, vì vậy sẽ không ghi đè các thay đổi cục bộ của bạn nếu bạn chưa chạy "trạng thái p4".

Tại sao thanh toán rõ ràng?

Một câu hỏi tôi thường nhận được là "tại sao bạn muốn sử dụng thanh toán rõ ràng?" Ban đầu nó có thể là một quyết định thiết kế điên rồ, nhưng thanh toán rõ ràng có một số lợi ích mạnh mẽ.

Một lý do để sử dụng kiểm tra rõ ràng là nó loại bỏ nhu cầu quét các tệp để thay đổi nội dung. Mặc dù với các dự án nhỏ hơn tính toán băm cho mỗi tệp để tìm sự khác biệt khá rẻ, nhiều người dùng của chúng tôi có hàng triệu tệp trong không gian làm việc và / hoặc có các tệp có kích thước 100 megabyte, nếu không lớn hơn. Tính toán tất cả các giá trị băm trong những trường hợp đó là vô cùng tốn thời gian. Kiểm tra rõ ràng cho phép Perforce biết chính xác những tập tin mà nó cần để làm việc. Hành vi này là một trong những lý do Perforce rất phổ biến trong các ngành công nghiệp tệp lớn như ngành công nghiệp trò chơi, phim ảnh và phần cứng.

Một lợi ích khác là thanh toán rõ ràng cung cấp một hình thức giao tiếp không đồng bộ cho phép các nhà phát triển biết chung những gì đồng nghiệp của họ đang làm việc hoặc ít nhất là ở đâu. Nó có thể cho bạn biết rằng bạn có thể muốn tránh làm việc trong một khu vực nhất định để tránh xung đột không cần thiết hoặc có thể cảnh báo bạn về thực tế rằng một nhà phát triển mới trong nhóm đã đi sâu vào mã mà có lẽ họ không cần để được chỉnh sửa. Kinh nghiệm cá nhân của tôi là tôi có xu hướng làm việc trong Git hoặc sử dụng Perforce với allwrite cho các dự án mà tôi là người đóng góp duy nhất hoặc là người đóng góp không thường xuyên và kiểm tra rõ ràng khi tôi làm việc chặt chẽ với một nhóm. Rất may sự lựa chọn là của bạn.

Thanh toán rõ ràng cũng chơi độc đáo với khái niệm Perforce của những người thay đổi đang chờ xử lý. Thay đổi đang chờ xử lý là các nhóm mà bạn có thể đặt các tệp đang mở của mình để sắp xếp công việc. Trong Git, bạn có khả năng sử dụng các nhánh khác nhau làm thùng để tổ chức công việc. Chi nhánh rất tuyệt, nhưng đôi khi thật tuyệt khi có thể sắp xếp công việc của bạn thành nhiều thay đổi được đặt tên trước khi thực sự gửi đến máy chủ. Với mô hình Perforce có khả năng ánh xạ nhiều chi nhánh hoặc nhiều dự án vào một không gian làm việc, những người thay đổi đang chờ xử lý giúp dễ dàng giữ các thay đổi riêng biệt được tổ chức.

Nếu bạn sử dụng IDE để phát triển, chẳng hạn như Visual Studio hoặc Eclipse, tôi khuyên bạn nên cài đặt một plugin Perforce cho IDE của mình. Hầu hết các plugin IDE sẽ tự động kiểm tra các tệp khi bạn bắt đầu chỉnh sửa chúng, giúp bạn không phải tự mình kiểm tra.

Thay thế lực lượng cho các tính năng Git

  • git stash ==> p4 shelve
  • git phân nhánh cục bộ ==> hoặc kệ Perforce hoặc nhánh nhiệm vụ
  • git blame==> p4 annotatehoặc Perforce Timelapse View từ GUI

Làm việc bị ngắt kết nối

Có hai tùy chọn để làm việc bị ngắt kết nối khỏi dịch vụ phiên bản Perforce (đó là thuật ngữ ưa thích của chúng tôi cho máy chủ Perforce).

1) Sử dụng P4Sandbox để có phiên bản cục bộ đầy đủ và phân nhánh cục bộ

2) Chỉnh sửa tệp theo ý muốn và sử dụng 'trạng thái p4' để cho Perforce biết bạn đã làm gì

Với cả hai tùy chọn trên, bạn có thể chọn sử dụng cài đặt "allwrite" trong không gian làm việc của mình để không phải mở khóa các tệp. Khi làm việc ở chế độ này, bạn sẽ muốn sử dụng lệnh "cập nhật p4" để đồng bộ hóa các tệp mới thay vì "đồng bộ hóa p4". "Cập nhật p4" sẽ kiểm tra các tệp để thay đổi trước khi đồng bộ hóa chúng.

Bắt đầu nhanh

Tất cả các ví dụ sau sẽ thông qua dòng lệnh.

1) Định cấu hình kết nối của bạn với Perforce

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

Bạn có thể dán các cài đặt này trong tệp cấu hình shell của mình, sử dụng p4 setđể lưu chúng trên Windows và OS X hoặc sử dụng tệp cấu hình Perforce.

1) Tạo không gian làm việc

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) Lấy các tập tin từ máy chủ

cd /Users/matt/work
p4 sync

3) Kiểm tra tệp bạn muốn làm việc và sửa đổi nó

p4 edit main/foo; 
echo cake >> main/foo

4) Gửi nó đến máy chủ

p4 submit -d "A trivial edit"

5) Chạy p4 help simpleđể xem các lệnh cơ bản mà bạn sẽ cần để làm việc với Perforce.


5
Một tổng quan tuyệt vời. Tôi sẽ lưu cái này (hoặc bài đăng kết quả trên trang web) để gửi cho một số nhân viên mới của chúng tôi.
Caleb Huitt - cjhuitt

@Matt nói "đến từ Git, thật dễ dàng để cảm thấy như toàn bộ khái niệm không gian làm việc rắc rối hơn nhiều so với giá trị của nó." Có thể - nhưng tôi đã thực hiện ánh xạ như vậy trong RCS và CVS trong nhiều năm. Không sử dụng các mô-đun CVS, nhưng bằng cách tạo cây liên kết tượng trưng chỉ vào một hoặc nhiều repos CVS. Cây thưa thớt, không chứa tất cả các thư mục. Vì nhiều lý do bạn mô tả Perforce làm như vậy. Nó có thể là một nỗi đau để duy trì điều này trong CVS. (Và git, và hg, và bzr ... không chắc chắn về bzr.)
Krazy Glew

Cảm ơn Matt, một đọc rất hữu ích. Tôi vẫn nghĩ rằng hệ thống tạo phiên bản sẽ cho tôi biết những gì tôi đã thay đổi cục bộ so với repo từ xa hoặc giữa các chi nhánh chứ không phải theo cách khác :)
jupp0r

1
Thật! Rất may bạn có thể làm điều đó với Perforce; Tôi đã không chạy 'chỉnh sửa p4' trong nhiều năm. perforce.com/blog/131112/say-goodbye-p4-edit
Matt

8
Cảm ơn, nhưng một gợi ý. Từ "mạnh mẽ" là khá chồn và khiến tôi có khuynh hướng coi nhẹ tuyên bố là tuyên truyền. Tôi thích nếu bạn giải thích tính năng này và sau đó để tôi quyết định xem nó có mạnh mẽ hay không.
damian

24

Sự khác biệt lớn nhất giữa git và p4, không có câu trả lời nào hiện có, là chúng sử dụng các đơn vị trừu tượng khác nhau.

  • Trong git, sự trừu tượng là bản vá (hay còn gọi là diff, aka thay đổi). Một cam kết trong git về cơ bản là đầu ra của việc chạy diffgiữa trạng thái trước đó và hiện tại của các tệp được cam kết.
  • Trong lực lượng, sự trừu tượng là tập tin . Một cam kết trong p4 là nội dung đầy đủ của các tệp trong cam kết tại thời điểm đó. Điều này được tổ chức thành một thay đổi, nhưng bản sửa đổi được lưu trữ trên cơ sở mỗi tệp và người thay đổi chỉ đơn giản là thu thập các bản sửa đổi khác nhau của các tệp với nhau.

Mọi thứ khác chảy từ sự khác biệt này . Phân nhánh và hợp nhất trong git là không đau bởi vì, từ góc độ trừu tượng của git, mọi tệp có thể được xây dựng lại hoàn toàn bằng cách áp dụng một tập hợp các bản vá theo thứ tự, và do đó để hợp nhất hai nhánh, bạn chỉ cần áp dụng tất cả các bản vá trên nhánh nguồn không có trong nhánh đích đến nhánh đích theo đúng thứ tự (giả sử không có bản vá nào trên cả hai nhánh trùng nhau).

Chi nhánh lực lượng là khác nhau. Một hoạt động nhánh trong perforce sẽ sao chép các tệp từ thư mục con này sang thư mục con khác và sau đó đánh dấu mối liên kết giữa các tệp với siêu dữ liệu trên máy chủ. Để hợp nhất một tệp từ nhánh này sang nhánh khác ( integrationtheo thuật ngữ perforce), perforce sẽ xem xét nội dung đầy đủ của tệp ở 'đầu' của nhánh nguồn và nội dung đầy đủ của tệp ở đầu nhánh đích và nếu cần thiết hợp nhất bằng cách sử dụng một tổ tiên chung. Không thể áp dụng các bản vá từng cái một như git can, điều đó có nghĩa là sự hợp nhất thủ công xảy ra thường xuyên hơn (và có xu hướng đau đớn hơn).


10
Tôi không nghĩ rằng mô tả này là hoàn toàn chính xác - git lưu trữ các ảnh chụp nhanh hoàn chỉnh của tất cả các tệp và tạo một ảnh chụp nhanh mới khi một tệp bị thay đổi (điều này gây tốn kém trong trường hợp thay đổi thường xuyên thành các tệp nhị phân lớn), do đó, một cam kết chỉ chứa liên kết (thông qua băm) đến trạng thái hiện tại của tất cả các tệp. Đó là lý do tại sao chuyển đổi các nhánh trong git thường rất nhanh - nó chỉ phải sao chép các phiên bản được tham chiếu của tất cả các tệp có băm đã thay đổi vào không gian làm việc. Diffs chỉ được tạo khi đang cần thiết để so sánh và hợp nhất / rebasing.
ChrAfonso

3
Bất kể việc triển khai chính xác dưới mui xe, lệnh hợp nhất trong git (đặc biệt là hợp nhất tầm thường hoặc chuyển tiếp nhanh) dường như hoạt động bằng cách sử dụng các bản vá từ quan điểm của người dùng cuối , đó là điểm tôi đang cố gắng thực hiện.
damian

Perforce có thể thực hiện sáp nhập thay đổi (thay đổi). Đây là một câu hỏi Stack Overflow nói về nó. stackoverflow.com/questions/6158916/perforce-merge-changelist/iêng
Br.Bill

5
@ Br.Bill Một lần nữa, điểm tôi đang đưa ra không phải là liệu P4 có khả năng thực hiện hay không (vì dĩ nhiên là vậy!). Vấn đề là về sự trừu tượng , tức là mô hình mà người dùng cần phải nội hóa để hiểu cách thức hoạt động của nó.
damian

1
Cảm ơn vì điều này. Nó ngay lập tức giải thích làm thế nào chúng ta có thể có được Phiên bản mới nhất của một tệp cụ thể, làm thế nào chúng ta có thể nhận được một thay đổi cụ thể. Đây là phần khó hiểu nhất đối với tôi khi tôi đến từ git.
Abdulsattar Mohammed

20

Có lẽ không có nhiều tài liệu như vậy bởi vì Perforce là một hệ thống kiểm soát sửa đổi truyền thống khá gần gũi (gần với CVS, Subversion, v.v.) và thường được coi là ít phức tạp hơn các hệ thống kiểm soát sửa đổi phân tán hiện đại.

Cố gắng ánh xạ các lệnh từ cái này sang cái khác không phải là cách tiếp cận đúng; các khái niệm từ các hệ thống kiểm soát sửa đổi tập trung và phân tán không giống nhau. Thay vào đó, tôi sẽ mô tả một quy trình làm việc điển hình trong Perforce:

  1. Chạy p4 edittrên mỗi tệp bạn muốn chỉnh sửa. Bạn cần cho Perforce biết tập tin nào bạn đang chỉnh sửa. Nếu bạn đang thêm tệp mới, hãy sử dụng p4 add. Nếu bạn đang xóa các tập tin, sử dụng p4 delete.
  2. Làm cho mã của bạn thay đổi.
  3. Chạy p4 changeđể tạo một bộ thay đổi. Tại đây, bạn có thể tạo mô tả về thay đổi của mình và tùy ý thêm hoặc xóa tệp khỏi tập thay đổi của bạn. Bạn có thể chạy p4 change CHANGE_NUMBERđể chỉnh sửa mô tả sau nếu cần thiết.
  4. Bạn có thể thực hiện thay đổi mã bổ sung nếu bạn cần. Nếu bạn cần thêm / chỉnh sửa / xóa các tập tin khác, bạn có thể sử dụng p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
  5. Chạy p4 syncđể lấy các thay đổi mới nhất từ ​​máy chủ.
  6. Chạy p4 resolveđể giải quyết bất kỳ xung đột từ đồng bộ hóa.
  7. Khi bạn đã sẵn sàng để gửi thay đổi của mình, hãy chạy p4 submit -c CHANGE_NUMBER .

Bạn có thể sử dụng p4 revertđể hoàn nguyên các thay đổi của bạn đối với các tệp.

Lưu ý rằng bạn có thể làm việc trên nhiều thay đổi đồng thời miễn là không có tệp nào của chúng trùng nhau. (Một tệp trong ứng dụng khách Perforce của bạn có thể được mở chỉ trong một lần thay đổi tại một thời điểm.) Điều này đôi khi có thể thuận tiện nếu bạn có các thay đổi nhỏ, độc lập.

Nếu bạn thấy mình cần chỉnh sửa các tệp mà bạn đã mở trong một bộ thay đổi khác, bạn có thể tạo một ứng dụng khách Perforce riêng biệt hoặc bạn có thể bỏ các thay đổi hiện tại của mình sau này p4 shelve. (Không giống như git stash, giá đỡ không hoàn nguyên các tệp trong cây cục bộ của bạn, vì vậy bạn phải hoàn nguyên chúng một cách riêng biệt.)


3
Tôi xin lỗi tôi không hiểu điều này: các hệ thống hiện đại có phải phức tạp hơn các hệ thống truyền thống không? Đơn giản luôn là nguyên tắc trong công nghệ phần mềm. Theo một nghĩa nào đó, tôi nghĩ P4 hiện đại hơn nhiều về cả khái niệm và khả năng sử dụng (và khả năng bảo trì) so với Git. Tôi không ghét Git, nhưng hãy xem, sau 30 năm tiến bộ của công nghệ phần mềm, mọi người buộc phải dùng đến bàn điều khiển dựa trên văn bản để đưa ra các lệnh VCS - một sự suy thoái trong quá trình tiến hóa của loài người!
Dejavu

5
@Dejavu Đó không phải là quá nhiều về truyền thống so với hiện đại; đó là nhiều hơn về tập trung so với phân tán (và những cái phân tán xảy ra hiện đại hơn). Những người được phân phối không nhất thiết phải phức tạp hơn, nhưng tôi đã nói cụ thể rằng "Perforce ... được coi là ít phức tạp hơn ...", đó là một tuyên bố về ý kiến, không thực tế và không có nghĩa là một tấm chăn tuyên bố về tất cả các hệ thống. Cá nhân tôi coi git là phức tạp hơn bởi vì nó thêm nhiều hơn khái niệm (ví dụ như đẩy, kéo, nổi loạn) và một số điều không đơn giản (ví dụ: băm thay vì số thay đổi toàn cầu).
jamesdlin

2
Cảm ơn đã làm rõ, James! Gần đây tôi đã bị xúc phạm một chút khi thấy tất cả các đồng nghiệp phải được đào tạo thành một hacker git, người nên biết một loạt các kỹ năng hack git để giải quyết một số vấn đề cảm thấy rất trực quan khi sử dụng Perforce.
Dejavu

4
@Dejavu, nhận xét của bạn không có ý nghĩa, xem xét các IDE hiện đại hỗ trợ đồ họa gitvà họ đã làm như vậy trong nhiều năm.
Acumenus
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.