Tôi không bao giờ chắc chắn khi một dự án đủ xa để lần đầu tiên cam kết kiểm soát nguồn. Tôi có xu hướng ngừng cam kết cho đến khi dự án hoàn thành "khung" và tôi chủ yếu cam kết các tính năng từ đó trở đi. (Tôi chưa thực hiện bất kỳ dự án cá nhân nào đủ lớn để có một khung cốt lõi quá lớn cho việc này.) Tôi có cảm giác đây không phải là cách thực hành tốt nhất, mặc dù tôi không chắc điều gì có thể sai.

Ví dụ, tôi có một dự án bao gồm một tệp mã duy nhất. Sẽ mất khoảng 10 dòng mã soạn sẵn và 100 dòng để dự án hoạt động với chức năng cực kỳ cơ bản (1 hoặc 2 tính năng). Trước tiên tôi nên đăng ký:

1. Các tập tin trống?
2. Mã nồi hơi?
3. Những tính năng đầu tiên?
4. Ở điểm nào khác?

Ngoài ra, những lý do để kiểm tra tại một điểm cụ thể là gì?

Bạn nên cam kết ngay khi bạn có một "đơn vị" hợp lý hoàn thành.

Một đơn vị là gì? Nó phụ thuộc vào những gì bạn đang làm; ví dụ, nếu bạn đang tạo một dự án Visual Studio, hãy cam kết giải pháp ngay sau khi tạo, ngay cả khi nó không có gì trong đó.

Từ đó trở đi, hãy tiếp tục cam kết thường xuyên nhất có thể, nhưng vẫn chỉ cam kết hoàn thành các "đơn vị" (ví dụ: các lớp, cấu hình, v.v.); làm như vậy sẽ giúp cuộc sống của bạn dễ dàng hơn nếu có sự cố xảy ra (bạn có thể hoàn nguyên một bộ thay đổi nhỏ) và sẽ giảm khả năng xảy ra xung đột.

Theo như tôi quan tâm, repo kiểm soát nguồn của bạn là một phần của thiết lập dự án cơ bản, vì vậy tôi cam kết ngay sau khi tôi tạo dự án trống của mình.

Hôm qua

... thay vào đó, nếu bạn không thể du hành thời gian ...
(có thể xe của bạn không thể đạt tốc độ 88mph hoặc tụ điện thông lượng của bạn bị ngắt)

Hiện nay

Các dự án mới nên được cam kết tại điểm đẫm máu, thật điên rồ, và các hệ thống DVCS hiện đại chỉ cần loại bỏ mọi lý do sở hữu để tránh các cam kết : git init . ; git add * ; git commit -m initial-commitbây giờ, trước khi quá muộn, vì nó có thể đã quá muộn.

Một câu hỏi hợp lý hơn, có thể tranh cãi hơn có thể là: "Khi nào tôi nên hợp nhất các cam kết của mình với một kiểm soát nguồn được chia sẻ trên một kho lưu trữ được quản lý theo nhóm trong một dự án đã thiết lập ?" (lưu ý các tính từ, tính từ rất quan trọng) Và tôi có cảm giác hầu hết các câu trả lời khác thực sự đang cố gắng trả lời cho điều đó.

Chi nhánh cá nhân của bạn nên được cam kết thích điên , ít nhất một lần mỗi ngày , trước khi đi ngủ. Bạn có thể thức dậy vào buổi sáng sau đó, và thấy rằng bạn không biết bạn đang làm cái quái gì vào tối hôm trước. VCS sẽ bảo vệ bạn chống lại điều đó và có cơ hội quay trở lại phiên bản phụ của phiên bản phụ gần đây có khả năng biên dịch độc đáo, chạy trơn tru và / hoặc vượt qua các bài kiểm tra có thể là lựa chọn tốt nhất của bạn.

Tôi sẽ nói cam kết càng sớm càng tốt. Mục đích chính của kiểm soát nguồn là cho phép bạn quay trở lại trong trường hợp có sự cố xảy ra và điều này cộng hưởng với thực hành "cam kết sớm và thường xuyên".

