Git có nên được sử dụng cho tài liệu và quản lý dự án? Mã có nên ở trong một kho lưu trữ riêng biệt?

Tôi đang bắt đầu một kho lưu trữ Git cho một dự án nhóm. Liệu có ý nghĩa gì khi lưu trữ tài liệu trong cùng kho Git dưới dạng mã - có vẻ như điều này mâu thuẫn với bản chất của luồng sửa đổi git.

Dưới đây là tóm tắt câu hỏi của tôi:

• Là kiểu sửa đổi Git sẽ gây nhầm lẫn nếu cả mã và tài liệu được kiểm tra vào cùng một kho lưu trữ ? Kinh nghiệm với điều này?

• Git có phù hợp để kiểm soát sửa đổi tài liệu không?

• Tôi KHÔNG hỏi liệu Hệ thống kiểm soát sửa đổi nói chung nên hay không nên được sử dụng cho tài liệu - nó nên.

Cảm ơn các phản hồi cho đến nay!

Chúng tôi lưu trữ tài liệu trong SVN tất cả các thời gian. Trên thực tế, toàn bộ hướng dẫn sử dụng của chúng tôi được viết bằng LaTeX và được lưu trữ trong SVN. Chúng tôi chọn LaTeX đặc biệt vì đây là ngôn ngữ dựa trên văn bản và dễ dàng hiển thị các khác biệt theo từng dòng.

Chúng tôi cũng lưu trữ một số tệp không được định dạng văn bản, như tệp Microsoft Office .doc, bảng tính trải rộng, tệp .zip, v.v., khi cần thiết ... nhưng một số lợi ích của RCS bị mất khi bạn không thể thấy sự gia tăng khác biệt

Chìa khóa thực sự là đảm bảo tài liệu của bạn được tổ chức tốt, để mọi người có thể tìm (và cập nhật) tài liệu (và nguồn) khi họ cần.

Vâng, nó phụ thuộc vào định dạng nào bạn sử dụng cho tài liệu. Nếu nó là một cái gì đó dựa trên văn bản thì tất cả đều tốt.

Git cũng có thể lưu trữ nội dung nhị phân và bạn có thể theo dõi các bản sửa đổi, nhưng đầu ra khác biệt sẽ không có ý nghĩa.

Cũng có thể lưu trữ tài liệu trong chính mã như perldoc pod, java cũng có một số định dạng / chú thích cho việc này.

Tôi không thể tưởng tượng được tại sao bạn nghĩ rằng có thể có vấn đề khi sử dụng git hoặc bất kỳ hệ thống kiểm soát phiên bản nào khác, cho tài liệu. Giống như mã nguồn, tài liệu nên có lịch sử đầy đủ và khả năng hoàn nguyên về phiên bản cũ hơn nếu điều đó trở nên cần thiết. Một hệ thống kiểm soát phiên bản là hoàn hảo cho việc này.

Rõ ràng rằng việc sử dụng một số loại Hệ thống kiểm soát phiên bản để lưu trữ tài liệu là một công cụ cao cấp. Phần thú vị hơn của câu hỏi là liệu có nên lưu trữ tài liệu ở vị trí CÙNG làm mã nguồn không? Vấn đề có thể xảy ra ở đây là khó có thể thiết lập các đặc quyền truy cập khác nhau cho mã và tài liệu trong trường hợp đó. Và trong nhiều trường hợp kinh doanh, mọi người sẽ cần truy cập vào tài liệu chứ không phải mã nguồn, như bộ phận tiếp thị hoặc BA.

Trong công ty mà tôi làm việc, chúng tôi đưa tài liệu vào SVN. Tuy nhiên, sau một vài xung đột và nhu cầu chia sẻ nó, chúng tôi đã quyết định chuyển nó sang Mediawiki.

Lúc đầu, nó là trac, sau đó chuyển sang Mediawiki vì nó dễ sử dụng hơn ...

