Khóa các tệp nhị phân bằng hệ thống kiểm soát phiên bản git

Trong một năm rưỡi, tôi đã để mắt đến cộng đồng git với hy vọng có thể chuyển đổi khỏi SVN. Một vấn đề cụ thể giữ tôi lại là không thể khóa các tệp nhị phân. Trong suốt năm qua, tôi vẫn chưa thấy sự phát triển về vấn đề này. Tôi hiểu rằng việc khóa tệp đi ngược lại các nguyên tắc cơ bản của kiểm soát nguồn phân tán, nhưng tôi không thấy cách một công ty phát triển web có thể tận dụng git để theo dõi mã nguồn và các thay đổi tệp hình ảnh khi có khả năng xảy ra xung đột tệp nhị phân.

Để đạt được hiệu quả của việc khóa, một kho lưu trữ "trung tâm" phải được xác định. Bất kể tính chất phân tán của git, hầu hết các công ty sẽ có một kho lưu trữ "trung tâm" cho một dự án phần mềm. Chúng tôi sẽ có thể đánh dấu một tệp là yêu cầu khóa từ kho lưu trữ git quản lý tại một địa chỉ được chỉ định. Có lẽ điều này được thực hiện khó khăn vì git theo dõi nội dung tệp chứ không phải tệp?

Có bạn nào có kinh nghiệm xử lý các tệp git và nhị phân cần bị khóa trước khi sửa đổi không?

LƯU Ý: Có vẻ như dự án điều khiển phiên bản phân phối nguồn mở mới của Source Gear, Veracity, đã khóa là một trong những mục tiêu của nó.

Git LFS 2.0 đã hỗ trợ thêm tính năng khóa tệp.

Với Git LFS 2.0.0, giờ đây bạn có thể khóa các tệp mà bạn đang làm việc tích cực, ngăn người khác đẩy đến máy chủ Git LFS cho đến khi bạn mở khóa lại các tệp.

Điều này sẽ ngăn chặn xung đột hợp nhất cũng như mất công việc trên các tệp không thể hợp nhất ở cấp hệ thống tệp. Mặc dù nó có vẻ mâu thuẫn với bản chất phân tán và song song của Git, nhưng khóa tệp là một phần quan trọng của nhiều quy trình phát triển phần mềm — đặc biệt đối với các nhóm lớn hơn làm việc với tài sản nhị phân.

Subversion có những ổ khóa, và chúng không chỉ là lời khuyên. Chúng có thể được thực thi bằng cách sử dụng svn:needs-lockthuộc tính (nhưng cũng có thể bị cố tình phá vỡ nếu cần). Đó là giải pháp phù hợp để quản lý các tệp không thể hợp nhất. Công ty tôi làm việc cho các cửa hàng về mọi thứ trong Subversion và sử dụng svn:needs-lockcho tất cả các tệp không thể hợp nhất.

Tôi không đồng ý với "ổ khóa chỉ là một phương thức giao tiếp". Chúng là một phương pháp hiệu quả hơn nhiều so với thông báo đẩy như điện thoại hoặc e-mail. Các ổ khóa lật đổ được tự lập tài liệu (ai có ổ khóa). Mặt khác, nếu bạn phải giao tiếp bằng các kênh thông báo đẩy truyền thống khác, chẳng hạn như e-mail, bạn sẽ gửi thông báo cho ai? Bạn không biết trước ai có thể muốn chỉnh sửa tệp, đặc biệt là trên các dự án mã nguồn mở, trừ khi bạn có danh sách đầy đủ về toàn bộ nhóm phát triển của mình. Vì vậy, những phương pháp giao tiếp truyền thống gần như không hiệu quả.

Máy chủ khóa trung tâm, mặc dù chống lại các nguyên tắc của DVCS, là phương pháp khả thi duy nhất cho các tệp không thể hợp nhất. Miễn là DVCS không có tính năng khóa trung tâm, tôi nghĩ rằng nó sẽ giữ cho công ty tôi làm việc sử dụng Subversion.

Giải pháp tốt hơn sẽ là tạo một công cụ hợp nhất cho tất cả các định dạng tệp nhị phân của bạn, nhưng đó là một mục tiêu dài hạn và liên tục sẽ không bao giờ "hoàn thành".

Đây là một bài đọc thú vị về chủ đề này.

Tôi đồng ý rằng khóa các tệp nhị phân là một tính năng cần thiết cho một số môi trường. Tuy nhiên, tôi chỉ có một suy nghĩ về cách thực hiện điều này:

