Lợi ích của quá trình cam kết hai giai đoạn (dàn dựng) của git là gì?

174

Tôi đang học git và tôi nhận thấy rằng nó có quy trình cam kết hai bước:

git add <files>
git commit

Bước đầu tiên đặt bản sửa đổi vào cái được gọi là "khu vực tổ chức" hoặc "chỉ mục".

Điều tôi quan tâm là tại sao quyết định thiết kế này được đưa ra, và lợi ích của nó là gì?

Ngoài ra, là một người dùng git, bạn làm điều này hay chỉ sử dụng git commit -a?

Tôi hỏi điều này khi tôi đến từ bzr (Bazaar) không có tính năng này.

version-control git workflows

— thomasrutter
nguồn

3

+1 để hỏi. Tôi sử dụng Rùa SVN, có cùng cách tiếp cận và tôi không bao giờ hiểu tại sao.

— DPD

3

Khu vực tổ chức không phải là bất thường. Tương tự, giả sử, TFS sẽ kiểm tra hoặc bỏ chọn hộp bên cạnh một tệp trước khi đăng nhập. Chỉ các tệp đã kiểm tra được cam kết. Sự khác biệt với Git là nếu bạn sử dụng git add -p, bạn có thể chọn cam kết một phần của tệp trong khi không cam kết một phần khác của cùng một tệp .

— Kyralessa

Tôi thấy rằng liên kết này tóm tắt hầu hết những gì đã được trả lời ở đây và thêm một vài trường hợp sử dụng nữa để biện minh cho nhu cầu dàn dựng.

— Veverke

2

Câu hỏi này thực sự đã được trả lời, nhưng đây cũng là một lời giải thích hay: stackoverflow.com/questions/4878353/ trên

— guitar_freak

1

Đừng quên git statusvà có thể git push. Đối với tất cả các hype về git, (và mã GitHub chia sẻ thật tuyệt vời) phần là rất khó chịu

— user949300

83

Chia công việc thành các cam kết riêng biệt. Có lẽ bạn đã nhiều lần mở một tệp để viết một sửa chữa một dòng, nhưng đồng thời bạn phát hiện ra rằng định dạng sai, một số tài liệu có thể được cải thiện hoặc một số sửa chữa không liên quan khác. Với các RCS khác , bạn phải ghi lại hoặc ghi vào bộ nhớ, hoàn thành bản sửa lỗi bạn đã thực hiện, cam kết và sau đó quay lại để sửa các nội dung khác (hoặc tạo một cam kết bóng với những thứ không liên quan) . Với Git, bạn chỉ cần sửa tất cả cùng một lúc và giai đoạn + cam kết một dòng riêng biệt, bằng git add -ihoặc git-gui.

Đừng phá vỡ công trình. Bạn đang làm việc trên một sửa đổi phức tạp. Vì vậy, bạn thử những thứ khác nhau, một số trong đó hoạt động tốt hơn những thứ khác, một số trong đó phá vỡ mọi thứ. Với Git, bạn sẽ xử lý mọi thứ khi sửa đổi làm mọi thứ tốt hơn và checkout(hoặc chỉnh sửa thêm một chút) khi sửa đổi không hoạt động. Bạn sẽ không phải phụ thuộc vào chức năng hoàn tác của trình chỉnh sửa, bạn có thể checkouttoàn bộ repo thay vì chỉ theo từng tệp và bất kỳ lỗi cấp tệp nào (chẳng hạn như xóa tệp không được cam kết hoặc lưu + đóng sau khi sửa đổi xấu) không dẫn đến nhiều công việc bị mất.

— l0b0
nguồn

3

Đến từ một DVCS (bzr) không có tính năng này, nghe có vẻ giống như những gì tôi hiện đang đạt được với sự kết hợp sử dụng tự do bộ đệm "hoàn tác" của trình soạn thảo của tôi, lệnh "hoàn nguyên <file>" và các cam kết chọn lọc (" cam kết <file> "). Âm thanh như tính năng này của git có khả năng mang tính phương pháp hơn.

— thomasrutter

1

Về "các RCS khác", điều đó không hẳn đúng. Trên thực tế, bạn có thể đạt được những chức năng tương tự trong Mercurial bằng cách sử dụng các bản vá .

— Lucio Paiva

1

@ l0b0, về điểm thứ hai của bạn. Nếu chỉ có một cam kết giai đoạn duy nhất, bạn có thể đã thực hiện các thay đổi (mà bạn sử dụng với git add) trực tiếp như một cam kết. Nếu bạn phát hiện ra rằng bạn đã làm điều gì đó sai, bạn sẽ xóa cam kết và quay lại vị trí trước khi bạn thực hiện cam kết. Với khái niệm dàn dựng, không phải bạn chỉ làm điều đó, mà thêm phần phức tạp?

— alpha_989

