Khi nào một kiểm soát phiên bản cam kết quá lớn? [đóng cửa]

Tôi đã nghe thấy ở một số nơi "Đừng thực hiện các cam kết lớn" nhưng tôi chưa bao giờ thực sự hiểu cam kết "lớn" là gì. Có lớn không nếu bạn làm việc trên một loạt các tập tin ngay cả khi có liên quan? Có bao nhiêu phần của một dự án bạn nên làm việc cùng một lúc?

Đối với tôi, tôi gặp khó khăn khi cố gắng thực hiện "những cam kết nhỏ" vì tôi quên hoặc tạo ra thứ gì đó tạo ra thứ khác tạo ra thứ khác. Sau đó, bạn kết thúc với những thứ như thế này:

Thực hiện hàng đợi đi tùy chỉnh

Người máy
-Quảng tin mớiQuyue không gì khác hơn là SingleThreadExecutor
-sendMsg chặn cho đến khi tin nhắn được gửi và thêm chờ trong khi tin nhắn nhận được
gởi
Các cuộc gọi -adminExist được cập nhật (xem bộ điều khiển)
Các cuộc gọi được yêu thích để gửiMessage

Bộ điều khiển
-Trình tin mới Trường biểu thị thời gian chờ giữa các tin nhắn
-Bắt đầu các plugin dịch vụ được chuyển sang reloadPlugins
-adminExists chuyển từ Máy chủ vì quản trị viên Toàn cầu. Kiểm tra tại kênh,
máy chủ và cấp độ toàn cầu

quản trị viên
-Các phương thức mới getServer và getChannel có được quản trị viên đối tượng phù hợp
thuộc về

BotEvent
-toString () cũng hiển thị thêm và thêm1

Kênh
trường kênh được đổi tên thành tên
Lỗi đánh máy kết hợp trong kênh (int)

Người phục vụ
-Quản trị viên được chuyển sang Trình điều khiển

PluginExecutor
-Minor thử nghiệm thêm, sẽ được gỡ bỏ sau

Plugin JS
-Được cập nhật để thay đổi khung
-Repliated InstanceTracker.getContoder () với Controller.instance
-VLC nói chuyện ngay bây giờ trong tập tin riêng

Nhiều cập nhật và thay đổi dự án NB

---

Tập tin bị ảnh hưởng
Sửa đổi /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Sửa đổi /trunk/Quackbot-Core/dist/README.TXT
Sửa đổi /trunk/Quackbot-Core/nbproject/private/private.properies
Sửa đổi /trunk/Quackbot-Core/nbproject/private/private.xml
Sửa đổi /trunk/Quackbot-Core/src/Quackbot/Bot.java
Sửa đổi /trunk/Quackbot-Core/src/Quackbot/Controll.java
Sửa đổi /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Sửa đổi /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Sửa đổi /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Sửa đổi /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Sửa đổi /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Sửa đổi /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Sửa đổi /trunk/Quackbot-GUI/dist/README.TXT
Sửa đổi /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Sửa đổi /trunk/Quackbot-GUI/nbproject/private/private.properies
Sửa đổi /trunk/Quackbot-GUI/nbproject/private/private.xml
Sửa đổi /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Sửa đổi /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Xóa /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Sửa đổi /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Sửa đổi /trunk/Quackbot-Impl/dist/README.TXT
Sửa đổi /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Sửa đổi /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Sửa đổi /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Sửa đổi /trunk/Quackbot-Impl/lib/javarebel.stats
Thêm /trunk/Quackbot-Impl/lib/jrebel.info
Sửa đổi /trunk/Quackbot-Impl/nbproject/private/private.properies
Sửa đổi /trunk/Quackbot-Impl/nbproject/private/private.xml
Sửa đổi /trunk/Quackbot-Impl/nbproject/project.properies
Sửa đổi /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Thêm / trunk / Quackbot-Impl / plugin / CMDs / Toán tử / hostBan
Sửa đổi /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Sửa đổi /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlay.js
Sửa đổi /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Sửa đổi /trunk/Quackbot-Impl/plugins/listpers/onJoin.js
Sửa đổi /trunk/Quackbot-Impl/plugins/listpers/onQuit.js
Sửa đổi /trunk/Quackbot-Impl/plugins/testCase.js
Thêm /trunk/Quackbot-Impl/plugins/utils/whatsPlay.js
Sửa đổi /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Thêm / thân cây / Quackbot-Impl / vlc_http
Thêm /trunk/Quackbot-Impl/vlc_http/civerse.html
Sửa đổi /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Sửa đổi /trunk/Quackbot-Plugins/dist/README.TXT
Sửa đổi /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Sửa đổi /trunk/Quackbot-Plugins/nbproject/private/private.properies
Sửa đổi /trunk/Quackbot-Plugins/nbproject/private/private.xml
Sửa đổi /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Thêm / thân cây / Quackbot-Plugins / vlc_http
Thêm /trunk/global-lib/jrebel.jar

