Tại sao có khu vực dàn dựng giữa "git add" và "git commit"? Tôi hiểu khái niệm, nhưng không thấy ý nghĩa trong việc thêm tệp vào khu vực dàn dựng trước khi thực sự cam kết. Tại sao không bỏ qua bước này?Tại sao có một quá trình dàn dựng trong git?
Một lý do chính là bạn không phải cam kết toàn bộ thư mục làm việc của mình. Bạn có thể di chuyển các phần của nó vào chỉ mục và chỉ cam kết các phần đó.
Ví dụ, bạn đang làm việc trên hai việc khác nhau, và bây giờ mã của bạn trông giống như
//random code
//bug fix
//new feature
Bạn có thể giai đoạn chỉ dòng //bug fix và cam kết đó, và hơn giai đoạn dòng //new feature và cam kết đó.
Giờ đây, bạn có hai cam kết khác nhau cho mỗi loại. Sau đó trong thử nghiệm bạn nhận ra new feature cam kết phá một cái gì đó, bạn có thể xóa new feature cam kết, nhưng không cần phải recommit các bugfix
Như Dickon Reed lưu ý trong câu trả lời của mình, bạn cũng đạt được hiệu suất như git commit bây giờ chỉ cần thêm những gì có trong chỉ mục vào cam kết. Nó không cần phải tìm kiếm thông qua cây của bạn để tìm tất cả các thay đổi.
+1 để đề cập * một số thay đổi trong một số tệp * – eckes
Bạn có thể không muốn chỉ cam kết một số thay đổi của mình. Nếu bạn sửa chữa một cái gì đó bạn có thể cam kết chỉ những thay đổi có liên quan để sửa chữa.
Đây là PITA thuần túy (theo ý kiến khiêm tốn của tôi). Rõ ràng, hầu hết các công cụ giao diện người dùng (thực ra là tất cả những gì tôi biết, bao gồm cả ứng dụng EGit, Mac XCode và GitHub của Eclipse) không tiết lộ tính năng này.
Tôi hiểu khái niệm cam kết một phần. Bạn không muốn cam kết mọi thứ bạn có trên hệ thống tệp của mình. Nhưng việc giới thiệu khái niệm "Giai đoạn" cho nó là quá mức cần thiết.
Hiện tại có 4 giai đoạn cho check-in của bạn phải đi qua:
1. Your file system
2. The staging
3. your local repository
4. the remote upstream
UI frontend git không cho thấy nhiều dàn. Họ cho bạn thấy tất cả những thay đổi bạn có. Bạn kiểm tra những cái bạn muốn cam kết và bạn cam kết trong một thao tác đơn lẻ.
Có thể, đây là chi tiết phân tách được nâng lên thành khái niệm giao diện người dùng. Thay vì một:
commit(X, Y, Z)
bạn có:
add(X), add(Y), add(Z), commit()
Tôi vừa mới bắt đầu khám phá thế giới tuyệt vời của DVCS và mặc dù tôi đã bán linh hồn của tôi để git quỷ nhưng tôi vẫn có cái nhìn không thiên vị .Có một số dự phòng trong ý tưởng của khu vực dàn dựng tuy nhiên bạn có thể bỏ bê khu vực dàn dựng hoàn toàn (mà tôi đã làm trong khi tôi đã sử dụng khách hàng github). Mặt khác, nó mang lại sự linh hoạt hơn vì vậy tôi sẽ nói rằng sự dư thừa không phô trương mà đôi khi có thể giúp bạn một chút.
Điều khiến tôi nghĩ đến là có quá nhiều cụm từ đặt tên cho nó: bộ nhớ cache, khu vực dàn dựng, chỉ mục. Rõ ràng quyết định thiết kế này nổi lên như là tập hợp các khái niệm tương tự và nó có một số lịch sử theo nó. Đặt cược đầu tiên của tôi đã chứng tỏ là hợp lý - tôi đã truy cập trang web Bitkeeper và tìm thấy "dàn dựng" ở đó (họ sử dụng nó để phân nhánh theo yêu cầu)
Bây giờ tôi đoán rằng tại thời điểm Bitkeeper quản lý nguồn Linux tính năng này bị lạm dụng và thay vì tạo chi nhánh theo yêu cầu cho một số nhà phát triển, nó chỉ được một nhà phát triển sử dụng. Và sau đó vì trường hợp sử dụng này được chứng minh là Git hữu ích kết hợp phiên bản nhẹ của "khu vực dàn dựng" được triển khai thuận tiện bằng cách cung cấp giao diện người dùng cho "chỉ mục" hoặc "bộ nhớ cache".
+1. 'git add -p' có lẽ là tính năng git yêu thích của tôi. – MatrixFrog
url hoạt động: https://git.wiki.kernel.org/articles/w/h/a/WhatIsTheIndex_edd2.html – gilligan
@gilligan Cảm ơn, đã cập nhật liên kết. – Andy