Cá nhân, cam kết đầu tiên của tôi thường chỉ chứa tệp .gitignore (hoặc tương đương) với một vài bộ lọc mà tôi biết sẽ cần thiết, như * .py [co] cho mã Python. Thiết lập dự án cơ bản và / hoặc nguyên mẫu đơn giản đầu tiên là những gì thường theo sau.

Cam kết đầu tiên có thể là một tệp README với ít nhất một bản tóm tắt của dự án hoặc đủ thông tin về cột mốc đầu tiên của dự án. Các chủ đề rộng cũng có thể bao gồm:

• Giới thiệu
• Mô tả dự án
• Cơ cấu dự án
• Quy ước mã hóa
• Hướng dẫn cách làm:
  • xây dựng
  • kiểm tra
  • triển khai
• Vấn đề đã biết và cách giải quyết
• những việc cần làm
• Điều khoản sử dụng

Việc thực hành cập nhật README trước khi thực hiện các thay đổi cho dự án cũng được gọi là Phát triển theo hướng Readme và nó cho phép bạn suy nghĩ về các thay đổi trước khi đầu tư thời gian để thực hiện các thay đổi đó.

Bất cứ ai muốn đóng góp hoặc sử dụng phần mềm này sau đó sẽ bắt đầu với README.

Nếu bạn đã hoàn thành công việc mà bạn không muốn mất, thì nó sẽ nằm trong hệ thống kiểm soát nguồn của bạn.

Điều này chắc chắn áp dụng cho các hệ thống phân tán như Git. Nếu bạn đang sử dụng một hệ thống tập trung và cách duy nhất để kiểm tra một cái gì đó là làm cho nó hiển thị với mọi người , bạn có thể muốn giữ lại - hoặc bạn có thể xem xét việc thiết lập kho lưu trữ git cục bộ của riêng mình và gửi đến tập trung hệ thống khi bạn đã sẵn sàng.

Nguyên tắc nhỏ của tôi là kiểm tra một khi tệp giải pháp của tôi (hoặc đoạn mã xây dựng khác) được thực hiện, ngay cả khi nó chứa một vài tệp trống. Đó là một thực tiễn tốt khi có nhiều hơn một người làm việc trong dự án. Tập tin đó có xu hướng có các vấn đề hợp nhất tồi tệ nhất ban đầu vì mọi người đang thêm mọi thứ vào dự án vì vậy cần phải cam kết sớm và thường xuyên.

Ngay cả khi bạn là người duy nhất làm việc trong dự án và nó chỉ có một tệp, tôi thấy việc theo cùng một quy trình công việc dễ dàng hơn và tiết kiệm suy nghĩ cho vấn đề trong tay.

Không chắc chắn nếu nó đã được đề cập.

Nhưng hãy chắc chắn rằng những gì bạn cam kết chạy / biên dịch! Vì vậy, không có lỗi cú pháp, vv

Không có gì bực bội hơn việc kiểm tra mã bị hỏng.

Quan điểm khác liên quan nhiều hơn đến kiểm thử phần mềm (phương pháp TDD) sẽ được cam kết ngay khi bạn có các trường hợp kiểm thử mới có màu xanh lá cây. Điều này có nghĩa là bạn đã hoàn thành một "đơn vị" mã mới.

Ngay trước khi bạn làm điều gì đó ngớ ngẩn.

Đối với những người trong chúng ta không có sức mạnh ma thuật, điều đó có nghĩa là ít và thường xuyên.

Nếu bạn đang làm việc một mình, hãy làm điều đó mỗi khi bạn uống, hoặc bất cứ điều gì.

Nếu bạn đang làm việc trong một nhóm, có lẽ bạn cần đảm bảo rằng thứ đó sẽ được biên dịch, để nếu người khác có bản mới nhất, họ sẽ không gặp phải lỗi. Nhưng khác hơn thế, càng nhiều càng tốt.