• Có cách đánh dấu tệp là "cần khóa" (như thuộc tính "svn: cần khóa").
• Khi thanh toán, git sẽ đánh dấu một tệp như vậy là chỉ đọc.
• Một lệnh mới git-locksẽ liên hệ với máy chủ khóa trung tâm đang chạy ở đâu đó để yêu cầu quyền khóa.
• Nếu máy chủ khóa cấp quyền, hãy đánh dấu tệp là đọc-ghi.
• git-add sẽ thông báo cho máy chủ khóa về hàm băm nội dung của tệp bị khóa.
• Máy chủ khóa sẽ theo dõi nội dung băm đó xuất hiện trong một cam kết trên kho lưu trữ chính.
• Khi mã băm xuất hiện, hãy mở khóa.

Đây là một ý tưởng còn rất nửa vời và có những lỗ hổng tiềm ẩn ở khắp mọi nơi. Nó cũng đi ngược lại tinh thần của git, nhưng nó chắc chắn có thể hữu ích trong một số ngữ cảnh.

Trong một tổ chức cụ thể, loại thứ này có thể được xây dựng bằng cách sử dụng sự kết hợp phù hợp giữa các trình bao bọc tập lệnh và các móc cam kết.

Để đáp lại mối quan tâm bổ sung của Mario với những thay đổi xảy ra ở nhiều nơi trên các tệp nhị phân. Vì vậy, tình huống là Alice và Bob đều thực hiện thay đổi đối với cùng một tài nguyên nhị phân cùng một lúc. Chúng đều có repo cục bộ của riêng mình, được sao chép từ một điều khiển từ xa trung tâm.

Đây quả thực là một vấn đề tiềm ẩn. Vì vậy, Alice hoàn thành đầu tiên và đẩy đến alice/updatenhánh trung tâm . Thông thường khi điều này xảy ra, Alice sẽ thông báo rằng nó nên được xem xét lại. Bob thấy điều đó và đánh giá nó. Anh ta có thể (1) tự kết hợp những thay đổi đó vào phiên bản của mình (phân nhánh từ alice/updatevà thực hiện các thay đổi của mình đối với phiên bản đó) hoặc (2) tự xuất bản các thay đổi của mình lên bob/update. Một lần nữa, anh ấy đưa ra một thông báo.

Bây giờ, nếu Alice đẩy đến masterthay vào đó, Bob sẽ gặp tình huống khó xử khi anh ta kéo mastervà cố gắng sáp nhập vào chi nhánh địa phương của mình. Xung đột của anh với Alice. Nhưng một lần nữa, quy trình tương tự có thể áp dụng, chỉ trên các nhánh khác nhau. Và ngay cả khi Bob bỏ qua tất cả các cảnh báo và cam kết với Alice, vẫn luôn có thể rút ra cam kết của Alice để sửa chữa mọi thứ. Điều này đơn giản trở thành một vấn đề giao tiếp.

Vì (AFAIK) các khóa Subversion chỉ mang tính chất tư vấn, e-mail hoặc tin nhắn tức thì có thể phục vụ cùng một mục đích. Nhưng ngay cả khi bạn không làm điều đó, Git vẫn cho phép bạn sửa nó.

Không, không có cơ chế khóa nào. Nhưng cơ chế khóa có xu hướng chỉ thay thế cho giao tiếp tốt. Tôi tin rằng đó là lý do tại sao các nhà phát triển Git chưa thêm cơ chế khóa.

Gần đây, chúng tôi mới bắt đầu sử dụng Git (đã sử dụng Subversion trước đây) và tôi đã tìm thấy một thay đổi đối với quy trình làm việc có thể giúp giải quyết vấn đề của bạn mà không cần khóa. Nó tận dụng lợi thế của cách git được thiết kế và cách các nhánh dễ dàng.

Về cơ bản, nó tổng hợp để đẩy đến một nhánh không phải chính, thực hiện việc xem xét nhánh đó, và sau đó hợp nhất vào nhánh chính (hoặc bất kỳ nhánh mục tiêu nào).

Cách git được "dự định" được sử dụng, mỗi nhà phát triển xuất bản kho lưu trữ công khai của riêng họ, mà họ yêu cầu người khác lấy từ đó. Tôi nhận thấy rằng người dùng Subversion gặp khó khăn với điều đó. Vì vậy, thay vào đó, chúng tôi đẩy đến các cây nhánh trong kho lưu trữ trung tâm, với mỗi người dùng có cây nhánh của riêng họ. Ví dụ: một hệ thống phân cấp như thế này có thể hoạt động:

users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey

Hãy sử dụng cấu trúc của riêng bạn. Lưu ý rằng tôi cũng đang hiển thị các nhánh chủ đề, một thành ngữ git phổ biến khác.

Sau đó, trong repo cục bộ cho người dùng:

feature1
feature2

Và để đưa nó đến máy chủ trung tâm (nguồn gốc):

