Trong kiểm soát phiên bản tập trung, có luôn cập nhật thường xuyên không?

Giả sử rằng:

• Nhóm của bạn đang sử dụng kiểm soát phiên bản tập trung.
• Bạn đang làm việc trên một tính năng lớn hơn sẽ mất vài ngày để hoàn thành và bạn sẽ không thể cam kết trước đó vì nó sẽ phá vỡ bản dựng.
• Các thành viên trong nhóm của bạn cam kết một điều gì đó mỗi ngày có thể thay đổi một số tệp bạn đang làm việc.

Vì đây là kiểm soát phiên bản tập trung, bạn sẽ phải cập nhật kiểm tra cục bộ của mình tại một số điểm: ít nhất một lần ngay trước khi thực hiện tính năng mới.

Nếu bạn chỉ cập nhật một lần ngay trước khi cam kết, thì có thể có rất nhiều xung đột do nhiều thay đổi khác của đồng đội, đó có thể là một thế giới đau đớn để giải quyết tất cả cùng một lúc.

Hoặc, bạn có thể cập nhật thường xuyên và ngay cả khi có một vài xung đột để giải quyết từng ngày, việc này sẽ dễ thực hiện hơn, từng chút một.

Bạn sẽ luôn luôn cập nhật thường xuyên chứ?

Cá nhân, tôi cập nhật các phiên bản địa phương của tôi hàng ngày.

Trong kịch bản bạn mô tả, tôi sẽ đi thêm một dặm nữa

• Tạo một nhánh cho tính năng mới, dài.
• Hợp nhất thường xuyên từ tuyến chính đến chi nhánh mới này.

Cách này,

• Bạn có thể đăng ký hàng ngày để giữ mã của mình trên máy chủ
• Bạn không phải lo lắng về việc phá vỡ bản dựng bằng cách đăng ký.
• Bạn có thể sử dụng kho lưu trữ để hoàn tác một số công việc hoặc khác biệt khi cần thiết với các đăng ký trước đó.
• Bạn chắc chắn đang làm việc trên cơ sở mã mới nhất và sớm phát hiện các thay đổi mã xung đột có thể xảy ra.

Những nhược điểm như tôi thấy chúng là

• Việc hợp nhất từ ​​chính phải được thực hiện thủ công (hoặc viết kịch bản)
• Phải mất nhiều "quản trị"

Vâng, đó là một ý tưởng tốt để cập nhật thường xuyên. Bạn cập nhật thường xuyên để tránh xung đột hợp nhất khó khăn và đây là kiến ​​thức cơ bản về kiến ​​thức Quản lý cấu hình phần mềm (SCM) với vấn đề thay đổi khác nhau.

Điều này là bất kể nếu nó được tập trung hoặc phân phối; thời gian bạn chuyển hướng từ nguồn ngược dòng càng lâu (nghĩa là nếu đó là một thân cây, nhánh hoặc kho lưu trữ khác trong trường hợp DVCS) thì khả năng xung đột hợp nhất càng cao. Vâng, những bất ngờ khó chịu từ nhóm của bạn có thể đến khi cập nhật, nhưng hoãn lại những bất ngờ khó chịu thậm chí còn tồi tệ hơn (bạn càng chờ lâu, mọi người càng nhớ tại sao một loạt thay đổi được thực hiện).

Để cập nhật để làm việc, điều này cũng có nghĩa là bạn và các lập trình viên khác làm việc với mã không bao giờ nên cố tình cam kết hoặc đẩy mã ngược dòng phá vỡ bản dựng . Đây thường là lý do tại sao các lập trình viên phân nhánh (hoặc phân kỳ từ thượng nguồn theo thuật ngữ SCM), để bảo vệ các thành viên trong nhóm của bạn và các bên liên quan khác khỏi bị hỏng mã nếu tình huống như vậy chắc chắn sẽ xảy ra.

Câu thần chú bạn có thể sử dụng để ghi nhớ là: "cập nhật, cập nhật, cập nhật, cam kết". Luôn đảm bảo các thay đổi của bạn hoạt động với người khác trước khi cam kết. Điều này cũng là để đảm bảo kiểm tra mã lần đầu tiên hoạt động tốt.

Điểm đạn thứ 3 trong câu hỏi đơn giản là sai :

• Bạn đang làm việc trên một tính năng mới chắc chắn sẽ mất vài ngày để hoàn thành và bạn sẽ không thể cam kết trước đó vì nó sẽ phá vỡ bản dựng.

Nếu bạn biết rằng bạn sẽ làm việc với một cái gì đó bạn không thể cam kết một thời gian, đó là ví dụ trong sách giáo khoa để sử dụng các nhánh.

Đừng đặt mình vào tình huống bạn có nhiều thay đổi đang chờ xử lý. Nếu bạn biết rằng bạn sẽ không thể cam kết trong chi nhánh chính của dự án trong một thời gian, thì hãy làm việc trên một chi nhánh khác. Và ở đó, cam kết thường xuyên .

Nếu bạn đã ở trong tình huống được mô tả trong câu hỏi, thì hãy chuyển sang một chi nhánh ngay bây giờ , cam kết thay đổi của bạn và tiếp tục làm việc trong chi nhánh đó.

Thông thường trong CVCS, nên cập nhật thường xuyên. Nhưng nếu bạn đang làm việc trên một chi nhánh thì câu hỏi "cập nhật thường xuyên hay không" trở thành "hợp nhất thường xuyên hay không". Và câu trả lời là có. Chỉ cần đảm bảo cam kết tất cả các thay đổi đang chờ xử lý (trong chi nhánh) trước khi hợp nhất từ ​​một chi nhánh khác, để tùy chọn của bạn quay lại hợp nhất một cách an toàn nếu bạn phải.

