Tôi nên làm gì khi tôi đã chờ đợi quá lâu giữa các lần xác nhận?

100

Tôi đã nghịch ngợm ... Quá nhiều "mã hóa cao bồi", không đủ cam kết. Bây giờ, ở đây tôi với một cam kết rất lớn. Vâng, tôi đáng lẽ phải cam kết tất cả cùng, nhưng bây giờ đã quá muộn.

Cái gì tốt hơn

Thực hiện một cam kết rất lớn liệt kê tất cả những điều tôi đã thay đổi
Cố gắng chia nó thành các cam kết nhỏ hơn có khả năng sẽ không biên dịch, vì các tệp có nhiều sửa lỗi, thay đổi, tên phương thức bổ sung, v.v.
Cố gắng thực hiện đảo ngược một phần các tệp chỉ để xác nhận phù hợp, sau đó đặt lại các thay đổi mới.

Lưu ý: tính đến thời điểm hiện tại tôi là lập trình viên duy nhất làm việc trong dự án này; người duy nhất sẽ xem xét bất kỳ ý kiến cam kết nào trong số này là tôi, ít nhất là cho đến khi chúng tôi thuê thêm lập trình viên.

Nhân tiện: Tôi đang sử dụng SVN và Subclipse. Tôi đã tạo một chi nhánh mới trước khi thực hiện bất kỳ thay đổi nào trong số này.

Thông tin thêm : Tôi đã hỏi một câu hỏi riêng liên quan đến cách tôi gặp tình huống này ngay từ đầu: Cách chuẩn bị viết lại keo của ứng dụng

— Durron597
nguồn

2

Bạn đang sử dụng chương trình kiểm soát phiên bản nào? Nhiều người có các mô-đun cho phép bạn chia nhỏ các chỉnh sửa của mình trong "hunk", tức là các nhóm dòng được sửa đổi, cho phép bạn nhóm các chỉnh sửa của mình theo bất kỳ cách nào bạn muốn và phân phối các mod của một tệp cho một số thay đổi. Ví dụ, mercurial có phần mở rộng "kệ". Tất nhiên bạn vẫn nên kiểm tra xem mỗi lô thay đổi có được biên dịch hay không, nếu điều đó quan trọng với quy trình của bạn. Cho dù đó là tất cả giá trị rắc rối là tùy thuộc vào bạn và cửa hàng của bạn.

— alexis

6

Ít nhất hãy kiểm tra nó trên chi nhánh, vì vậy bạn không mất các thay đổi của mình.

— Rory Hunter

2

Bạn có thể tiếp tục tự đặt câu hỏi và chờ đợi lâu hơn, hoặc thực sự cam kết và đối phó với bất kỳ mớ hỗn độn nào tạo ra ... Và sau đó ... đừng làm lại!

— haylem

40

# 1, cầu nguyện cho sự tha thứ, và sau đó đi ra ngoài và không phạm tội nữa :)

— Peteris

5

Câu hỏi quan trọng hơn bạn nên tự hỏi mình là: "làm thế nào để tôi thay đổi thói quen xấu của mình để ngăn chặn điều này xảy ra lần nữa". Không nên có lý do để cam kết không ít nhất một lần một ngày, tốt hơn thường xuyên hơn.

— Doc Brown

52

Để trả lời, bạn phải tự hỏi làm thế nào bạn mong đợi sử dụng kết quả của những cam kết này trong tương lai. Những lý do phổ biến nhất là:

Để xem những gì phát hành một lỗi đã được giới thiệu.
Để xem tại sao một dòng mã nhất định có mặt.
Để hợp nhất vào một chi nhánh khác.
Để có thể kiểm tra phiên bản trước để khắc phục sự cố mà khách hàng hoặc người kiểm tra đang thấy trong phiên bản đó.
Để có thể bao gồm hoặc loại trừ một số phần nhất định từ một bản phát hành.

