Git tính năng chi nhánh và cải tiến mã nhỏ

Question

Chúng tôi chỉ mới bắt đầu sử dụng git cho mã sản xuất của mình và chúng tôi đang gặp phải một vấn đề nhỏ trong quy trình làm việc của mình. Chúng tôi cần tìm ra cách xử lý các cải tiến mã chung/sửa lỗi kỹ thuật xuất hiện khi làm việc trên một tính năng.

Quy trình làm việc mà chúng tôi đã áp dụng là sử dụng 'phát triển' làm chi nhánh tích hợp chính và phát triển tất cả các tính năng trên các nhánh tính năng ngoài 'phát triển'. Khi một tính năng hoàn tất, nhà phát triển tạo yêu cầu kéo và mọi người sẽ đánh giá nó để cung cấp nhận xét trước khi nó được hợp nhất trở lại phát triển. Điều này dường như hoạt động rất tốt.

Vấn đề chúng tôi gặp phải là trong quá trình phát triển thường xuyên tính năng, nhà phát triển có thể muốn sửa đổi/tái cấu trúc một số mã phổ biến để cải thiện hệ thống hoặc xóa một số khoản nợ kỹ thuật. Thay đổi này có giá trị, nhưng không trực tiếp gắn liền với tính năng đang được phát triển.

Dựa trên quy trình làm việc của chúng tôi, nó thực sự nên được thực hiện trên một nhánh khác trải qua yêu cầu kéo và xem xét mã của riêng nó trước khi bắt đầu phát triển. Nếu chúng ta có chúng làm điều này mặc dù, làm thế nào họ có thể nhận được sự thay đổi trở lại vào chi nhánh tính năng của họ trong khi chờ đợi cho việc xem xét mã đầy đủ xảy ra và mã để có được sáp nhập vào phát triển.

Những ý tưởng chúng tôi có là:

1) cherry-nhận những thay đổi từ chi nhánh 'refactorX' vào chi nhánh tính năng của chúng tôi. Tiếp tục phát triển và cho phép git (hy vọng) tìm ra khi chúng ta hợp nhất lại để phát triển rằng nó đã có sự thay đổi từ nhánh refactor.

2) Hợp nhất nhánh 'refactorX' vào chi nhánh tính năng của chúng tôi và tiếp tục phát triển. (lưu ý: chi nhánh phát triển cho 'refactorX' có thể sau này trong lịch sử phát triển, vì vậy chúng tôi nghĩ điều này có thể có vấn đề)

3) Một số tùy chọn thông minh khác mà chúng tôi chưa biết. :)

Những gì chúng tôi đang tìm kiếm là một số hướng dẫn thực hành tốt nhất về cách xử lý phần này của quy trình làm việc. Sau khi nói về nó nhiều hơn chúng ta biết rằng nó sẽ đi lên thường xuyên và chúng tôi muốn tìm một cách trơn tru và hiệu quả để xử lý nó trong công việc của chúng tôi.

Bất kỳ đề xuất nào?

Answer 1

Có vẻ như bạn đang cố gắng để tránh sáp nhập chi nhánh phát triển trở lại vào chi nhánh tính năng. Nó có lợi để tránh bước này, nhưng đôi khi nó là cần thiết, đặc biệt là trong các tình huống như thế này.

Một kỹ thuật mà chúng tôi đang bắt đầu sử dụng cũng là git rebase --onto. Thay vì hợp nhất chi nhánh phát triển vào nhánh tính năng, nhánh tính năng có thể được chuyển đến cuối nhánh phát triển để có được các tính năng mới.

Khi bạn đang sử dụng kho lưu trữ trung tâm, có thể hữu ích nhất khi tạo tên chi nhánh đối tượng địa lý mới. Ví dụ, chúng ta gắn thêm -v2 vào tên nhánh mới.

Quá trình di chuyển điển hình có thể trông giống như

git checkout feature 
git branch -m feature-v2 
git rebase --onto develop develop 
git push -u origin feature-v2 

Bây giờ bạn có mã mới trong ngành năng của bạn nhưng chưa sáp nhập chi nhánh phát triển thành các chi nhánh tính năng.

Answer 2

Tùy chọn thứ ba là nhà phát triển phải rebase tất cả các nhánh tính năng của họ vào nhánh đã được tái cấu trúc (vì vậy thay đổi cấu trúc lại được kết hợp trong tất cả công việc của họ). Sau đó bạn đảm bảo rằng nhánh cấu trúc lại được xem xét trước và hợp nhất lại vào nhánh phát triển. Tất cả các nhánh tính năng sẽ được dựa trên sự phát triển và bạn có thể hợp nhất chúng như bình thường (ví dụ: hợp nhất một, rebase các thành phần khác để phát triển, lặp lại).

Trong nghệ thuật ASCII, trước khi xem xét refactoring:

--- development 
       \ 
       --- refactoring 
           \ 
           --- feature1 
           --- feature2 

Và sau đó:

------ development|refactoring 
           \ 
           --- feature1 
           --- feature2 

Sau đó, nếu bạn hoàn thành feature1 và sáp nhập nó trong:

------ refactoring --- development|feature1 
        \ 
        --- feature2 

Bạn rebase feature2 phát triển lại:

------ refactoring --- development|feature1 
              \ 
              --- feature2 

Và sau đó bạn có thể hợp nhất feature2 trong như bình thường:

------ refactoring --- feature1 --- development|feature2