2011-08-15 14 views
5

Tôi luôn muốn thử những điều mới với quy trình làm việc của mình và tôi nghĩ rằng đó có thể là một thử nghiệm thú vị để tự động thực hiện các bước đỏ, xanh lá cây và refactor. trước khi đẩy).Tự động git cam kết giữa các bước Red, Green và Refactor?

Tôi đã tự hỏi liệu có ai khác đã thử điều này trước đây không? Tôi nghĩ rằng tôi đã đọc về điều này một lần, nhưng tôi không thể tìm thấy bất kỳ tài liệu tham khảo.

Tôi hy vọng một lợi ích có thể là tập trung nhiều hơn vào việc cam kết thường xuyên, cũng như có thể xem quy trình làm việc của tôi một cách trực quan để tôi có thể cải thiện nó. Ví dụ, trước khi đè bẹp tôi có thể thấy thời gian giữa màu đỏ và màu lục của tôi quá dài hay nếu số lượng thay đổi mã tôi thực hiện lớn hơn mức cần thiết giữa mỗi bước.

tôi sẽ thực hiện điều này như là một plugin guard để khi tôi tiết kiệm một spec hoặc thư viện tập tin, nó chạy thông số kỹ thuật và cam kết thay đổi với một thông điệp cam kết như:

Green: 1621 examples, 0 failures, 2 pending (1659 tests/s, 0.0006 p/test) 

Ý tưởng được rằng Tôi có thể quét trực quan điều này khi squashing và xác định nơi để nhóm các cam kết Red/Green/Refactor liên quan bằng các thay đổi hợp lý.

Tệ nhất tôi nghĩ đây có thể là một thử nghiệm thú vị, tốt nhất là nó có thể cho tôi một cách nhìn khác về cách tôi làm việc.

Trả lời

1

Tôi thích ý tưởng đó.

Hiển thị thông số mới/cập nhật có thể là dấu cộng. :)

Điều này có thể phức tạp đối với plugin này để biết khi nào mã đạt trạng thái "Màu đỏ/xanh" thực sự.

có nó:

  • cam --amend 'Red' khi thông số kỹ thuật không được đi qua và không có tập tin khác so với file 'đặc tả' được thay đổi?
  • sau khi cam kết 'Xanh' ngay sau khi thông số kỹ thuật được chuyển vì cập nhật trong lib?
+0

Tôi đã nghĩ về loại công việc đó. Để bắt đầu, tôi sẽ chỉ cam kết sau mỗi lần chạy spec. Sửa đổi khi không có thay đổi trạng thái có thể cắt giảm tiếng ồn mặc dù. – dkubb

1

Vâng, tôi nghĩ đây sẽ là một thử nghiệm thú vị để làm khi thông tin thu thập được sẽ rất thú vị để phân tích. Bạn có thể xem thời gian chu kỳ trung bình của mình và xem những phần nào của dự án (tệp) có thời gian chu kỳ chậm hơn có thể được coi là chỉ số mã. Càng có nhiều thông tin trong git log thì tốt hơn ... tức là spec nào thất bại, vv Hãy chia sẻ mọi tiến bộ và/hoặc kết quả xuất phát từ ý tưởng.

1

Wow !! Tin hay không, tôi đã có một ý tưởng tương tự một vài ngày trở lại (để làm như một dự án cuối tuần), khi tôi đã đọc về bài kiểm tra đơn vị, rằng tôi muốn xây dựng một mô-đun cho git làm điều tương tự.

Ý tưởng của tôi không hoàn toàn tự động hóa, mà là một phần. Ví dụ, một cam kết tùy chỉnh sẽ thấy những gì là RED và cung cấp cho họ một số ID, và GREEN tiếp theo sẽ xem tất cả những gì REDs nó giải quyết, và thêm một bình luận thích hợp trong thông điệp cam kết cùng với ID thử nghiệm và các cam kết RED.

Một số chức năng bổ sung có thể bao gồm duyệt qua các cam kết dựa trên một số tiêu chí ...

Anyways, nếu bạn thấy thông tin này mà bạn đang nói đến, vui lòng cập nhật chủ đề này.

1

Tôi thích điều này và đã tự coi đó là một hoặc hai lần. Tôi không chắc chắn tôi hoàn toàn nhìn thấy giá trị của nó mặc dù. Lúc đầu đỏ mặt tôi nghĩ rằng nó sẽ làm cho nó dễ dàng để quay trở lại trạng thái màu xanh lá cây được biết đến cuối cùng của tôi. Sau khi nhìn thấy JUnitMax, nó có chức năng "hoàn nguyên về màu xanh" được tích hợp sẵn, vì vậy tôi không cảm thấy mong muốn từ khi tự động cam kết.

Các vấn đề liên quan