Hai lý do đầu tiên có thể được phục vụ tốt với một lần đăng ký lớn, giả sử bạn có thể tạo một thông báo đăng ký áp dụng tốt như nhau cho từng dòng mã thay đổi. Nếu bạn là lập trình viên duy nhất, thì các cam kết nhỏ hơn sẽ không giúp việc hợp nhất của bạn trở nên dễ dàng hơn. Nếu bạn không có kế hoạch thực hiện một bản phát hành hoặc thử nghiệm chỉ với một phần của các thay đổi không được chấp nhận, thì hai lý do cuối cùng không được áp dụng.

Có những lý do khác để thực hiện các cam kết nhỏ, nhưng chúng là trong khi bạn đang ở giữa các thay đổi, và thời gian đã qua. Những lý do đó làm cho việc chống lại một sai lầm hoặc thay đổi thử nghiệm trở nên dễ dàng hơn và giúp dễ dàng tiếp tục đồng bộ hóa với các đồng nghiệp mà không có sự hợp nhất đáng sợ.

Từ sự hiểu biết của tôi về tình huống của bạn như bạn đã mô tả, có vẻ như không có ích gì để chia tách cam kết của bạn tại thời điểm này.

— Karl Bielefeldt
nguồn

Câu trả lời tuyệt vời! Mặc dù tôi không cảm thấy hối tiếc về việc không thực hiện các cam kết nhỏ, tôi cảm thấy tốt hơn rất nhiều về những gì tôi nên làm để lấy lại hành vi tốt một cách hiệu quả nhất có thể.

— durron597

1

Một điều khác về 3 và 5 là bất kỳ công việc nào bạn làm bây giờ để cho phép chúng xảy ra, bạn có thể đợi cho đến khi bạn thực sự cần nó và sau đó làm công việc tương tự. Nó có thể sẽ khó hơn một chút trong tương lai vì trí nhớ của bạn về những gì bạn đã làm đã biến mất. Nhưng một lần nữa, có lẽ bạn sẽ không bao giờ cần nó.

— Steve Jessop

Theo kinh nghiệm của tôi, thật rắc rối và mong manh khi dựa vào các bình luận kiểm soát phiên bản để kể một câu chuyện tại sao mã lại ở đó (tức là lý do 1 và 2). Nếu bạn đang sử dụng SVN với một chi nhánh, dù sao thì lịch sử cam kết sẽ bị mất khi hợp nhất (bạn sẽ tốt hơn với những thứ hiện đại hơn như git). Vì vậy, đó là IMHO phục vụ tốt nhất với ý kiến.

— Hans-Peter Störr

1

@hstoerr - nếu bạn đang sử dụng Subversion 1.5 trở lên, bạn có thể lưu lại lịch sử với tùy chọn --reintegrate khi hợp nhất.

— Dustin Kendall

1

git add -p là người bạn tốt nhất của bạn ở đây. Tôi đã yêu tính năng đó. Bằng cách này, tôi có thể cam kết sửa đổi tiêu chuẩn mã hóa của mình trong các cam kết riêng biệt và giữ cho các thay đổi mã có liên quan được tách biệt.

— Spidey

39

Tôi nghĩ bất cứ điều gì bạn làm, hãy cố gắng tránh việc kiểm tra trong mã mà bạn biết sẽ không biên dịch.

Nếu bạn nghĩ rằng tùy chọn thứ ba của bạn là khả thi, đó có thể là một cách tốt để làm điều đó, miễn là bạn có thể đảm bảo rằng chuỗi cam kết của bạn sẽ không tạo ra một hệ thống không thể hoàn thành. Nếu không, chỉ cần làm một cam kết lớn. Nó xấu, nhưng nó đơn giản, nhanh chóng và hoàn thành nó. Đi về phía trước, cam kết thường xuyên hơn .

— Thất vọngWithFormsDesigner
nguồn

Tùy chọn ba là có thể nhưng nó sẽ cực kỳ tốn thời gian. Tôi nghĩ rằng tôi sẽ thực hiện tùy chọn 1

— durron597

3