Tôi nghĩ bạn nên cam kết thường xuyên hơn. Nếu bạn sẽ làm việc trong một thời gian dài như vài ngày, bạn nên phân nhánh mã và làm việc trong chi nhánh của mình thay vì làm việc trực tiếp trong thân cây. Tôi biết thật tiện lợi khi bắt đầu làm việc mà không cần chi nhánh, nhưng nó không thực sự linh hoạt vì bạn không thể chắc chắn rằng bản cập nhật / cam kết của mình có phá vỡ mã của bạn hay không, điều này dẫn đến tình huống bạn sẽ giữ bản cập nhật / cam kết cho đến khi bạn hoàn thành công việc của bạn "Phân nhánh tính năng" tốt hơn theo cách bạn luôn có thể cam kết mã của mình và chỉ cần hợp nhất trở lại sau khi bạn hoàn thành.

Trong chiến lược phân nhánh, bản cập nhật được thay thế bằng việc hợp nhất từ ​​thân cây. Theo kinh nghiệm của tôi, bạn không cần phải hợp nhất từ ​​thân cây thường xuyên, vì mã trong khoảng thời gian như năm ngày sẽ không thay đổi nhiều và chỉ dễ dàng giải quyết xung đột một lần khi bạn kết thúc.

Tôi thực sự thấy thuận tiện hơn khi sử dụng điều khiển phiên bản phân tán cục bộ. Đó là, tôi sử dụng git như máy khách lật đổ. Điều này có những ưu điểm:

• Các thay đổi cục bộ được lưu trước khi cập nhật, vì vậy nếu tôi mắc lỗi trong hợp nhất, tôi luôn có thể quay lại và thực hiện lại.
• Khi thực hiện các thay đổi lớn hơn, tôi có thể lưu các phần đã hoàn thành. Điều đó giúp dễ dàng hơn để xem xét các thay đổi còn lại trong tiến trình.
• Khi tôi sửa một lỗi trong một số công việc lớn hơn, tôi có thể cam kết sửa lỗi đó, tạm thời khắc phục phần còn lại và "sửa lỗi" để sửa lỗi trong khi giữ cho công việc khác đang diễn ra cục bộ.

Nếu bạn đang thêm một tính năng mới, bạn có thể tạo một tệp nguồn đơn mới (và một tệp tiêu đề giao diện bên ngoài phù hợp) không?

Tôi lo ngại rằng một "tính năng mới" đang có ý nghĩa rộng rãi? Định hướng đối tượng có thể không còn là từ thông dụng trước đây nữa, nhưng có công trong mô hình đó.

Bằng cách đó, bạn có thể tạo khung (giao diện bên ngoài, cộng với các chức năng còn sơ khai) và cam kết rằng sau đó sẽ có các hiệu ứng bên thứ ba tối thiểu, trong khi bạn hoàn thành phần còn lại của sự phát triển?

Trong tình huống bạn mô tả tôi cảm thấy tốt hơn là có nhiều tệp nguồn nhỏ hơn ít hơn, các tệp lớn hơn.

Nó khác với điều khiển phiên bản tập trung như thế nào so với điều khiển phân phối?

Trong cả hai trường hợp, bạn sẽ phải đăng ký ở một nơi có nội dung sẽ được di chuyển so với những gì bạn đã bắt đầu. Tôi không thấy bất kỳ sự khác biệt nào về tần suất hợp nhất từ ​​kho lưu trữ trung tâm đến nơi làm việc của bạn (và chi nhánh dự án của bạn là nơi làm việc của bạn).

Tôi có xu hướng hợp nhất thường xuyên (ít nhất một lần một ngày, tôi cũng có thể hợp nhất vào một số thời điểm thuận tiện khác cho tôi hoặc khi tôi biết ai đó đã kiểm tra thứ gì đó ảnh hưởng đến những gì tôi đang làm). Việc tiếp thu những thay đổi nhỏ dễ dàng hơn nhiều và nếu bạn gặp vấn đề, mọi người sẽ hữu ích hơn khi bạn hỏi họ về những gì họ vừa kiểm tra so với những gì họ đã kiểm tra trong một tuần trước.

BTW, tôi không biết bạn gọi "phá vỡ công trình" là gì. Tôi có xu hướng làm việc với mức tăng tương đối nhỏ, để tôi giữ trạng thái có thể biên dịch được, ngay cả khi nó phá vỡ một số tính năng. Và tôi chạy thử nghiệm để tôi biết rằng sự hợp nhất đã không phá vỡ thứ gì đó nên hoạt động. Một lần nữa, nó dễ dàng hơn để khắc phục một vấn đề khi nó được phát hiện sớm.

Nó phụ thuộc vào mức độ bạn "tuyệt vời" khi người khác phá vỡ công trình. Một mặt, bạn muốn cập nhật thành từng phần nhỏ nhất có thể. Cá nhân, tôi cập nhật hầu như mỗi khi tôi nhận thấy cập nhật có sẵn. Mặt khác, nếu bản dựng bị hỏng và sẽ mất một ngày để người khác sửa nó, bạn vẫn muốn có thể làm việc trên tính năng mới của mình trong thời gian đó.

Tôi đã làm việc với các hệ thống kiểm soát phiên bản rất khó sao lưu sau khi cập nhật xong. Về những điều đó, tôi có xu hướng chỉ cập nhật ngay trước khi tôi cần đăng nhập. Với các hệ thống kiểm soát phiên bản tốt hơn, có rất ít lý do để không cập nhật nhiều lần mỗi ngày.