Khoảng 2 ~ 3 giờ vào dự án.

Đùa thôi. Không có một câu trả lời hay nào phù hợp với mọi tình huống. Trước hết, nếu bạn có một hệ thống kiểm soát phiên bản phân tán (như git hoặc Mercurial) thì cam kết repo cục bộ của bạn sẽ không bảo toàn dữ liệu của bạn trong trường hợp thất bại thảm hại. Nhưng một repo từ xa riêng có thể khiến bạn mất tiền, ví dụ như trên github. Bạn sẽ lưu giữ lịch sử cam kết, nhưng theo kinh nghiệm của tôi, bạn sẽ không cần điều đó cho đến khi dự án của bạn được nâng cao một chút.

Ngoài ra, bạn có thể không muốn có quá nhiều khuấy động lúc đầu, đặc biệt nếu bạn đang di chuyển các tệp xung quanh. Cam kết thay đổi sẽ là một gánh nặng nếu chỉ là một nhỏ. Bạn thậm chí có thể quyết định vứt bỏ mọi thứ. Nhưng nếu bạn mất các thay đổi không quan trọng để sao chép thì bạn sẽ bỏ lỡ việc tạo một bản sao lưu và các hệ thống kiểm soát phiên bản tạo ra các hệ thống sao lưu cực kỳ giá trị.

Một số người hiện nay sử dụng DropBox hoặc tương tự để lưu trữ mã của họ. Nó có thể là một sự thỏa hiệp tốt khi bắt đầu một dự án vì không cần nỗ lực để thiết lập. Tuy nhiên, đó là một thói quen man rợ trong phát triển phần mềm nghiêm trọng, đặc biệt là nếu một số người đang chạm vào mã cùng một lúc.

Vì vậy, tôi có xu hướng thiết lập kiểm soát phiên bản bất cứ khi nào tôi có thứ gì đó có giá trị, tức là không tầm thường để nhân rộng. Giá trị là chủ quan (và phụ thuộc vào năng lực của một người), do đó bạn sẽ phải đưa ra đánh giá của riêng mình. Tại thời điểm đó, tôi lưu trữ một repo thứ hai trên một đĩa bên ngoài hoặc trên github nếu đó là một dự án công cộng hoặc tài khoản thanh toán của tôi sẽ giữ nó.

Nhiều người đã trả lời "Ngay lập tức" và tôi đồng ý 100%. Tôi cũng thích đề xuất của Xion để bắt đầu với các mẫu bỏ qua của VCS (tức là .gitignorehoặc tương đương).

Tôi đoán nó đã được nhiều người đồng ý rằng không có nhược điểm nào đối với các cam kết sớm. Tôi muốn thêm ưu điểm:

• Bạn ít có khả năng cam kết những thứ mà bạn đã chọn để loại bỏ nhưng điều đó vẫn còn lảng vảng xung quanh. Khi tôi bắt đầu một sự phát triển mới, tôi sẽ mã hóa và loại bỏ các thứ một cách nhanh chóng và khi tôi cam kết sau đó, khi đã có một loạt các tệp, tôi đã vô tình cam kết các công cụ chỉ để xóa nó trong lần xác nhận tiếp theo. Điều này, trái ngược với cam kết nhỏ, hoặc thậm chí trống rỗng, là tiếng ồn thực sự trong lịch sử.
• Nếu bạn thuộc loại có hệ thống và có những bước đầu tiên điển hình trong các dự án của mình, việc có những điểm như cam kết có thể là hướng dẫn cho bạn hoặc cho người khác, và thậm chí nó có thể tạo cơ hội để phân nhánh tại một điểm nhất định và tạo ra một dự án có thể sử dụng lại. Tôi đã làm việc với các dự án dựa trên Maven, nơi điều này rất hữu ích (vì khi thiết lập dự án Maven, một số bước đầu tiên nhỏ có thể xác định cơ sở khá lớn và trong khi các bước đó không phải làm gì nhiều , chúng có thể cần phải suy nghĩ đủ để đảm bảo tái sử dụng).