Nhược điểm của việc cam kết mã sẽ không biên dịch hoặc xây dựng trong một nhánh tính năng (hoặc tương tự) khủng khiếp đến mức bắt buộc ai đó tránh làm như vậy "bất cứ điều gì họ làm"? Tôi tưởng tượng rằng bất kỳ cam kết thực sự khủng khiếp nào cũng có thể tránh được bởi những người khác, đó là lý do thực sự duy nhất tại sao tôi tránh chúng ngay từ đầu (tất nhiên, giả sử rằng các cam kết không được phát hành ).

— Kenny Evitt

3

Các "tránh việc kiểm tra trong mã đó sẽ không biên dịch" chỉ áp dụng cho một chia sẻ mã cơ sở / chi nhánh. Trong một dự án một người hoặc một chi nhánh phát triển một người, tôi khẳng định điều quan trọng hơn là chỉ cần thay đổi của bạn thành VC để bạn không bị mất đồ.

— Stephen C

3

@StephenC chẳng hạn vì nó phá vỡ các công cụ như git-bisect. Nếu mã biên dịch / chạy mọi lúc và bạn cần tìm hồi quy nếu nó biên dịch mọi lúc bạn chỉ có thể tìm kiếm nhị phân (không đề cập đến việc nếu có hồi quy trong đoạn mã bạn sẽ có thay đổi lớn để đọc thay vì thu hẹp nó xuống).

— Maciej Piechotka

@MaciejPiechotka - Chà, rõ ràng nếu bạn cần sử dụng các công cụ cụ thể trên các nhánh riêng của mình và họ yêu cầu mã đó có thể biên dịch được, thì hãy làm như vậy. Nhưng đó không phải là điển hình cho một dự án / chi nhánh một người.

— Stephen C

19

Lý do quan trọng nhất để thực hiện các cam kết thường xuyên, nhỏ và có ý nghĩa là để hỗ trợ sự hiểu biết về lịch sử của mã. Cụ thể, rất khó để hiểu mã đã thay đổi như thế nào nếu khó tạo ra các khác biệt dễ hiểu.

Tùy chọn 1 làm xáo trộn lịch sử các thay đổi bạn đã thực hiện, nhưng nếu không, nó sẽ không gây ra bất kỳ vấn đề nào.

Tùy chọn 2 làm xáo trộn lịch sử các thay đổi bạn đã thực hiện, có thể ít hơn so với tùy chọn 1, nhưng nó có thể gây ra các vấn đề khác cho chính bạn hoặc người khác nếu họ giả định hoặc kết luận rằng các cam kết là khác biệt, ví dụ có thể được sáp nhập vào các chi nhánh khác một cách độc lập. Trừ khi có một lý do thực tế mạnh mẽ tại sao điều này được ưa thích hơn tùy chọn 1, điều này ít lý tưởng hơn nó.

Tùy chọn 3 là tốt nhất, tất cả những thứ khác đều bằng nhau, nhưng nếu, như bạn đã mô tả ở nơi khác, làm như vậy sẽ đòi hỏi lượng thời gian "cực kỳ" hoặc sẽ phải chịu các chi phí đáng kể khác, bạn sẽ phải cân nhắc các chi phí đó với lợi ích dự kiến của tạo ra các cam kết sạch hơn.

Dựa trên thông tin bạn đã cung cấp, tôi sẽ chọn tùy chọn 1. Có lẽ bạn nên thiết lập lời nhắc nhắc bạn thực hiện các thay đổi của mình?

Tạo mẫu và viết lại

Một lưu ý khác cần lưu ý, đặc biệt là lưu ý đến việc bạn là lập trình viên duy nhất và tôi nghi ngờ rằng bạn đang làm việc trên một cơ sở mã tương đối mới, đó là có lẽ tốt để phát triển các thói quen khác nhau khi thực hiện các thay đổi khi bạn thay đổi đang tạo mẫu mã mới so với việc duy trì hoặc mở rộng mã hiện có. Có lẽ không có sự phân chia sắc nét khủng khiếp giữa hai người, nhưng tôi nghĩ đó vẫn là một sự khác biệt hữu ích.