Phải ....

Vì vậy, cho câu hỏi:

• Một số yếu tố cho một cam kết trở nên quá lớn ( công cụ không rõ ràng ) là gì?
• Làm thế nào bạn có thể ngăn chặn những cam kết như vậy? Xin cho biết chi tiết
• Thế còn khi bạn ở giai đoạn nửa đầu phát triển khi mọi thứ đang diễn ra nhanh chóng thì sao? Những cam kết khổng lồ vẫn ổn chứ?

Đối với tôi, tôi gặp khó khăn khi cố gắng thực hiện "những cam kết nhỏ" vì tôi quên hoặc tạo ra thứ gì đó tạo ra thứ khác tạo ra thứ khác.

Đó là vấn đề. Có vẻ như bạn cần phải học cách chia nhỏ công việc của mình thành những phần nhỏ hơn, dễ quản lý hơn.

Vấn đề với các cam kết lớn là:

• Trong một dự án nhiều người, nhiều khả năng các cam kết của bạn sẽ gây ra xung đột cho các nhà phát triển khác giải quyết.
• Thật khó để mô tả chính xác những gì đã được thực hiện trong các thông điệp tường trình.
• Khó theo dõi thứ tự thay đổi đã được thực hiện, và do đó để hiểu nguyên nhân của vấn đề.
• Nó làm tăng khả năng mất rất nhiều công việc không được cam kết.

Đôi khi những cam kết lớn là không thể tránh khỏi; ví dụ: nếu bạn phải thay đổi một API chính. Nhưng đó không phải là bình thường. Và nếu bạn thấy mình trong tình huống này, có lẽ nên tạo một chi nhánh và thực hiện công việc của bạn ở đó ... với rất nhiều cam kết nhỏ ... và tái hòa nhập khi bạn kết thúc.

(Một trường hợp khác là khi bạn thực hiện nhập ban đầu, nhưng đó KHÔNG phải là vấn đề từ góc độ của các vấn đề được liệt kê ở trên.)

Nguyên tắc trách nhiệm duy nhất.

Mỗi cam kết kiểm soát nguồn chỉ nên phục vụ một mục đích. Nếu bạn phải đặt từ "và" hoặc "cũng" trong tóm tắt của mình, bạn cần tách nó ra.

Nó rất phổ biến để kết thúc với nhiều thay đổi không liên quan hoặc bán liên quan riêng biệt trong bản sao làm việc của bạn. Đây được gọi là "vấn đề sao chép làm việc rối" và thực sự rất khó tránh ngay cả đối với các nhà phát triển có kỷ luật. Tuy nhiên, cả Git và Mercurial đều cung cấp cho bạn các công cụ để giải quyết nó - git add -p hoặc chunk select và Mercurial Queues trong TortoiseHg .

Hãy tưởng tượng rằng khách hàng được yêu cầu thực hiện một thay đổi cụ thể - ví dụ: để thêm một quy tắc rằng một cái gì đó hoặc cái khác không thể được thực hiện trong vòng hai ngày kể từ ngày "bất cứ điều gì". Sau đó, sau khi bạn thực hiện thay đổi, họ thay đổi suy nghĩ. Bạn sẽ muốn quay trở lại cam kết của bạn. Nếu tất cả đều bị cuốn vào một số điều về việc thay đổi thứ tự các báo cáo không liên quan, thì cuộc sống của bạn là một sự khốn khổ.

