Cái nào chiếm nhiều không gian đĩa hơn? Làm thế nào để bạn theo dõi sửa lỗi (chúng tôi đang sử dụng Jira)? Làm thế nào để bạn biết được chi nhánh hoặc kho lưu trữ nào có sửa lỗi? phải có những ưu điểm/nhược điểm khác đối với kho lưu trữ so với chi nhánh?git branch so với git repository, cái nào tôi nên sử dụng?
Câu hỏi của bạn không mang lại nhiều ý nghĩa. Các kho chứa luôn chứa ít nhất một nhánh và bạn không thể có một chi nhánh không có kho lưu trữ. Vì vậy, tất nhiên, một chi nhánh nhỏ hơn một kho lưu trữ. Cả hai không thực sự là những thứ có thể so sánh được.
Vì vậy, hãy nói một chút về kho chứa Git thực sự chứa. Có một vài điều chính:
việc cây - đây là tình trạng hiện thời của tất cả các tập tin của bạn, những người bạn đang làm việc trên. Điều này có thể chiếm một số lượng khá lớn của không gian.
đối tượng - đây là cách nội bộ git lưu trữ mọi thứ - blobs để thể hiện nội dung của tệp, cây đại diện cho cấu trúc thư mục, cam kết đại diện cho ảnh chụp nhanh của cây công việc. Đây là thứ khác thực sự chiếm không gian.
refs - viết tắt của tham chiếu: chi nhánh hoặc thẻ. Chúng rất, rất nhẹ - chúng chỉ là con trỏ tới các cam kết cụ thể. Chúng chiếm một không gian nhỏ, nhưng nó quá ít đến nỗi bạn nên nghĩ chúng hoàn toàn miễn phí. Thẻ là tham chiếu cố định; họ chỉ đến một cam kết vĩnh viễn và được sử dụng cho những thứ như đánh dấu các phiên bản. Các nhánh là các tham chiếu di chuyển; với một kiểm tra ra, nó tiến lên phía trước như bạn cam kết. Đó là những gì bạn sẽ sử dụng để đại diện cho các dòng phát triển - một nhánh ổn định, một chi nhánh cho một bugfix hoặc tính năng cụ thể, bạn đặt tên cho nó.
Có những thứ khác bên trong thư mục .git bên cạnh các đối tượng và ref, nhưng hiện tại bạn không quan tâm nhiều đến chúng.
Làm thế nào để bạn theo dõi các sửa lỗi (chúng tôi đang sử dụng Jira)?Làm thế nào để bạn biết được chi nhánh hoặc kho lưu trữ nào có sửa lỗi?
Đây là loại tùy thuộc vào bạn. Nói chung mọi người kết thúc việc nhúng một số thông tin trong thông báo cam kết của họ để cho biết rằng họ giải quyết một số lỗi/vấn đề cụ thể. Bạn có thể có một quy trình làm việc được xác định, nơi bạn thực hiện các sửa lỗi trên các nhánh của riêng mình (hoặc có thể là một nhánh bảo trì trên bản phát hành trước) và hợp nhất chúng vào nhánh phát triển hiện tại của bạn, từ đó chia sẻ các sửa lỗi với phiên bản sau. Bạn sẽ có thể nói điều gì đó như "các nhánh chủ và bảo trì luôn luôn có tất cả các bản sửa lỗi" - mặc dù nếu bạn muốn kiểm tra, bạn có thể làm điều gì đó như git log --grep='bug 1234', giả sử bạn đã đặt chuỗi đó vào thư cam kết của mình!
Nói chung, không cần phải có nhiều bản sao của kho lưu trữ của cùng một dự án. Có thể bạn sẽ có một trung tâm, và mỗi nhà phát triển sẽ có riêng của họ - nhưng khi một nhà phát triển xuất bản tác phẩm của họ, họ sẽ đặt nó vào trung tâm, và đó là nơi mọi thứ quan trọng.
Với tôi, một kho lưu trữ nên có một dự án riêng biệt. Chi nhánh là một "con đường" phát triển trên dự án. Vì vậy, bạn có thể có một chi nhánh phát triển, một chi nhánh sản xuất, và một vài chi nhánh tính năng, và một số chi nhánh sửa lỗi. Các chi nhánh có thể được sáp nhập với nhau khi cần thiết và cuối cùng sáp nhập vào phát triển và sản xuất.
Không gian đĩa: toàn bộ kho lưu trữ lớn hơn việc tạo chi nhánh, vì chi nhánh chỉ là con trỏ khi được tạo lần đầu tiên, trong khi toàn bộ kho lưu trữ cần lưu trữ tất cả các tệp git.
Chi nhánh luôn luôn tốn kém hầu như không có gì để tạo bên trong cùng một repo (kỹ thuật nói nó phụ thuộc vào những gì bạn đặt trong chi nhánh, nhưng tôi chắc chắn rằng đó là rõ ràng để bắt đầu với).
Khi nhân bản repo, bạn có thể kết thúc với yêu cầu bộ nhớ gấp đôi (cả cho gói và cho cây đang hoạt động). Tuy nhiên, điều này có thể khiến bạn tin rằng kho lưu trữ nhân bản nhất thiết phải là điều tối ưu. Hãy để tôi cho bạn biết lý do tại sao điều đó không phải lúc nào cũng đúng/
Một repo thực sự chỉ là một bộ sưu tập các chi nhánh. Một chi nhánh thực sự là (như trong sao chép sâu) mất nhiều như một repo, ngoại trừ các đốm màu cam kết duy nhất cho một chi nhánh cụ thể. (Thường không có nhiều khác biệt ở đó).
Tại địa phương, bạn có thể sao chép một repo mà không mất thêm chi phí vì nó có thể được liên kết cứng (trong cùng hệ thống tệp). Ngoài ra, chi phí phát sinh bằng cách có một cây làm việc khác có thể tránh được bằng cách nhân bản thành một repo trần (ví dụ: bằng cách sử dụng git clone --mirror).
trong một dự án
Theo tôi, một repo tương ứng với một 'người chơi' trong công việc phân phối. Người chơi có thể là 'người tự nhiên' hoặc 'vai trò proxy'. Tôi có
trong thực tế chỉ có 3-4 loại chi nhánh được chia sẻ acros s tất cả của repo (chủ, maint, thử nghiệm, không ổn định).
NGOÀI DỰ ÁN
Tất nhiên, một dự án wil có nó là repo riêng (hầu hết thời gian). Tôi bắt đầu nghiêng về phía việc sử dụng các mô-đun con vì nó có vẻ linh hoạt hơn các nhánh dị (tức làcác dự án khác nhau trong các chi nhánh riêng biệt của cùng một kho)
Một lợi ích lớn của việc có một repo đơn là sẽ rất trơn tru khi chuyển đổi cây làm việc liên quan từ nhánh này sang nhánh khác. Để công bằng sự khác biệt này có thể được làm việc arounnd theo hai hướng:
Bạn thấy đấy, một repo bắt đầu là một tập hợp các chi nhánh, với một hiệp hội ít nhiều đến một cây làm việc duy nhất. Các quy ước là nơi sự khác biệt thực sự xuất hiện: bạn thường là sử dụng repo để quản lý bộ chi nhánh và cây làm việc khác nhau.
Chi nhánh mất nhiều như repo? Bạn đã sử dụng git? – Cascabel
Giống như bạn làm :) tyvm, tôi sử dụng git độc quyền; tại sao bạn sẽ từ nó khác nhau? Đối với tất cả các ý định và mục đích, trên một hệ thống tập tin cục bộ, không có nhiều sự khác biệt giữa 'git branch bla' hoặc' git clone. ../ blo' ngoại trừ các cây đang hoạt động trong kho không có trụ; tại sao bạn muốn cụm từ nó khác nhau? – sehe
Er, không phải là cây làm việc đủ của một sự khác biệt? Và nếu vì lý do gì đó, kho lưu trữ không nằm trên cùng một hệ thống tệp, bạn cũng tăng gấp đôi phần còn lại. (Và đó chỉ là không gian đĩa - nó cũng sẽ mất thời gian của con người để giữ cho chúng được đồng bộ!) Tôi nghĩ rằng với thực tế là OP hỏi câu hỏi này, bạn phải cẩn thận hơn một chút. Tạo chi nhánh về cơ bản luôn miễn phí; nhân bản một repo là không. Nếu bạn có thể tinh chỉnh câu đầu tiên tôi sẽ sẵn sàng lấy đi phần còn lại của tôi - phần còn lại của câu trả lời của bạn là tuyệt vời, tôi chỉ tìm thấy phần mở đầu cực kỳ gây hiểu nhầm. – Cascabel
Chi nhánh trong một repo cũng có lợi thế ngoài các nhận xét khác. Nhiều công cụ đồ họa (hoặc văn bản giao diện người dùng) có thể hiển thị cho bạn thông tin về các commit/tags/etc trên các nhánh trong một repo. Dữ liệu đó sẽ không có sẵn nếu bạn tạo một kho lưu trữ mới mỗi khi bạn muốn bẻ gãy phát triển.
Bạn cũng sẽ có thời gian dễ dàng hơn để thể hiện chi nhánh của các mối quan hệ chi nhánh khi sử dụng phân nhánh nội bộ. Nó chỉ là tự nhiên ở đó, trong khi với repo bổ sung, bạn phải theo dõi và quản lý mối quan hệ bên ngoài.
Lý do tôi hỏi là vì tôi đã tham gia một số khóa đào tạo git gần đây, và người hướng dẫn đã cho thấy một quy trình làm việc có 2 repos. Một là dành cho dev trên nhánh master. Repo này được xây dựng và thử nghiệm và sau đó các cam kết được đẩy vào repo "vàng" để sử dụng bởi QA. Chúng tôi đang cố gắng băm ra các lý do để sử dụng mô hình này, so với sử dụng các chi nhánh. Cảm ơn ý kiến của mọi người. Tôi học rất nhiều như thường lệ. :-) – user561638
Nếu repo nhân bản của bạn nằm trên cùng một đĩa và sử dụng liên kết cứng, nó có thể không sử dụng nhiều không gian hơn. Không chỉ là một con trỏ, đó là tất cả các chi nhánh sử dụng, nhưng không nhất thiết phải là bản sao của tất cả các tập tin. – bstpierre
Lý do tôi hỏi là vì tôi đã tham dự một số khóa đào tạo git gần đây, và người hướng dẫn đã cho thấy một quy trình làm việc, nơi có 2 repos. Một là dành cho dev trên nhánh master. Repo này được xây dựng và thử nghiệm và sau đó các cam kết được đẩy vào repo "vàng" để sử dụng bởi QA. Chúng tôi đang cố gắng băm ra các lý do để sử dụng mô hình này, so với sử dụng các chi nhánh. Cảm ơn ý kiến của mọi người. Tôi học rất nhiều như thường lệ. :-) – user561638