Git Staging: Khi nào lên sân khấu? Phải làm gì nếu sửa đổi xảy ra sau đó

Tôi còn khá mới mẻ với thế giới rộng lớn của Git. Tôi đã đọc hướng dẫn và đang thực hành nhưng tôi bối rối về một số khía cạnh của nó, điều mà tôi không thể tìm ra sau khi tìm kiếm.

Tôi tự hỏi:

• Trong một dự án (đăng bài cam kết đầu tiên), khi nào là thời điểm thích hợp để tạo tập tin nguồn? Ngay trước khi cam kết? Ngay sau khi thêm / xóa hoặc sửa đổi?

• Nếu các tệp được đặt ở giữa hai lần xác nhận và sau đó chúng được sửa đổi, điều gì xảy ra với Git? Có cần quan tâm về thay đổi nội dung khi nó được nêu và những gì nó trở thành kể từ đó?

• Nếu tôi tạo một tệp mới, tạo giai đoạn cho nó và sau đó muốn xóa nó, tại sao Git yêu cầu tôi sử dụng cờ "-f" và một tệp "git -rm.ext" đơn giản sẽ không hoạt động?

Tôi đã đọc "Giai đoạn nào có nghĩa là" và nhiều chủ đề khác của hướng dẫn và các hướng dẫn khác về Git nhưng như tôi đã nói, tôi vẫn không hiểu các vấn đề trên.

Vì vậy, nếu bạn có thể, xin vui lòng trả lời các câu hỏi bằng các từ và ví dụ của riêng bạn để tôi có thể có cơ hội hiểu rõ hơn về nó.

Cảm ơn bạn.

Mục đích của khu vực tổ chức là để có một không gian linh hoạt cho cam kết của bạn. Tôi nghĩ rằng điều này sẽ trở nên rõ ràng hơn nếu bạn tương phản git với các hệ thống kiểm soát phiên bản được tập trung hóa, chẳng hạn như lật đổ.

Lật đổ

Trong lật đổ, bạn có thể chọn để cam kết một số tệp của bản sao làm việc của bạn. Nhưng chỉ có các tập tin hoàn chỉnh. Bây giờ: Điều gì sẽ xảy ra nếu bạn muốn tạo tập tin giai đoạn A, không phải tập tin Bvà các phần của tập tin Cliên quan đến tập tin Amà không phải là các phần phụ thuộc vào thay đổi trong tập tin B(từ đó bạn sẽ gặp vấn đề với tính nhất quán của cam kết).

Git

Git giải quyết điều này bằng cách cung cấp dàn dựng như là bản sao làm việc thứ hai. Trong khu vực tổ chức, bạn sẽ ghép một ảnh chụp nhanh mà bạn sẽ cam kết (nói đại khái).

Do đó, trong khu vực tổ chức, bạn có thể tạo một ảnh chụp nhanh bao gồm các thay đổi Avà một phiên bản tệp Cchỉ phản ánh các thay đổi trong đó A.

Đối với các câu hỏi cụ thể

• Bạn có thể giai đoạn tại bất kỳ điểm nào bạn muốn. Cá nhân tôi thích lên sân khấu ngay trước khi tôi khởi động cam kết.

• Khi có các thay đổi trong một tập tin được sắp xếp và sau đó thay đổi tập tin đó trong bản sao làm việc, bạn đã không thay đổi tập tin theo giai đoạn. Bạn có thể quyết định có nên thực hiện những điều đó hay không hoặc có nên thay đổi giai đoạn đó không. Tức là nếu bạn chạy, git gui citoolbạn sẽ thấy sự khác biệt của các phiên bản được dàn dựng và không được dàn dựng (các công cụ đơn giản và đẹp mắt để dàn dựng và cam kết theo dòng thông minh).

• Git thận trọng ở đây, đó có lẽ là một điều tốt.

Chiến lược cam kết chung: Cam kết chi tiết

Tôi nghĩ khi nói về câu hỏi "Khi nào tôi nên lên sân khấu", người ta cũng nên nói về thói quen cam kết.

VCS tập trung

Trong các hệ thống kiểm soát phiên bản tập trung nơi bạn cam kết với một máy chủ trung tâm, điều quan trọng đối với đồng nghiệp là các cam kết của bạn đã hoàn tất và được kiểm tra tốt. Vì vậy, mọi người sẽ cố gắng cam kết không thường xuyên và sau đó cam kết trạng thái của các tệp hoàn chỉnh để giảm thiểu khả năng xảy ra lỗi. Do đó, một cam kết có xu hướng khá lớn, bao gồm rất nhiều thay đổi (nếu chúng không phải là sửa chữa đơn giản). Những thay đổi trong một cam kết có thể hoàn toàn không liên quan.

Git

Trong Git, một cam kết được thực hiện cục bộ, chỉ đẩy chúng ra một máy chủ khiến chúng trở nên công khai. Do đó, một cam kết là giá rẻ trong một ý nghĩa. Một cam kết trong ý nghĩa lật đổ là khá so sánh với một số git committheo sau git push. Sự khác biệt này có vấn đề.