Một mục công việc, một thay đổi. Một yêu cầu từ khách hàng, một thay đổi. Một điều bạn có thể thay đổi suy nghĩ của mình, một thay đổi. Đôi khi điều đó có nghĩa là nó là một dòng mã. Đôi khi nó là mười tệp khác nhau bao gồm cả lược đồ cơ sở dữ liệu. Tốt rồi.

Cam kết lớn là khi bạn có hàng tấn thay đổi mà thực sự không phải trong cùng một nhóm. Nếu tôi thay đổi logic của bộ điều khiển, thì mô hình kết nối cơ sở dữ liệu, sau đó một số misc. kịch bản, tôi không nên gói tất cả theo một cam kết.

Phòng ngừa đang thực hiện các cam kết theo những gì bạn đang hoàn thành. Trong ví dụ trên tôi sẽ cam kết sau logic điều khiển, sau khi cơ sở dữ liệu hoạt động và sau các tập lệnh. Đừng bỏ qua cam kết đơn giản vì bạn biết những gì đã thay đổi. Người khác sẽ nhìn lại thông điệp nhật ký cam kết "Thay đổi" của bạn và tự hỏi bạn đang hút thuốc gì.

Nhập khẩu ban đầu có lẽ là cam kết lớn nhất bạn nên có. Thiết lập hệ thống từ đầu? Chắc chắn có một vài cam kết lớn. Sau khi bạn đã san bằng nó mặc dù đã đến lúc giữ mọi thứ ngăn nắp.

Nếu bạn biết rằng bạn sẽ làm việc với một đoạn mã lớn trước đó, tôi sẽ khuyên bạn nên tạo một nhánh cho tính năng cụ thể của mình trong khi định kỳ kéo mã xuống từ dòng chính để đảm bảo mã của bạn không đồng bộ. Khi bạn hoàn thành công việc trên nhánh, hợp nhất tất cả các thay đổi của bạn trở lại tuyến chính. Bằng cách này, các thành viên khác trong nhóm sẽ không ngạc nhiên và / hoặc khó chịu khi họ thấy một cam kết lớn. Ngoài ra, có rất ít cơ hội phá vỡ mọi thứ. Tiếp tục thực hành để phá vỡ mọi thứ thành các cam kết nhỏ hơn. Với thời gian nó sẽ trở thành bản chất thứ hai.

Ví dụ này cho thấy một cam kết quá lớn.

Theo nguyên tắc thông thường, hãy mô tả sự thay đổi trong một câu hoặc một dòng văn bản. (Dựa trên quy tắc này, cam kết nên được chia thành 10-15 lần nhỏ hơn.) Nếu bạn không thể nhận xét đầy đủ một cam kết trong một dòng, thì nó đã quá lớn.

Để thực hành các cam kết nhỏ hơn, hãy ghi chú vào notepad của bạn (hoặc trong Notepad) về những gì bạn đã thay đổi hoặc thêm vào. Cam kết trước khi nó trở thành một danh sách dài hoặc trước khi bạn thực hiện thay đổi mã không liên quan đến những gì bạn đã có trong notepad.

Trong lĩnh vực của tôi (mô hình vật lý), tôi phát hiện ra một lỗi trong đầu ra ngày hôm nay không có trong kho lưu trữ từ 6 tháng trước. Khi điều này xảy ra, tôi sẽ thực hiện tìm kiếm nhị phân trên các bản sửa đổi:

1. Chạy mô hình từ 3 tháng trước
2. Nếu lỗi vẫn còn ở đầu ra, hãy chạy mô hình từ 4,5 tháng trước
3. ... lặp lại cho đến khi tôi tìm thấy cam kết mang lại sản lượng xấu

Khi lỗi được giới thiệu trong một cam kết quái dị, tôi phải ngồi với một chiếc lược có răng để tìm nguồn gốc của vấn đề. Nếu cam kết chạm vào một số lượng nhỏ tệp, việc theo dõi dòng mã giới thiệu sự cố sẽ ít gây đau đớn hơn.

Tôi khuyên bạn nên chia nhỏ vấn đề của mình thành một loạt các nhiệm vụ nhỏ hơn (lý tưởng nhất là đặt từng nhiệm vụ trong trình theo dõi lỗi). Thực hiện một cam kết khi bạn hoàn thành mỗi nhiệm vụ (và đóng lỗi / tính năng đó trong trình theo dõi lỗi của bạn).