Điểm đầu tiên của bạn có ý nghĩa, mặc dù tôi đã không sử dụng nó, cho đến nay. Về mặt lý thuyết tại sao bạn không thể làm một cái gì đó giống như git add -ivới một cam kết một giai đoạn? Bạn chỉ cần chọn một loạt các tệp (hoặc dòng trong tệp) liên quan đến một tính năng và thực hiện một cam kết. Sau đó, bạn sẽ quay lại và thực hiện cam kết thứ hai liên quan đến một tính năng khác ..

— alpha_989

@thomasrutter, Từ tuyên bố của bạn, có vẻ như bạn đang đề xuất rằng khu vực tổ chức tạo ra "điểm hoàn tác thủ công". Trong VIM với liên tục hoàn tác, bạn có thể nhận được lịch sử không giới hạn rất đáng tin cậy. Điều này cũng được theo dõi tự động theo git-branchkiểu thời trang ( jovicailic.org/2017/04/vim-persistent-undo ). Hơn nữa lịch sử hoàn tác của bạn được tự động theo dõi mỗi khi bạn chuyển sang chế độ bình thường. Vì vậy, nó làm giảm gánh nặng tinh thần của bạn khi phải tạo ra "điểm hoàn tác thủ công". Tại sao việc sử dụng bộ chỉnh sửa "hoàn tác" bộ đệm của bạn không theo phương pháp?

— alpha_989

65

Một trong những lợi ích đối với tôi là khả năng "thêm" các tập tin dần dần. Trước khi cam kết tôi xem lại từng tập tin. Khi tập tin được xem xét, tôi thêm nó. Khi tôi git statushoặc git diff, git chỉ hiển thị cho tôi các tệp đã được sửa đổi và chưa được thêm vào. Khi tôi đã xem xét tất cả các tệp và thêm chúng, sau đó tôi có thể cam kết.

Vì vậy, có, tôi thấy khu vực dàn dựng rất hữu ích.

Và không, tôi không bao giờ sử dụng git commit -a. Tuy nhiên, tôi thường sử dụng git add -u. Bằng cách này tôi vẫn có thể hình dung những gì sẽ được cam kết.

— David
nguồn

2

Chính xác. Ưu điểm là kiểm soát chi tiết tốt hơn nhiều so với chính xác những gì bạn đang thực hiện.

— Josh K

Điều gì xảy ra khi bạn giai đoạn một tập tin nhiều lần? nó có được "sáp nhập" trong khu vực tổ chức không?

— m4l490n

21

Lợi ích khá đơn giản: nó cung cấp cho bạn toàn quyền kiểm soát các tệp bạn muốn cam kết khi nào. Đối với vấn đề đó, bạn có thể sử dụng git add -pđể kiểm soát dòng nào bạn muốn cam kết.

— Hen Hen
nguồn

2

Tôi đã luôn tự hỏi về cách làm điều này. Tôi ước có một tệp .gitignorelinesđể bạn có thể thực hiện các thay đổi cục bộ cho từng dòng riêng lẻ có thể tồn tại và vẫn còn nguyên.

— alex xám

3

@ReinHenrichs, hãy suy nghĩ về các tệp cấu hình cần thay đổi của mỗi nhà phát triển.

— Ian

1

@Ian Vì vậy, một phần của tệp thay đổi không thường xuyên và được chia sẻ và một phần của tệp thay đổi thường xuyên, theo những cách không tương thích và không được chia sẻ? Hỗ trợ sự đồng cảm sai lầm này chắc chắn nghe giống như một tính năng chống.

— Rein Henrichs

1

@ReinHenrichs, vâng và nó rất phổ biến khi tệp chứa tên của máy chủ cơ sở dữ liệu và mỗi nhà phát triển có cơ sở dữ liệu riêng.

— Ian

4

@Ian Vấn đề của bạn thực sự là ở đó, rằng bạn có một tệp được cho là cấu hình cho ứng dụng cũng chứa một số cấu hình cụ thể của máy / dev. Tất cả các hệ thống cấu hình mà tôi biết cho phép bạn chia nó thành nhiều tệp. Vì vậy, ví dụ bạn có app.confcái chứa những thứ bạn muốn chia sẻ, và sau đó là db.confthứ bạn vừa đưa vào danh sách .gitignore. Vấn đề được giải quyết. Nếu bạn đang sử dụng thứ gì đó độc quyền, bạn thực sự nên tìm kiếm thứ gì đó thật đơn giản trong đó. Hoặc đặt nó thông qua một bộ tiền xử lý trong một sự kiện xây dựng trước. Nhiều giải pháp đấy.

— Aidiakapi

1

Một trong những lợi ích mà tôi thích là khả năng cam kết một phần của sự thay đổi. Tức là, bằng cách sử dụng git add -e. Thỉnh thoảng tôi không cam kết thường xuyên và lệnh git add -e cho phép tôi làm sáng tỏ những thay đổi của mình đến một mức độ nào đó.

— leed25d
nguồn