Git cho phép bạn cam kết các dòng mã, ngay cả khi bạn đã thay đổi các dòng khác trong cùng một tệp. Điều này mang lại cho bạn rất nhiều lợi ích vì ví dụ bạn có thể phạm phải lỗi bảo mật trong dòng 100 trong khi đã thay đổi dòng 300-350 giới thiệu một tính năng mới.

• Bạn có thể tách các thay đổi khác nhau trong các cam kết khác nhau. Điều này phân tách chúng độc đáo trong lịch sử phiên bản của bạn và thậm chí cho phép bạn hoàn nguyên cái này nhưng không phải cái kia.
• Cam kết của bạn không nhất thiết phải phản ánh trạng thái "biên dịch" bản sao làm việc của bạn (mặc dù tôi cố gắng giữ nguyên như vậy).

Vậy đâu là "kiểm soát chất lượng" và bảo đảm xây dựng trong một cam kết mà người dùng lật đổ sẽ mong đợi? Nó được chuyển sang các hành động khác trong git. Bạn vẫn muốn đưa ra một trạng thái hoạt động của chương trình trong một kho lưu trữ công cộng. Do đó, bạn đảm bảo rằng các bài kiểm tra thành công và chương trình hoạt động trước khi đưa ra các thay đổi của bạn.

Ngoài ra, hãy cố gắng sử dụng các chi nhánh đến mức tối đa. Khi cam kết nhiều thay đổi nhỏ, bạn sẽ có một lịch sử phiên bản khá lớn. Nếu bạn làm việc trong các nhánh, bạn có thể phân loại các cam kết chi tiết đó theo tên nhánh và sau đó hợp nhất chúng lại (tùy chọn --no-ffcũng sẽ bảo tồn các tính năng này sống trong một nhánh duy nhất).

Tức là bạn chỉ có thể giữ thói quen sáp nhập vào masterchi nhánh, nếu chi nhánh ở trạng thái tốt . Bạn cũng có thể sử dụng thẻ để theo dõi các mốc và phát hành.

Bây giờ để quay lại dàn dựng: Một khi bạn cam kết một vài dòng cho mỗi lần cam kết, bạn sẽ trực tiếp thực hiện trước khi cam kết. (Ít nhất đó là cách tôi làm điều đó).

Tôi nghĩ rằng bạn đang thực hiện nó quá nghiêm trọng. Dàn dựng chỉ là chọn những thứ bạn muốn đưa vào cam kết tiếp theo. Nó rất hiếm khi quan trọng khi hoặc cách bạn thực hiện việc dàn dựng; và nếu bạn có nhiều thay đổi được dàn dựng và không theo giai đoạn tại bất kỳ thời điểm nào, có lẽ bạn cần phải xem lại quy trình phát triển của mình.

Trong một dự án (đăng bài cam kết đầu tiên), khi nào là thời điểm thích hợp để tạo tập tin nguồn? Ngay trước khi cam kết? Ngay sau khi thêm / xóa hoặc sửa đổi?

Tôi thường làm điều đó ngay trước khi cam kết (trừ khi tôi nhận thấy một số lỗi đánh máy, vì vậy tôi phải sửa lỗi vào phút cuối và cũng xử lý nó). Quá trình này là như sau: chỉnh sửa, chạy thử nghiệm, giai đoạn, cam kết. Nếu bạn giai đoạn trước khi thử nghiệm, rất có thể các thử nghiệm sẽ thất bại và bạn sẽ phải thực hiện các thay đổi và giai đoạn chúng cũng vậy, vậy tại sao không để nó cho đến thời gian cam kết?

Nếu các tệp được đặt ở giữa hai lần xác nhận và sau đó chúng được sửa đổi, điều gì xảy ra với Git? Có cần quan tâm về thay đổi nội dung khi nó được nêu và những gì nó trở thành kể từ đó?

Nó sẽ cho bạn thấy sự khác biệt giữa trạng thái hiện tại của repo và (lần thay đổi cuối cùng + thay đổi theo giai đoạn). Khi bạn thực hiện một số thay đổi mới, nó sẽ chỉ tính lại trạng thái (cam kết cuối cùng + thay đổi theo giai đoạn).

Nếu tôi tạo một tệp mới, tạo giai đoạn cho nó và sau đó muốn xóa nó, tại sao Git yêu cầu tôi sử dụng cờ "-f" và một tệp "git -rm.ext" đơn giản sẽ không hoạt động?

Bây giờ tôi đoán ở đây, nhưng có lẽ bởi vì thông tin được dàn dựng có thể quan trọng (nếu không bạn sẽ không xử lý nó), nhưng nó chưa được kiểm soát phiên bản (như một tệp bạn có thể xóa git -rm). Vì vậy, gitmuốn chắc chắn rằng bạn biết những gì bạn đang làm.