Khi bạn đang tạo mẫu mã mới, hãy cam kết bất cứ khi nào bạn muốn lưu các thay đổi của mình, gần như chắc chắn trong một chi nhánh, nhưng có lẽ trong một dự án riêng biệt. Hoặc thậm chí có thể chỉ hoạt động bên ngoài kiểm soát phiên bản hoàn toàn. Thay vào đó, bạn có thể tập trung vào việc thu thập bằng chứng về tính khả thi của các giả thuyết hoặc thiết kế khác nhau mà bạn đang xem xét. Tôi thường viết các nguyên mẫu nhỏ bằng các công cụ khác nhau, ví dụ LINQPad thay vì Visual Studio cho mã C #.

Khi bạn xác nhận một giả thuyết hoặc thiết kế cụ thể, hãy viết lại nó trong dự án chính của bạn, lý tưởng nhất là trong một chi nhánh và đưa ra những cam kết nhỏ, có ý nghĩa sẽ hỗ trợ tốt nhất cho sự hiểu biết của người khác (bao gồm cả bạn trong tương lai) về bản chất của những thay đổi bạn đang làm

— Kenny Evitt
nguồn

1

Câu trả lời tốt; Kenny bạn có một bài viết hay cơ sở kiến thức khác để liên kết với các chi tiết cụ thể hơn về tạo mẫu không? Phiên bản tạo mẫu của tôi là "phác thảo trong sổ ghi chép hoặc trên bảng trắng"

— durron597

@ durron597, tôi không thể nghĩ ra bất kỳ liên kết nào (thậm chí để tìm kiếm) ngoài đỉnh đầu của tôi. Tôi đã chơi xung quanh với đủ các ngôn ngữ lập trình được giải thích (và được biên dịch động) mà tôi thậm chí không nghĩ rằng ý tưởng 'tạo mẫu' có thể là tiểu thuyết! Và tôi đã viết lại rất nhiều chương trình C, C ++ và Java (hết lần này đến lần khác) mà tôi không nghĩ rằng điều đó cũng không phổ biến, hoặc ít nhất là tiểu thuyết đối với một số người.

— Kenny Evitt

12

Mặc dù câu trả lời hợp lý duy nhất là không bao giờ phá vỡ thân cây , nhưng đôi khi điều đó là không thể. Ví dụ: svn có thể phá vỡ cam kết nếu bạn cam kết quá nhiều (có thể là một tùy chọn hoặc một tính năng, tôi không chắc chắn). Trong trường hợp đặc biệt như vậy, chỉ cần kiểm tra trong miếng. Vì bạn là một lập trình viên duy nhất, nó sẽ không làm phiền bất cứ ai.

Do đó, tôi sẽ chọn tùy chọn 1. Nếu không thể, thì tùy chọn 2.

Tùy chọn 3 đòi hỏi nhiều nỗ lực và đơn giản là nó không xứng đáng.

— Bовић
nguồn

1

hoặc gắn thẻ các phiên bản không biên dịch là "KHÔNG TẠO MÁY TÍNH"

— ratchet freak

2

@ratchetfreak: Tôi đoán một "thẻ" trong SVN sẽ không giúp được gì nhiều, vì các thẻ không hoạt động như "nhận xét" trên thân cây.

— Doc Brown

@DocBrown Tôi có nghĩa là thêm nó vào thông điệp cam kết

— ratchet freak

5

@ratchetfreak Tôi sẽ thực hiện dưới dạng "PHẦN X / N: kiểm tra ABC

— MÁY TÍNH DOESNT

Phương án 3 không đòi hỏi nhiều nỗ lực. Một câu trả lời khác giải thích làm thế nào để làm điều đó một cách nhanh chóng và dễ dàng sử dụng git add --patchvà git stash. Tình hình chỉ có vẻ khó khăn vì các công cụ và kiến thức kiểm soát nguồn lỗi thời.