Đó không phải là quy mô của cam kết thực sự quan trọng, đó là phạm vi của sự thay đổi sẽ quyết định cách thức các cam kết của bạn được tổ chức.

Bạn có thể, ví dụ thay đổi mỗi thể hiện của __macro1để __macro2trong một cơ sở mã lớn, làm thay đổi 200 file. 200 cam kết sẽ không lành mạnh trong trường hợp đó.

Những gì bạn muốn kết thúc là có thể kéo kho lưu trữ ở bất kỳ sửa đổi nào và có công việc xây dựng. Bạn đã thay đổi từ libfoođến libbar? Tôi hy vọng rằng thay đổi bao gồm cập nhật tập lệnh xây dựng và Makefiles của bạn (hoặc bất cứ điều gì có thể áp dụng).

Đôi khi, bạn có thể cần thực hiện một loạt các thay đổi thử nghiệm để thực hiện một điều, trong trường hợp đó, bạn phải xác định phạm vi nào quan trọng hơn với bạn nếu bạn cần hoàn nguyên sau. Có một người phụ thuộc vào người khác? Cam kết tất cả chúng cùng một lúc trong một lần sửa đổi. Mặt khác, trong trường hợp đó, tôi đề nghị một cam kết cho mỗi thay đổi. Bạn nên làm một cái gì đó như thế trong một chi nhánh khác, hoặc trong một repo khác nào.

Mặc dù có, bạn có quyền hoàn nguyên một tệp cho bản sửa đổi trước đó (do đó sao lưu một tệp ra khỏi một cam kết lớn hơn), làm như vậy thực sự làm hỏng các công cụ như chia đôi sau này trên đường và làm ô nhiễm lịch sử.

Nếu bạn dừng lại và nghĩ "Ok, các bài kiểm tra vượt qua, tôi nghĩ rằng điều này hoạt động .. nhưng nếu nó trở nên tồi tệ, tôi có thể dễ dàng sao lưu nó không?" .. cuối cùng bạn sẽ thực hiện các cam kết hợp lý.

Điều cần nắm bắt ở đây là "Lớn" trong bối cảnh này là về số lượng thay đổi rõ rệt không phải là kích thước vật lý của cam kết (mặc dù nhìn chung cả hai sẽ song hành với nhau).

Đó không phải là một câu hỏi về "không thực hiện các cam kết lớn" cũng như thực hiện các cam kết nhỏ - lý tưởng để thực hiện các thay đổi nhỏ chứa đựng.

Rõ ràng từ thay đổi rằng bạn đã có một loạt những điều có thể được cam kết riêng (và an toàn) và do đó, nó khá rõ ràng rằng nó quá lớn.

Lý do có thể là một vấn đề là vì cam kết cuối cùng của bạn là điểm tham chiếu của bạn cho những thay đổi bạn đang thực hiện và ví dụ: nếu bạn nhận được bit đầu tiên đúng và sau đó nhận được bit tiếp theo, bạn không có cách nào dễ dàng để đưa công việc của bạn trở lại điểm mà bạn bắt đầu mắc lỗi (BTDTGTTS).

Tất nhiên đôi khi các thay đổi chỉ là lớn - tái cấu trúc quy mô lớn - và như được đề xuất bởi những người khác, đây là nơi bạn cần phân nhánh, theo cách đó mặc dù cá nhân của bạn có thể phá vỡ mọi thứ mà chúng được tách ra khỏi thân phát triển chính để không phải là một vấn đề và bạn có thể tiếp tục cam kết sớm và thường xuyên.

Một điều nữa - nếu có thứ gì đó xuất hiện ở giữa công việc của bạn đòi hỏi sự chú ý ngay lập tức hơn, bạn cần thay đổi nó một cách riêng biệt (lý tưởng là trong một bộ thư mục hoàn toàn khác biệt) và cam kết riêng.

Thách thức thực sự trong tất cả những điều này không phải là cơ chế mà là suy nghĩ của nó - rằng một cam kết không chỉ là một bản sao lưu mà bạn tạo ra mỗi lúc mà là mỗi cam kết là một viên sỏi trên đường đi và không có gì sai cả của các cam kết nhỏ và việc trộn lẫn các thứ khác nhau lại với nhau trong một cam kết mob cũng tệ như một bit chức năng mơ hồ liên quan đến nhau trong một khối mã.

