Quy trình làm việc: Sử dụng các định dạng tài liệu nhị phân trong Git không có khóa (chuyển từ lật đổ)


16

Chúng tôi là một nhà tư vấn phần mềm với vô số dự án cho các khách hàng khác nhau. Theo truyền thống, chúng tôi sử dụng Subversion, nhưng hiện đang xem xét chuyển sang Git.

Một phần đáng kể các tài liệu chúng tôi sản xuất được chia sẻ với khách hàng của chúng tôi (yêu cầu, thiết kế toàn cầu, thông số kỹ thuật thử nghiệm, v.v.) và chúng tôi sử dụng MS Office để sản xuất chúng. Trong Subversion, chúng tôi có thể sử dụng tính năng "Khóa" của nó để đảm bảo rằng không ai đang chỉnh sửa cùng một tài liệu cùng một lúc. Trong Git, bạn không thể làm điều đó vì bản chất phân tán của nó, git không có khóa.

Khóa thực sự ít hơn một cơ chế giao tiếp, nhưng chúng là một cơ chế rất hiệu quả.

Hiện tại, mã và tài liệu hướng tới khách hàng của chúng tôi thường nằm trong các thư mục con khác nhau của kho lưu trữ svn khác nhau. Khi chuyển sang git, bạn muốn giới thiệu chúng tôi làm gì? Tôi thấy một loạt các tùy chọn:

  1. Chúng tôi di chuyển các kho svn sang git 1 trên 1. Thay vì sử dụng các khóa trên các tệp Office, chúng tôi thực hiện những gì người git đề xuất và bằng cách nào đó cố gắng thay đổi quy trình làm việc của chúng tôi để khắc phục nó. Điều này có thể đang làm việc trong một chi nhánh trên bất kỳ chỉnh sửa tài liệu nào và hợp nhất nó qua đánh giá. Cách tiếp cận này vượt qua ví dụ: các bảng Excel có chứa thông tin quản lý dự án; chúng dễ dàng được chỉnh sửa bởi các thành viên trong nhóm (và chúng tôi khuyến khích việc này được thực hiện), nhưng không phải tuân theo bất kỳ quy trình đánh giá chính thức nào

  2. Chúng tôi sử dụng git cho mã và svn cho tài liệu và quản lý dự án. Điều này có nhược điểm là một số tài liệu thiết kế cụ thể hơn sẽ không "ở gần" mã mà nó quy định, làm tăng cơ hội mọi người quên cập nhật chúng. Ngoài ra, mọi người phải sử dụng và hiểu hai bộ công cụ. Điều đó nói rằng, có lẽ đây là một cơ hội tuyệt vời để chuyển sang các công cụ tài liệu dựa trên văn bản (latex, markdown, HTML, bất cứ điều gì) cho các tài liệu thiết kế không dành cho khách hàng.

  3. Giống như 1, nhưng chúng tôi hack một git locklệnh thực hiện khóa svn cho chúng tôi (chuyển cờ chỉ đọc một cách thích hợp và đồng bộ hóa với máy chủ thông qua một số phương tiện).

Tôi không mua đối số rằng các khóa không hoạt động trong DVCS vì hệ thống thậm chí sẽ hoạt động khi bạn hoàn toàn ngoại tuyến. Khóa Svn cũng có thể được ghi đè; chúng là một cơ chế giao tiếp . Nếu không có một số loại kết nối mạng, bạn sẽ không khiến máy tính của mình giao tiếp nhiều.

Chúng ta không thể là cửa hàng duy nhất rất hài lòng với cách svn lockphù hợp với quy trình làm việc của mình, phải không?

Bất kỳ ý tưởng hoặc lời khuyên?

Tôi đã tìm thấy /programming/119444/locking-binary-files-USE-git-version-control-system nhưng cuộc thảo luận khá kỹ thuật; Tôi đang tìm cách để giải quyết hoặc tránh vấn đề thực tế của hai thành viên trong nhóm chỉnh sửa cùng một tệp nhị phân.