— Ron MacNeil

7

Cố gắng chia nó thành các cam kết nhỏ hơn có khả năng sẽ không biên dịch, vì các tệp có nhiều sửa lỗi, thay đổi, tên phương thức bổ sung, v.v.

Khi tôi thấy mình trong một tình huống tương tự, tôi đã sử dụng kỹ thuật sau:

Chỉ thêm mã có liên quan đến một tính năng cụ thể: git add --patch
Stash tất cả các thay đổi khác: git stash save --keep-index
Chạy thử nghiệm / thử biên dịch
Cam kết thay đổi nếu mọi thứ đều ổn, nếu không đi đến 1

Tôi không quen thuộc với SVN, vì vậy tôi không biết liệu điều này có phù hợp với tình huống cụ thể của bạn không, nhưng cơ sở nên giống nhau - cô lập các phần nhỏ của mã và kiểm tra chúng riêng lẻ.

— Milos
nguồn

Tôi thích điều này nhưng không may là một trong nhiều điều trong danh sách việc cần làm của tôi (có rất nhiều khi bạn là người công nghệ duy nhất trong công ty) là chuyển từ SVN sang git, và tôi vẫn chưa tìm được nó .

— durron597

1

Vì tôi không đủ để sử dụng --patch, tôi sử dụng Hoàn tác trong nhiều trình soạn thảo khác nhau, để đến các trạng thái làm việc trước đó và cam kết chúng. Sau đó, tôi làm lại cho các cam kết tiếp theo. Do sự cám dỗ để thực hiện các bổ sung nhỏ cho mã khi ở trạng thái Hoàn tác, tôi luôn tạo bản sao lưu trước khi bắt đầu quá trình này!

— joeytwiddle

Với git, bạn cũng có thể thêm tương tác (thêm -i) trước khi xác nhận và phân nhánh sau đó để xác thực các cam kết của bạn một cách độc lập.

— riezebosch

3

Làm thế nào về tùy chọn 4: Sao lưu trạng thái hiện tại của repo của bạn ở một nơi tạm thời, hoàn nguyên repo của bạn về trạng thái ban đầu, lập danh sách tất cả các thay đổi bạn đã làm (bạn vẫn có thể xem bản sao lưu tạm thời), sau đó thực hiện lại thủ công (và biên dịch và kiểm tra!) chúng như các cam kết riêng biệt.

Điều này sẽ dễ dàng hơn, vì bạn đã viết mã, chỉ là một chút để tìm ra phần nào cần sao chép và dán từ bản sao lưu tạm thời của bạn.

Khi bạn đã thực hiện lại mọi thay đổi một cách sạch sẽ và do đó đảm bảo rằng các cam kết là khép kín, nhỏ và biên dịch, bạn có thể xóa bản sao lưu tạm thời và mọi thứ sẽ gần như chính xác (ngoại trừ thời gian / ngày cam kết) sẽ là nếu bạn làm điều đó ngay từ đầu.

— Tuyệt vời nhất
nguồn

Đây chỉ là một cách làm tùy chọn # 3. Có lẽ là cách tốt nhất, đúng, nhưng vẫn còn khá tốn thời gian.

— durron597

Có 149 dòng Thêm / Xóa / Gửi tin nhắn khi tôi thực hiện một cam kết lớn. Đó là ít nhất nửa ngày để làm điều này.

— durron597

@ durron597 Tôi không đồng ý, tôi nghĩ điều này khác với # 3. Về 149 dòng, bạn đánh giá bao nhiêu về lịch sử cam kết sạch? Có đáng để dành nửa ngày vào? Dù sao, nó không giống như các phương thức khác sẽ không yêu cầu tìm ra dòng nào nên được cam kết, vì vậy bạn sẽ phải trải qua 149 dòng. Sự khác biệt về thời gian sẽ nhỏ.

— Tuyệt vời nhất