Ít nhất, hãy rèn luyện bản thân để cam kết bất cứ khi nào bạn nghĩ cho bản thân mình "Tôi thích sự tiến bộ của tôi cho đến nay và tôi không muốn đánh mất nó nếu những thay đổi tôi sắp thực hiện là một thảm họa." Sau đó, bạn có tùy chọn tận dụng VCS để thổi bay mọi ngõ cụt mà bạn đã thử hoặc mã gỡ lỗi đặc biệt mà bạn đã thêm để theo dõi một vấn đề. (ví dụ với git reset --hardhoặc rm -rf *; svn update)

Không có quy tắc cứng và nhanh, không có đường phân chia quá khứ mà cam kết của bạn quá lớn.

Có là tuy nhiên một phương châm rằng cam kết nhỏ hơn là tốt hơn, trong lý do (tức là cam kết mỗi dòng là probaby quá mức).

Tôi ghi nhớ các loại hướng dẫn này:

• Một cam kết duy nhất nên bao gồm các thay đổi cho chỉ một sửa lỗi
• Một cam kết không nên bao gồm hơn nửa ngày làm việc
• Một cam kết không nên phá vỡ bản dựng

Tất nhiên - đây là những gì tôi ghi nhớ - YMMV. Các nhà phát triển khác nhau ủng hộ mức độ chi tiết khác nhau.

Cam kết càng nhỏ thì càng dễ tìm thấy chính xác nơi hồi quy tiềm năng đến từ đâu.

Lý tưởng nhất là một cam kết phải là nguyên tử , theo nghĩa là sự thay đổi mạch lạc nhỏ nhất đối với cơ sở mã (liên quan đến một lỗi, tính năng, v.v.).

Đối với các mẹo cụ thể để giữ kích thước của cam kết nhỏ, nó phụ thuộc rất lớn vào VCS của bạn và cách thiết lập: bạn phải có thể cam kết cục bộ hoặc làm việc trong chi nhánh của mình trên máy chủ.

Chìa khóa là cam kết với chi nhánh "riêng tư" của bạn mỗi khi bạn thực hiện thay đổi nguyên tử, và sau đó bạn có thể hợp nhất thường xuyên chi nhánh của mình, ví dụ mỗi tuần.

Sử dụng một dvcs, quy trình làm việc của bạn có thể trông như thế:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

Sử dụng một vcs tập trung:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Bạn có thể đã nghe câu nói rằng sự hoàn hảo là khi bạn không thể lấy đi bất cứ thứ gì khác. Điều đó cũng nên mô tả tiêu chuẩn của bạn cho kích thước cam kết.

Nó phụ thuộc vào dự án của bạn nơi kích thước "hoàn hảo" đó. Nếu bạn đang vận chuyển cho khách hàng bên ngoài, kích thước tốt có thể là mức tăng nhỏ nhất mà bạn có thể thoải mái vận chuyển nếu bạn không hoàn thành đúng kế tiếp. Nếu bạn đang xây dựng các ứng dụng nội bộ, được triển khai thường xuyên, kích thước tốt nhất có thể là mức tăng nhỏ nhất không phá vỡ bất cứ thứ gì (và đưa bạn đến gần hơn với nơi bạn muốn).

Các hệ thống kiểm soát phiên bản hiện đại giúp bạn tạo ra các cam kết tốt với việc phân nhánh dễ dàng, nổi loạn tương tác, khu vực tổ chức, v.v.

Thông điệp cam kết chỉ là một dòng (và đối với git tối đa 60 ký tự). Số lượng mã được cam kết phải đủ nhỏ để giữ thông điệp mô tả trong giới hạn đó.

Tôi có xu hướng cam kết mọi lúc (thậm chí nhiều hơn vì vậy bây giờ chúng tôi đã chuyển sang git) Tôi đã hoàn thành một phần, vì nó cho phép nắm bắt "lý do" mọi thứ được thực hiện theo cách này.

Đôi khi bạn đã làm việc cả ngày với một số lỗi khác nhau về logic và bạn quên không thực hiện mã của mình ở giữa. Việc sử dụng git citoolcó thể rất hữu ích cho việc chia nhỏ công việc của bạn thành những miếng nhỏ có kích cỡ cắn vào cuối ngày, ngay cả khi bạn không cẩn thận trong ngày khi bạn đang làm việc.