Bạn có thể làm rõ cách bạn "chia sẻ" tài liệu của mình với khách hàng không? Tôi hy vọng họ có quyền truy cập chỉ đọc và các thay đổi được quản lý bởi nhóm của bạn do kết quả của các yêu cầu thay đổi từ họ. Đúng không?
vaughandroid

2
Bạn có thể muốn sử dụng công cụ quản lý tài sản (có tính năng khóa) thay vì VCS để xử lý tài liệu nhị phân. Tôi đã làm việc tại một nơi có hình ảnh 2 GB được kiểm tra trong SVN, điều này khiến cho mọi thứ trở nên siêu chậm. Sau khi chúng tôi chuyển tất cả những thứ đó vào một thư mục dưới sự sao lưu, mọi thứ trở nên nhanh chóng và dễ xử lý hơn.
Spoike

1
@Baqueta Bằng email hoặc trên giấy. Vấn đề là "Chỉ sử dụng văn bản cho tài liệu!" không phải là một cách tiếp cận hợp lý ở đây, vì nỗ lực liên quan đến việc làm cho nó trông có vẻ nửa vời hơn nhiều so với các công cụ như MS Word.
skrebbel

@Spoike, nghe có vẻ như một câu trả lời hợp lệ đối với tôi :-) Dù sao, có khuyến nghị nào không?
skrebbel

@skrebbel Một từ, LaTeX.
kyrias

Câu trả lời:


5

Tôi khuyên bạn nên ở lại với SVN cho các tài liệu MS Office vì hai lý do:

  1. Nó đã ở đó và (theo ý kiến ​​của tôi) tốt hơn để giữ tài liệu Office (xem tại đây ). Có nhiều công cụ của bên thứ ba để làm điều này.
  2. Khóa, mặc dù có thể đạt được trong Git, không phải là "cách làm việc của Git". Nếu bạn cần những tính năng này, hãy gắn bó với công cụ cung cấp cho bạn giải pháp tốt nhất.

Có một câu nói mà tôi thích đã nói một câu như thế này: "Khi bạn đang cầm một cái búa, mọi thứ trông giống như một cái đinh". Chỉ vì bạn đang chuyển sang Git để giữ mã của bạn, điều đó không có nghĩa là bạn nên sử dụng nó để giữ tài liệu của mình.


Điều gì xảy ra nếu mã và tài liệu nằm trong cùng một kho lưu trữ SVN?
Jimmy T.

2

Kiểm soát phiên bản mã không phải là công cụ tốt nhất để làm việc trên các tệp Office, vì chúng là nhị phân và các công cụ này hoạt động trên sửa đổi cấp độ tệp.

Sử dụng một công cụ cộng tác, như MediaWiki (miễn phí) hoặc Atlassian Confluence (trả phí), từ đó bạn có thể dễ dàng trích xuất tài liệu Word. Hoặc sử dụng LaTex để tạo các tệp Office.

Hãy để tôi mở rộng ...

Nếu bạn cần cộng tác, bạn phải áp dụng một mô hình làm nổi bật các sửa đổi (ví dụ: đã thay đổi một từ, viết lại hoặc chỉ thay đổi một phông chữ) thành một đơn vị, ví dụ như một tệp.

SVN và Git, ngay cả khi nghĩ về mã, là các công cụ cấp thấp so sánh các tệp của chúng theo nội dung văn bản. Nhưng vấn đề là chúng chỉ có thể hoạt động trên các tệp văn bản, vì chúng không quan tâm đến bản chất / nội dung của tệp để trích xuất mô hình sửa đổi cấp cao.

Một ví dụ rõ ràng là một tập tin hình ảnh . Mặc dù TortoiseMerge là một công cụ giúp người dùng SVN bằng cách so sánh các hình ảnh cho các sửa đổi thực sự của họ, nhưng VCSes bình thường chạy bằng các bản vá nội dung trên các tệp. Hãy để tôi giải thích. Một công cụ như TortoiseMerge có thể cho bạn biết rằng một phiên bản mới của tệp hình ảnh chỉ bị thay đổi bởi một vài pixel hoặc độ chói nếu nó thực hiện phân tích HSV phức tạp hơn về hai tệp. Bạn có thể thêm hình mờ hoặc thay đổi mức độ màu, một công cụ so sánh các tệp hình ảnh sẽ làm nổi bật sự khác biệt của bạn nếu nó thực hiện thuật toán so sánh tốt. Nhưng để kiểm tra tệp mới trong máy khách của bạn thì phảisản xuất một đồng bằng. Một delta là một tập hợp các dòng được loại bỏ và các dòng được thêm vào tệp. Tập tin nhị phân không có ngắt dòng nếu họ không xảy ra để có \r\n, hoặc tương tự, trong tải trọng của họ, và trong một tam giác nếu bạn thay đổi một nhân vật duy nhất bạn đang thay thế toàn bộ một dòng.