Nó có thể phụ thuộc vào VCS mà bạn đang sử dụng.

Với Git, tôi cam kết một thư mục trống (hoặc với tệp README gần như trống). Vấn đề là tôi có thể quay lại và đặt lại chi nhánh của mình về trạng thái trống đó nếu tôi muốn bắt đầu lại hoàn toàn trong khi tôi vẫn còn sớm trong quá trình phát triển (trước khi đẩy ngược dòng). Sau đó tôi sẽ cam kết các tệp "được tạo" của mình (ví dụ: giải pháp phòng thu trực quan). Sau đó, khi tôi thực sự viết mã, tôi sẽ bắt đầu cam kết từng đơn vị như bình thường.

Với SVN, bạn đang đẩy mạnh việc ngược dòng với từng cam kết để bạn thực sự không có được sự sang trọng khi bắt đầu lại như bạn làm với Git. Trong trường hợp này, có thể không có lợi khi cam kết sớm nếu bạn nghĩ rằng bạn sẽ thực hiện việc sửa chữa sớm trong quá trình này. Điều đó sẽ tùy thuộc vào người viết mã.

Khi tôi bắt đầu một dự án mới, tôi thường bắt đầu bằng cách cam kết rằng trước khi bất kỳ mã nào được thêm vào. Một nguyên tắc chung mà tôi luôn tuân theo là: nếu PC của bạn gặp sự cố và xóa sạch tất cả dữ liệu của bạn, bạn không muốn phải viết mã từ bộ nhớ. Mười năm trước TDD và thực hành lập trình tốt hơn tôi khá lạc quan về những gì tôi có thể nhớ. Bây giờ, tôi có xu hướng thận trọng hơn. Như rất nhiều áp phích khác đã nói cam kết sớm và cam kết thường xuyên. Bạn không mất gì khi làm điều đó.

Tôi đang làm việc một mình trong hầu hết thời gian vì vậy tôi phải thú nhận rằng tôi đang bị chùng bước nhưng tôi thường cam kết trước khi về nhà. Theo cách đó, nếu tôi không đến vào ngày mai thì các đồng nghiệp của tôi có thể đến nơi tôi rời đi.

Tôi hiện đang sử dụng Rùa / SVN tại nơi làm việc.

Cam kết dự án trống ngay. Tiếp tục cam kết nhiều lần mỗi giờ bạn dành cho dự án. Cam kết ngay cả khi mã không biên dịch. Tôi đánh dấu các cam kết như vậy bằng "WIP" trong phần massage cam kết để theo dõi chúng.

Tôi cũng có một kịch bản tự động cam kết tất cả các dự án của tôi cứ sau 10 phút vào một repo dự phòng, chỉ trong trường hợp tôi quên cam kết thủ công. Hãy gọi nó là bộ đệm hoàn tác dựa trên đám mây của tôi.

Kiểm tra (còn gọi là đẩy ) dự án vào nhóm repo khi bạn cần nhóm của mình để xem mã của mình. Đó có thể là trước khi mã của bạn sẵn sàng để nhóm của bạn nhìn thấy, nếu bạn giống như tôi.

Nếu bạn muốn được tốt đẹp vào nhóm của bạn, bí cam kết của bạn trước khi đẩy họ đến repo đội.

Tôi đã xem qua tất cả các bài báo và tôi nghĩ rằng chúng tôi đã có rất nhiều giải pháp tốt nhưng tôi muốn chia sẻ phương pháp của tôi với bạn.

Trong khi làm việc với việc tạo khung (ngay từ đầu), rất nhiều thay đổi sẽ diễn ra cho mỗi mô-đun cho đến khi mô-đun được hoàn thành hoặc hoàn thành. Vì vậy, tôi luôn có 2 vị trí, một vị trí được đặt tên là NĂNG ĐỘNG và vị trí khác là STATIC. Khi các thay đổi đang diễn ra và khung chưa hoàn tất, nó đã được cam kết ở vị trí DYANMIC và sau khi hoàn thành và hoàn tất, tôi chuyển nó đến vị trí STATIC. Vì vậy, tôi có một Kiểm soát nguồn hoàn chỉnh.