git citool có thể cho phép bạn chọn những khối cụ thể của một tệp (hoặc dòng cụ thể nào) để cam kết trong một cam kết cụ thể, để bạn có thể chia nhỏ (không chồng chéo) các thay đổi được thực hiện cho cùng một tệp thành một số cam kết.

(Có vẻ như bạn sử dụng Subversion. Tôi không biết một công cụ thực hiện việc này cho Subversion, nhưng bạn có thể xem xét việc sử dụng git-svn, bộ chuyển đổi Subversion cho git, sẽ thay đổi cuộc sống của bạn.)

Cam kết càng lớn, bạn càng có khả năng phá vỡ công trình và được phần còn lại trong nhóm của bạn thanh toán. Tôi cố gắng thay đổi cam kết hai lần một ngày. Ngay trước bữa trưa và trước khi tôi về nhà. Vì vậy, @ 12pm và 4:30 pm tôi cố gắng làm mọi thứ hoạt động và sẵn sàng cam kết. Tôi thấy thực hành này làm việc cho tôi.

Để trả lời câu hỏi của bạn:

1) Đối với tôi, cam kết tiêu chuẩn được coi là lớn nếu nó làm nhiều hơn một việc. Tôi có nghĩa là sửa một lỗi hoặc thêm một tính năng.

2) Ngăn chặn những cam kết đó bằng cách biến nó thành thói quen và quy tắc để cam kết bất cứ khi nào bạn hoàn thành một việc gì đó.

3) Trong giai đoạn phát triển nửa đầu, tôi cho phép các cam kết bao gồm việc tạo các tệp đầu tiên sẽ được sử dụng sau này.

Tôi muốn lưu ý rằng khi kết thúc tôi có nghĩa là tất cả các lỗi bạn có thể xác định đã được sửa và bạn sẽ không phá vỡ bản dựng bằng cách cam kết.

Đúng, điều này tạo ra một số lượng lớn các cam kết, nhưng nó cho phép bạn khôi phục chính xác những gì đã phá vỡ thay vì phải quay lại một loạt thay đổi lớn đã được cam kết cùng lúc khi chỉ một trong những thay đổi gây ra sự cố.

Tôi cũng muốn chỉ ra rằng các quy tắc thay đổi một chút cho các hệ thống kiểm soát phiên bản phân tán (DVCS) như Mercurial và Git. Trong trường hợp bạn đang sử dụng một trong những thứ đó, bạn cam kết bất cứ khi nào bạn thực hiện thay đổi, nhưng chưa kiểm tra nó và sau đó bạn đẩy đến kho lưu trữ trung tâm khi nó hoạt động. Điều này là tốt hơn vì nó cho phép bạn sửa đổi nhiều thay đổi hơn cho mã của bạn mà không lo lắng về việc phá vỡ bản dựng.

Trong trường hợp của tôi, tôi đang cố gắng cam kết các tệp của máy chủ với hệ thống kho lưu trữ (SVN). Đây là cam kết ban đầu và không muốn tải xuống vì đây là một dự án thực sự lớn (vài GB) và tôi muốn thực hiện cam kết ban đầu khỏi máy chủ của khách hàng.

Vấn đề là máy khách đang ở trên một máy chủ dùng chung, máy khách svn bị giết (hoặc bất kỳ phần mềm nào khác) nếu nó chạy nhiều hơn một phút.

Một cách khác là tải xuống dự án trên máy tính của tôi và thực hiện cam kết ban đầu từ đó nhưng tôi muốn biết liệu có một tùy chọn nào trong SVN để phá vỡ cam kết lớn thành nhiều hơn, tương tự như các phương thức giao dịch.

Nhà phát triển trước tôi không bao giờ sử dụng một hệ thống kiểm soát phiên bản.

Công ty tôi làm việc để buộc một đánh giá mã ngang hàng cho mỗi cam kết. Do đó, bất kỳ cam kết nào gây khó khăn cho đồng nghiệp để tìm hiểu những gì đang diễn ra và xem xét trong một khoảng thời gian hợp lý, là quá lớn.