Vì vậy, đây là vấn đề. Các tệp nhị phân không tốt cho việc kiểm soát phiên bản vì bạn gần như có thể thay thế toàn bộ tệp cho mỗi lần sửa đổi. Xem xét khi bạn viết tệp Office bằng MS Office và cộng tác viên của bạn chỉnh sửa với OpenOffice. Nếu chúng triển khai ngay cả một phiên bản hơi khác của thuật toán nén các tệp OpenXML, bạn sẽ kết thúc ở các tệp hoàn toàn khác nhau ngay cả khi bạn thay đổi một dấu phẩy trong tài liệu.

Phần mềm cộng tác hiển thị các tài liệu bên trong theo định dạng dựa trên văn bản, bởi vì văn bản là thứ thực sự có ý nghĩa đối với công ty của bạn và có thể tính toán sự khác biệt hoặc xử lý xung đột. LaTex, hoặc Markdown nếu bạn thích, là một cách để lưu trữ tài liệu dưới dạng tệp văn bản với đánh dấu nâng cao, vì vậy không giống như tệp TXT cổ điển không có kiểm soát phông chữ / định dạng.

Nhưng rõ ràng là khách hàng của bạn sẽ không muốn mở các tệp Markdown, phải không? Ok, bạn có thể đơn giản, và tôi thực sự muốn nói đơn giản là sử dụng bất kỳ phần mềm nào tôi hiện đang quá lười biếng để chuyển đổi tài liệu nguồn thành PDF, Word hoặc bất cứ thứ gì.

Tóm tắt

Nếu bạn bắt đầu kiểm tra tệp văn bản vào kiểm soát nguồn của mình, bạn có quyền kiểm soát lớn hơn đối với lịch sử tệp và có thể dễ dàng quản lý xung đột, đặc biệt là không sử dụng khóa VCS.

Trước khi chia sẻ tài liệu chính thức, bạn cần một thói quen để xuất tài liệu văn bản nguồn sang tệp Office

Tách hai bước làm cho mọi người hạnh phúc với chi phí của một đường cong học tập.


Các tệp văn bản Linux và Mac không có dòng theo định nghĩa của bạn :-) deltas có thể được tạo cho các tệp nhị phân dễ dàng như vậy. Bạn quyết định một thuật toán khác nhau. Ví dụ, SVN tạo ra các đồng bằng nhỏ, đẹp chỉ tốt cho các tệp nhị phân (ít nhất là với các tệp lớn, đó là những gì tôi có nhiều kinh nghiệm nhất)
gbjbaanb

Tất nhiên không phải Windows có các đầu cuối dòng khác nhau. Dù sao, ngay cả khi bạn quản lý để tạo ra một delta nhỏ hơn (tôi sẽ cần phải viết lại một chút câu trả lời) nó có làm cho sự khác biệt có thể đọc được của con người không? Dĩ nhiên là không. Bạn sẽ không biết lớp nào đã được sửa đổi giữa các DLL. Và một lần nữa vấn đề là hai trình biên dịch có thể (tôi đã nói có thể ) tạo ra các tệp hoàn toàn khác nhau bằng cách sắp xếp lại các lớp theo cách chúng muốn. Đó là điểm của câu trả lời
usr-local-ΕΨΗΕΛΩΝ 30/03/2016

-1