git push origin feature1:users/a/feature1

(điều này có thể được đơn giản hóa với các thay đổi cấu hình)

Dù sao, khi feature1 được xem xét, ai sẽ chịu trách nhiệm (trong trường hợp của chúng tôi, đó là nhà phát triển của tính năng, bạn có thể có một người dùng duy nhất chịu trách nhiệm hợp nhất để làm chủ), thực hiện như sau:

git checkout master
git pull
git merge users/name/feature1
git push

Thao tác kéo thực hiện tìm nạp (kéo bất kỳ thay đổi chính mới nào và nhánh tính năng) và bản cập nhật chính đối với những gì mà kho lưu trữ trung tâm có. Nếu người dùng a đã thực hiện công việc của họ và theo dõi chính xác thì sẽ không có vấn đề gì với việc hợp nhất.

Tất cả điều này có nghĩa là, ngay cả khi người dùng hoặc nhóm từ xa thực hiện thay đổi đối với tài nguyên nhị phân, nó sẽ được xem xét trước khi được kết hợp vào nhánh chính. Và có một sự phân định rõ ràng (dựa trên quy trình) về thời điểm một thứ gì đó đi vào nhánh chính.

Bạn cũng có thể lập trình thực thi các khía cạnh của điều này bằng cách sử dụng git hook, nhưng một lần nữa, tôi chưa làm việc với chúng, vì vậy không thể nói về chúng.

Bạn nên kiểm tra quy trình làm việc hiện tại của mình để xem việc khóa hình ảnh có thực sự cần thiết hay không. Việc hai người cùng chỉnh sửa một hình ảnh một cách độc lập là điều tương đối bất thường và một chút giao tiếp có thể giúp ích rất nhiều.

Tôi đã thảo luận vấn đề này trên các nhóm thảo luận git và kết luận rằng tại thời điểm này, không có phương pháp khóa tệp tập trung nào được thống nhất cho git.

Khi tôi sử dụng Subversion, tôi đặt thuộc svn:needs-locktính một cách tôn giáo trên tất cả các tệp nhị phân và thậm chí cả các tệp văn bản khó chỉnh sửa. Tôi chưa bao giờ thực sự trải qua bất kỳ xung đột nào.

Giờ đây, ở Git, tôi không còn lo lắng về những điều như vậy. Hãy nhớ rằng: khóa trong Subversion không thực sự là khóa bắt buộc, chúng chỉ đơn thuần là công cụ giao tiếp. Và đoán xem: Tôi không cần Subversion để giao tiếp, tôi có thể quản lý tốt với E-Mail, Điện thoại và IM.

Một điều khác tôi đã làm là thay thế nhiều định dạng nhị phân bằng các định dạng văn bản thuần túy. Tôi sử dụng reStructuredText hoặc LaΤ _Ε Χ thay vì Word, CSV thay vì Excel, ASCII-Art thay vì Visio, YAML thay vì cơ sở dữ liệu, SVG thay vì OO Draw, abc thay vì MIDI, v.v.

Đây không phải là một giải pháp mà là một nhận xét về lý do tại sao cần có cơ chế khóa. Có một số công cụ được sử dụng trong một số lĩnh vực sử dụng các định dạng chỉ nhị phân là nhiệm vụ quan trọng và "sử dụng các công cụ tốt hơn / khác nhau" không phải là một lựa chọn. Không có công cụ thay thế khả thi nào. Những cái tôi quen thuộc thực sự sẽ không phải là ứng cử viên để hợp nhất ngay cả khi bạn lưu trữ cùng một thông tin ở định dạng ascii. Một ý kiến ​​phản đối mà tôi đã nghe là bạn muốn có thể làm việc ngoại tuyến. Công cụ cụ thể mà tôi đang nghĩ đến thực sự không hoạt động ngoại tuyến vì cần phải lấy giấy phép, vì vậy nếu tôi có dữ liệu trên máy tính xách tay, tôi không thể chạy công cụ khi đang trên tàu. Điều đó nói lên rằng git sẽ cung cấp những gì nếu tôi có kết nối chậm, Tôi có thể nhận giấy phép và cũng có thể kéo xuống các thay đổi nhưng có bản sao cục bộ nhanh để xem các phiên bản khác nhau. Đó là một điều tốt đẹp mà DVCS mang lại cho bạn ngay cả trong trường hợp này.

Một quan điểm cho rằng git đơn giản không phải là công cụ để sử dụng nhưng nó tốt cho tất cả các tệp văn bản cũng được quản lý với nó và thật khó chịu khi cần các công cụ kiểm soát phiên bản khác nhau cho các tệp khác nhau.