Vấn đề chính với SVN là nguyên nhân chia sẻ chúng tôi có hệ thống ủy quyền cho SVN.

• Có nhiều hơn chỉ là mã nguồn trong một kho lưu trữ là một điều rất tốt.

  Nó nhóm tất cả các tài nguyên của bạn lại với nhau và biến dự án thành một thực thể tập trung, gắn kết chứ không phải là một bộ sưu tập các tệp rải rác. Người đóng góp / nhân viên biết nơi tìm mọi thứ, thay vì gửi "Tôi thay đổi tài liệu cho tính năng x ở đâu?" email.

  Bạn sẽ muốn giữ mọi thứ ngăn nắp. Có một hệ thống để tách srctừ imageskhỏi docs. Bạn luôn có thể thêm một .gitignorethư mục để giữ cho kho lưu trữ và lịch sử sạch sẽ. Vì các cam kết Git dựa trên tệp, * bạn có thể tách rời các thay đổi nguồn từ các thay đổi tài liệu mạnh mẽ như bạn muốn.

• Như những người khác đã nói, Git là tuyệt vời cho phiên bản tài liệu miễn là nó dựa trên văn bản.

• Tôi hoàn toàn đồng ý; tài liệu nên được phiên bản ngay bên cạnh mã.

Sự tín nhiệm của tôi đến từ việc trở thành người dùng GitHub và đóng góp cho một dự án và khám phá nhiều dự án khác. Theo kinh nghiệm của tôi, một dự án hoàn chỉnh, thống nhất rất dễ để nói từ một nửa còn thiếu. Tôi cố gắng để chứa tất cả các dự án của tôi trong các thư mục bất cứ khi nào có thể.

Tôi đến đây với một câu hỏi tương tự. Chúng tôi đến từ một môi trường SVN, nơi về cơ bản là không có trí tuệ để giữ tất cả các tài liệu liên quan đến một dự án trong cùng một kho lưu trữ. Do tính chất của SVN, bạn có thể dễ dàng kiểm tra các phần của kho lưu trữ, vì vậy nếu bạn chỉ cần mã nguồn (ví dụ: triển khai trang web), thì không vấn đề gì.

Với Git, mọi thứ đã khác. Thanh toán luôn ở cấp độ gốc, vì vậy nếu bạn muốn đặt mọi thứ vào cùng một kho lưu trữ, bạn sẽ luôn kết thúc với cùng một cấu trúc thư mục. Một cách tiếp cận tôi đã gặp là đặt mọi thứ vào các nhánh riêng biệt, tức là bạn có các nhánh mã (thường là các nhánh chính, phát triển, v.v.) và một nhánh doc, có cấu trúc thư mục riêng, riêng. Tôi không chắc chắn đó là ý tưởng tốt nhất, nhưng đó là một gợi ý giúp giải quyết vấn đề mà tôi tưởng tượng là nền tảng của câu hỏi của bạn.

Tôi sử dụng wiki cho các tài liệu nội bộ ... nhận bản sửa đổi PLUS truy cập nổi bật / chỉnh sửa dễ dàng. Khi tài liệu không đồng bộ, hãy cập nhật nó ngay lúc đó và ở đó. Đối với tài liệu của người dùng cuối, hãy xem xét một công cụ chuyên nghiệp như Madcap Flare Họ sử dụng phương ngữ XML để chia sẻ, soạn thảo và chuyển đổi tài liệu.

Trong mã, các suy nghĩ thường được phân tách theo từng dòng. Tôi có xu hướng viết tài liệu với kết thúc tốt đẹp. Khi tôi cam kết các tệp đó, các dòng là cả một đoạn dài. Điều đó không hữu ích để đọc git diff. Đó là vấn đề tôi đã cố gắng giải quyết khi tôi tìm kiếm và tìm thấy trang này. Cảm ơn Arne Hartherz đã giới thiệu cho tôi git diff --word-diff. Bạn có thể thích git diff --color-wordsthậm chí tốt hơn.