Heh. Tôi đủ kinh nghiệm để biết sử dụng kiểm soát phiên bản, nhưng chưa đủ kinh nghiệm để từng cứu nó :) Vì vậy, lý do thực tế để thực hiện mọi thứ vẫn còn hơi hàn lâm, nếu bạn hiểu ý tôi.

— durron597

Bạn không cần phải sao lưu toàn bộ repo của mình . Bạn có thể thực hiện một cam kết "sao lưu", sau đó quay lại TRƯỚC với git reset HEAD~. Cam kết của bạn sẽ vẫn còn git reflognếu bạn quyết định bạn cần nó sau này. Bạn thậm chí có thể tách một nhánh (và sau đó chuyển trở lại nhánh hoạt động) trước khi thực hiện đặt lại, để đặt tên "sao lưu" của bạn. Xóa chi nhánh sau nếu bạn không cần nó. Chỉnh sửa: Xin lỗi đã không nhận ra OP là trên svn!

— joeytwiddle

3

Bạn là lập trình viên duy nhất; chỉ cần làm một checkin lớn chi tiết các bit quan trọng của những gì bạn đã làm.

Bạn có khả năng quay lại "các phần" của những gì bạn đã làm không? Nếu không, sau đó hoàn toàn tiến hành với tùy chọn 1.

Có một vài lý do để kiểm tra mã vào hệ thống kiểm soát phiên bản. Và TẤT CẢ chúng, khi bạn là nhà phát triển duy nhất, xoay quanh vấn đề an toàn - cụ thể là, nếu bạn làm hỏng, máy chết hoặc bất cứ điều gì, bạn luôn có thể quay lại điểm kiểm tra cuối cùng đó.

Một lập trình viên tham gia vào dự án sau này dường như không muốn quay lại phiên bản không biên dịch. Vì vậy, IMHO, tùy chọn 2 là sự mất trí.

Tùy chọn 3 nghe có vẻ như là một khoảng thời gian như vậy, rằng nếu tôi là sếp của bạn và thấy bạn lãng phí hàng giờ để làm điều này, tôi sẽ nói chuyện với bạn về thời gian của bạn có giá trị.

Để lặp lại: bằng cách kiểm tra mã của bạn, bạn đang che / lưu mông của bạn trong trường hợp thất bại trên máy của bạn. Mọi thứ khác, trong đội một người, là thay đồ cửa sổ.

— Không phải tôi
nguồn

1

Quay trở lại không phải là lý do duy nhất để sử dụng các cam kết nhỏ. Nó thậm chí không phải là một lý do đặc biệt tốt. Lý do chính là để có thể biết khi nào và tại sao một thay đổi được đưa ra và để tạo điều kiện khắc phục sự cố khi bạn gặp phải vấn đề không rõ nguồn gốc. Một lập trình viên khác tham gia vào dự án sau này gần như chắc chắn sẽ thỉnh thoảng gặp phải các dòng mã khiến anh ta đi "WTF" và tham khảo lại cam kết nơi nó được viết lần đầu hoặc sửa đổi lần cuối. Nếu cam kết đó là một cam kết khổng lồ thay đổi 500 điều, thì không thể có được bất kỳ thông tin hữu ích nào từ lịch sử.

— Aaronaught

Ngẫu nhiên, đây là lý do tại sao các đội sử dụng Git thường ghét các cam kết hợp nhất và yêu cầu / yêu cầu nổi loạn thay thế; hợp nhất cam kết phá vỡ bisectvà các kỹ thuật khác thường được sử dụng để cô lập các vấn đề, bởi vì rất nhiều thay đổi được nhồi vào một cam kết lớn.

— Aaronaught

1

Ở cấp độ cá nhân, tôi đồng ý rằng bạn không nên thực hiện các cam kết lớn trừ khi bạn hoàn toàn thay đổi cơ sở mã .. tại thời điểm nào bạn nên phân nhánh nó. Tuy nhiên, chúng ta đang nói về một lập trình viên duy nhất đang làm việc về cơ bản bị ngắt kết nối và hiện đang cố gắng quay lại làm việc đúng. Trong trường hợp đó tôi tin rằng một cam kết lớn là thích hợp hơn.