Cảm ơn

Với bất kỳ ứng dụng nào, bạn sẽ dành thời gian để thiết kế các thành phần. Bạn nên biết, đại khái hoặc chi tiết đầy đủ, không gian tên, dự án, tài liệu tham khảo bên ngoài, thư viện của bên thứ 3, v.v.

Nếu bạn ở trong một nhóm, tôi sẽ đề nghị lãnh đạo của bạn, hoặc bất cứ ai được chọn, để tạo dự án cơ sở, đặt các phụ thuộc và kiểm tra bộ xương đó (nền tảng mà dự án của bạn sẽ được xây dựng).

Bạn cũng muốn đảm bảo rằng bạn có nhiệm vụ, bản phát hành, thân cây, v.v.

Nếu bạn đang thực hiện một "nhiệm vụ" mới cho một dự án đang được thực hiện và bạn đang ở trong nhánh nhiệm vụ của riêng mình, hãy thực hiện kiểm tra hàng đêm để bạn giữ được công việc của mình.

Thông thường tôi kiểm tra bất cứ khi nào tôi thêm một cái gì đó mới, nhưng cố gắng tách các thứ trong các cam kết riêng biệt.

Điều đó có nghĩa là, nếu tôi thêm một phụ thuộc mới, tôi thực hiện các thay đổi cho đến khi chúng được biên dịch hoặc chúng đủ lớn để mất thời gian để làm lại chúng, từ đầu. Nếu tôi có một nhiệm vụ lớn hơn, tôi cố gắng cam kết nhiều lần, khi nó có ý nghĩa (một lần cho mỗi chức năng, mỗi lần tôi thực hiện nó biên dịch và chạy thành công, v.v.).

Tôi cũng cam kết khi tôi muốn một điểm sao lưu (nghĩa là "nếu những gì tôi thử bây giờ sẽ không hoạt động hoặc trở nên quá phức tạp, tôi muốn quay lại mã như hiện tại" hoặc khi ai đó yêu cầu tôi bỏ đi những gì tôi đang có làm và khắc phục một số vấn đề cấp bách).

Nếu bạn sử dụng hệ thống kiểm soát nguồn tập trung, bạn không thể tùy ý cam kết cho các điểm dự phòng, bởi vì một cam kết không biên dịch / công việc ảnh hưởng đến mọi người trong nhóm của bạn.

Thông thường khi tôi bắt đầu thêm mã soạn sẵn (ví dụ: thêm một ứng dụng web mới trong trang web django), tôi cam kết mọi thao tác tôi làm.

Nếu tôi làm theo hướng dẫn để tạo / ghi mã, tôi sử dụng tên bước trong hướng dẫn cho thông điệp cam kết. Bằng cách này, tôi có thể chỉnh sửa khác nhau và xem những gì một bước hướng dẫn đã làm, tại bất kỳ điểm nào sau này.

Ví dụ, tôi có một dự án bao gồm một tệp mã duy nhất. Sẽ mất khoảng 10 dòng mã soạn sẵn và 100 dòng để dự án hoạt động với chức năng cực kỳ cơ bản (1 hoặc 2 tính năng).

Nó sẽ phụ thuộc vào mức độ khó thêm các công cụ:

• Nếu việc thêm mã tấm nồi hơi là không quan trọng, tôi sẽ thêm nó và cam kết ngay trước khi bắt đầu mã khác (theo cách này, nếu tôi mắc lỗi hoặc đưa ra một lỗi lạ sau đó, tôi có thể chỉ cần quay lại mã nồi hơi và bắt đầu lần nữa).

• Nếu mã không tầm thường, tôi sẽ cam kết mỗi khi tôi thêm một cái gì đó mới (bất cứ nơi nào giữa hai dòng mã được thay đổi, thành một trăm hoặc hơn).