Bạn có thể sử dụng git cho các tài liệu đó mà không cần thêm khóa. Chọn một luồng công việc git mà các khối đẩy đến nhánh chính nếu không phải trên master. (Có một số quy trình công việc để lựa chọn.) Điều này sẽ ngăn mọi người ghi đè lên các sửa đổi của nhau đối với các tệp tài liệu nhị phân. Giả sử hai người sửa đổi cùng một tài liệu nhị phân. Cái đầu tiên đẩy nó thành chủ sẽ nhận được các thay đổi của chúng. Cái thứ hai sẽ bị chặn vì bản sao của chúng nằm sau nhánh chính. Họ phải đồng bộ trước. Vì vậy, người thứ hai không đồng bộ. Nó sẽ hiển thị một xung đột hợp nhất cho tài liệu nhị phân. Người đó lưu phiên bản của họ ở đâu đó và giải quyết xung đột bằng cách lấy phiên bản từ chủ (được đẩy bởi người đầu tiên). Tại thời điểm này, các tệp của người thứ hai được cập nhật với nhánh chính. Họ hợp nhất các thay đổi của họ với tài liệu nhị phân mới nhất (bằng tay), sau đó sẽ chứa cả những thay đổi của người thứ nhất và người thứ hai. Sau đó, phiên bản mới được đẩy lên thành chủ và trở thành nhánh chủ mới. Việc sáp nhập là một nỗi đau, nhưng nó chỉ xảy ra khi có xung đột. Ngoài ra, những thay đổi không bị mất hoặc bị ghi đè. Các xung đột được phát hiện và người dùng có thể giải quyết chúng một cách sạch sẽ.


4
Chính xác thì nỗi đau hợp nhất này là những gì khóa được cho là để ngăn chặn.
oefe

Thực tế, có các công cụ hợp nhất có thể hợp nhất các tài liệu Word. Tuy nhiên, tôi không có bất kỳ kinh nghiệm nào với họ, vậy tôi không biết họ giỏi đến mức nào?
Pete

Cảm ơn câu trả lời của bạn. Tôi thấy rằng đây là cách làm việc của Git. @Pete, Word tự nó có thể làm một Diff khá tốt, không chắc chắn về việc hợp nhất. Tuy nhiên, đó là một nỗi đau dễ dàng hơn để tránh với ổ khóa. Chúng tôi hiếm khi chỉnh sửa tài liệu Office đồng thời; hầu hết các công việc của chúng tôi (bao gồm các tài liệu chi tiết) đều nằm trong mã. Câu hỏi này là khoảng 2% số trường hợp 2 người làm chỉnh sửa cùng một tài liệu cùng một lúc. Cho rằng đó là 2%, không phải 30%, một giải pháp hợp nhất cảm thấy không tối ưu.
skrebbel

-2

Đặt 2 giải pháp đầu tiên của bạn lại với nhau và bạn không cần một giải pháp thứ ba.

Nếu bạn lưu bảng tính của mình trên đĩa dưới dạng CSV, Excel vẫn sẽ chỉnh sửa chúng và sau đó git sẽ vui lòng hợp nhất chúng cho bạn.

Tương tự, bạn có thể mở, chỉnh sửa và lưu tệp của mình trong Word nếu chúng là HTML hoặc (thần giúp chúng tôi) RTF. Word tất nhiên sẽ thêm nhiều sự phình to hơn văn bản hữu ích, nhưng nó vẫn chỉ là văn bản mà git rất vui khi hợp nhất cho bạn.

Được cho phép, các giải pháp này cho rằng bạn không sử dụng hoặc có thể tránh xa các tính năng dành riêng cho MS, điều thực sự chỉ có thể là vấn đề ở phía Excel.

Tất nhiên trừ khi bạn cũng yêu cầu Word phải được cài đặt trên một hệ thống để có thể đọc tài liệu của bạn, bản thân nó là một viễn cảnh đáng sợ đối với tôi ...


1
Có thật không? Bạn đang đề nghị quay trở lại thời kỳ đồ đá để có thể tránh xung đột hợp nhất?
Petter Nordlander

Tôi không chắc tôi hiểu chính xác những gì bạn cảm thấy là thời kỳ đồ đá về việc lưu trữ ở định dạng văn bản so với định dạng nhị phân ...
Steven
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.