— NotMe

1

@Aaronaught Tôi muốn nói thêm rằng chính bạn 3 tháng sau có thể tạo thành một 'lập trình viên khác'.

— Maciej Piechotka

1

Tôi cũng không đồng ý với việc phân nhánh như một chiến lược khả thi cho những thay đổi kiến trúc hoặc những thay đổi "phá hoại" khác. Điều đó chỉ dẫn đến một cơn ác mộng của xung đột hợp nhất và lỗi sau hợp nhất. Về lâu dài, rất ít đau đớn để tìm ra cách phá vỡ sự thay đổi lớn thành những thay đổi nhỏ hơn, tương thích ngược hoặc trong trường hợp xấu nhất, sử dụng cái mà Fowler, Humble và những người còn lại gọi là Branch Bằng cách trừu tượng hóa (mà thực sự không phải là một nhánh). Cả hai chiến lược này đều ngụ ý các cam kết nhỏ và tập trung.

— Aaronaught

2

Quy tắc của tôi là: Không đăng ký mà không xem xét mã nghiêm trọng. Nếu tôi tự mình làm, tôi sẽ phải tự xem lại mã, nhưng nó sẽ được xem xét. Dường như bạn có một số thay đổi mã mà người khác không thể xem xét, do đó bạn không thể tự xem lại mã đó (xem lại mã của bạn khó hơn và đòi hỏi nhiều kỷ luật hơn, vì bạn tự động đưa ra giả định sai rằng mã của bạn là chính xác ).

Quy tắc hoàn toàn không thể phá vỡ của mọi người là: Không bao giờ kiểm tra mã thậm chí không xây dựng và nghiêm túc tránh kiểm tra mã không hoạt động.

Giải pháp: Sao chép mã đã thay đổi của bạn, quay lại điểm ban đầu. Hợp nhất một thay đổi tại một thời điểm vào mã gốc, xem xét nó, kiểm tra nó, kiểm tra nó. Với phương pháp lập trình mà bạn mô tả, bạn buộc phải tìm một số lỗi nghiêm trọng theo cách đó.

Đó cũng là một cách tốt để rèn luyện cho bạn thói quen lập trình tốt.

— gnasher729
nguồn

Đây là logic tương tự như câu trả lời dựa trên Git ở trên ( git add --patchvà git stash) và một ví dụ điển hình về kịch bản mà các DVCS hiện đại có thể xử lý dễ dàng nhưng các hệ thống cũ hơn thì không thể.

— Ron MacNeil

1

Tôi nghĩ rằng bạn đang lo lắng quá nhiều. Nếu bạn là lập trình viên duy nhất và bạn không có bảng thông số cụ thể để làm việc thì điều đó hoàn toàn phụ thuộc vào bạn làm gì. Tôi cho rằng không ai sẽ trừng phạt bạn vì đã thực hiện một cam kết lớn vì vậy vấn đề duy nhất bạn sẽ gặp phải là về công nghệ, chẳng hạn như không thể khôi phục các thay đổi tệp riêng lẻ trong cam kết. Vì bạn chỉ kiểm soát repo tại thời điểm này dù vậy cũng không phải là một mối quan tâm lớn.

Có một ranh giới được rút ra giữa chủ nghĩa thực dụng và chủ nghĩa giáo điều. Những gì bạn đã làm sẽ không phải là một ý tưởng tốt trong một nhóm và có lẽ không nên lặp lại trong tương lai, nhưng trong tình huống của bạn, tôi sẽ chỉ gửi cam kết lớn.

— Roy
nguồn

1

điều này dường như không thêm bất cứ điều gì đáng kể vào những gì đã được đăng trong 12 câu trả lời trước

— gnat

-1