Cách tiếp cận kiểu cố vấn-khóa-qua thư thực sự rất khó. Tôi đã thấy điều đó và cảm thấy mệt mỏi với vô số email "Tôi đang chỉnh sửa" "Tôi đang chỉnh sửa xong" và thấy các thay đổi bị mất vì nó. Trường hợp cụ thể mà tôi đang nghĩ đến là một trường hợp mà một bộ sưu tập các tệp ascii nhỏ hơn sẽ đẹp hơn nhiều nhưng đó là một trường hợp sang một bên.

Tôi không mong đợi tính năng khóa tệp sẽ biến nó thành một tính năng trong git. Bạn chủ yếu quan tâm đến loại tệp nhị phân nào? Bạn có thực sự quan tâm đến việc khóa các tệp hay chỉ ngăn chặn các xung đột do không thể hợp nhất chúng.

Tôi dường như nhớ ai đó đã nói (hoặc thậm chí triển khai) hỗ trợ hợp nhất tài liệu OpenOffice trong git.

Còn các tập tin cad thì sao? Nếu các tệp không bị khóa, để được giữ ở chế độ chỉ đọc, hầu hết các chương trình cad sẽ chỉ mở chúng bằng một số bit tùy ý thay đổi, được xem như một tệp mới bởi bất kỳ vcs ​​nào. Vì vậy, theo quan điểm của tôi, khóa là một phương tiện lý tưởng để truyền đạt ý định thay đổi một số tệp cụ thể của bạn. Ngoài ra, nó ngăn cản một số Phần mềm giành được quyền ghi ngay từ đầu. Điều này cho phép cập nhật các tệp cục bộ mà không cần phải đóng phần mềm hoặc ít nhất là tất cả các tệp hoàn toàn.

TortoiseGit hỗ trợ quy trình làm việc git đầy đủ cho các tài liệu Office ủy quyền sự khác biệt cho chính Office. Nó cũng hoạt động ủy quyền cho OpenOffice cho các định dạng OpenDocument.

Tôi không đề nghị sử dụng git tại công ty của tôi cho cùng một vấn đề. Chúng tôi sử dụng EA cho tất cả các thiết kế của mình và microsoft word cho tài liệu, chúng tôi không biết trước ai có thể chỉnh sửa một tệp cụ thể nên khóa độc quyền là lựa chọn duy nhất của chúng tôi.

git sẽ hoạt động rất tốt trong môi trường không nhóm, nơi mỗi nhà phát triển tự chịu trách nhiệm về một đoạn mã hoặc tệp, vì trong trường hợp đó, thông tin liên lạc về khóa là không cần thiết.

Nếu tổ chức của bạn yêu cầu môi trường nhóm (thường để loại bỏ các nhà phát triển khỏi bảo mật công việc), thì hãy sử dụng svn, git không dành cho bạn. Svn cung cấp cả hai - kiểm soát nguồn và giao tiếp giữa các nhà phát triển về khóa.

Chỉ cần đặt một tệp văn bản trong cc với tệp mà bạn muốn khóa và sau đó có móc cập nhật từ chối nó.

Có thể đúng, việc tổ chức lại một dự án có thể giúp tránh các khóa, nhưng:

• Các đội cũng được sắp xếp theo các ưu tiên khác (vị trí, khách hàng, ...)
• Các công cụ cũng được lựa chọn theo các mục tiêu khác (tính tương thích, giá cả, tính dễ sử dụng của hầu hết nhân viên)
• Không thể tránh khỏi một số công cụ (và do đó có tệp nhị phân), vì đơn giản là không có công cụ thay thế nào có thể thực hiện công việc tương tự, phù hợp với nhu cầu của công ty với cùng một mức giá.

Để yêu cầu, toàn bộ công ty có thể tổ chức lại quy trình làm việc của họ và thay thế tất cả các công cụ của họ tạo ra mã nhị phân, chỉ để có thể làm việc với git, vì thiếu khóa, nghe có vẻ không hiệu quả.

Ổ khóa không phù hợp với triết lý git (vốn không bao giờ được tạo ra cho mã nhị phân), nhưng có những tình huống không thể bỏ qua, trong đó ổ khóa là cách hiệu quả nhất để giải quyết vấn đề đó.

Git không cung cấp bất kỳ lệnh nào để khóa tệp nhưng tôi đã tài trợ một cách để đạt được chức năng đó bằng cách sử dụng git hook. Một máy chủ phụ trợ là cần thiết để lưu trữ thông tin khóa. Chúng tôi có thể sử dụng hook cam kết trước để kiểm tra xem có bất kỳ tệp cam kết nào bị khóa hay không. Và nếu bất kỳ ai khóa một tệp, một chương trình sẽ cho máy chủ phụ trợ biết thông tin của khóa và tệp bị khóa.