Vấn đề không nằm ở sự chậm trễ lâu giữa các lần xác nhận mà thực tế là bạn giữ mã ở trạng thái không thể nén được quá lâu. Trước hết định nghĩa của bạn về 'dài' là gì? Đối với một số người, 5 phút cho trạng thái chuyển tiếp là quá nhiều nhưng một số người có thể đánh bóng mã của họ trong nhiều ngày mà không cần chạy trình biên dịch.

Trên thực tế, điều đó không thành vấn đề - điều quan trọng là bạn mất quyền kiểm soát mã của mình, mã của bạn trở nên không thể quản lý được. Điều này là bình thường, nó chỉ có nghĩa là bạn có nợ công nghệ và đã đến lúc nghĩ về tái cấu trúc. Vì vậy, bạn đang thất vọng? Mã của bạn không biên dịch, thậm chí bạn không có bài kiểm tra đơn vị? Làm thế nào bạn có thể nghĩ về tái cấu trúc trong trường hợp này? Đừng lo lắng. Kết thúc "mã hóa cao bồi" của bạn và bắt đầu làm sạch nó. Tốt nhất là cố gắng viết một số bài kiểm tra. Bạn không có thời gian cho việc đó? Ok, bắt đầu từ những cải tiến nhỏ.

Một số thay đổi không yêu cầu kiểm tra. Thay đổi tên biến cho phù hợp hơn, di chuyển mã lặp lại thành hàm riêng biệt, v.v ... Bạn sẽ hiểu rõ hơn về mã của mình. Sau đó, bạn có thể làm những thay đổi lớn hơn. Một lần nữa, hãy thử viết bài kiểm tra nếu có thể. Làm cho mã của bạn có thể quản lý được.

Sau đó, bạn sẽ thấy rằng thay đổi tiếp theo sẽ không khiến bạn "quá lâu" (bất kể nó có nghĩa là gì).

— AlexT
nguồn

2

Anh ấy đã không nói rằng anh ấy đã giữ mã không thể hoàn thành trong một thời gian dài. Mã trong repo đã không được sửa đổi trong một thời gian dài - cũ nhưng vẫn có thể biên dịch được. Mã trong bản sao làm việc của anh ta được cập nhật thường xuyên nhưng không được cam kết. Không có gì trong câu hỏi cho thấy mã của anh ta có thể yêu cầu tái cấu trúc - "mã hóa cao bồi" ở đây đề cập đến quy trình làm việc SCM của anh ta, chứ không phải chất lượng mã thực tế

— Idan Arye

@IdanArye Từ câu hỏi ban đầu ...Try to break it into smaller commits that likely won't compile...Nếu có điều gì đó ngăn bạn thực hiện mã của mình hơn thì đó là một bài hát hay mà mã khó quản lý. "Cam kết" chỉ là một trong những cách để duy trì công việc của bạn. Chúng ta có thể nghĩ về trường hợp cực đoan hơn - "nếu có gì đó ngăn tôi lưu tệp nguồn". mọi chuyện sẽ ra sao? Tôi đoán đó là nỗi sợ về những thay đổi của chính bạn. Tại sao nó có thể? ... Tôi đoán bạn đã hiểu rõ

— AlexT

2

Đối với tôi có vẻ như những gì ngăn cản anh ta phạm phải chỉ là sự lười biếng.

— Idan Arye

@IdanArye Bạn đúng về mọi tính. Điều đó cộng với việc không làm đủ TDD, đó là một vấn đề riêng biệt.

— durron597

@AlexT xem xét một kịch bản trong đó bạn sửa hai lỗi và một trong số chúng yêu cầu một phương thức mới được phát triển. Nếu bạn đã cam kết đúng cách, bạn sửa một lỗi, cam kết, sau đó sửa lỗi khác. Nếu bạn không, thì khi bạn cam kết, bạn phải bao gồm cả hai thay đổi trong cùng một cam kết hoặc cam kết sửa lỗi đầu tiên với các thay đổi cho lần thứ hai, ngoại trừ phiên bản đã cam kết không có lệnh gọi phương thức mới và do đó không biên dịch.

— durron597