luồng công việc git để cập nhật phần mềm mã nguồn mở được sửa đổi tùy chỉnh?

Question

Đại học của chúng tôi cung cấp dịch vụ lưu trữ web cho các phòng ban của trường trên các máy chủ mà chúng tôi quản lý. Cài đặt các chương trình của bên thứ ba nguồn mở yêu cầu sửa đổi quyền và mã của chương trình trước khi nó chạy. (Chúng tôi đang sử dụng suEXEC, nếu bạn quen thuộc.)

Hiện tại chúng tôi cung cấp WordPress thông qua tập lệnh trình cài đặt. Người dùng tải lên bản phát hành ổn định mới nhất và chạy tập lệnh PHP phía máy chủ thông qua SSH. Tập lệnh PHP này sửa đổi quyền truy cập tệp của tất cả các tệp/thư mục, thêm/xóa một số mã trong các tệp khác nhau và tạo một vài tệp mới. Kịch bản trình cài đặt này là hành động cân bằng cồng kềnh khi một phiên bản ổn định mới được phát hành.

Tôi muốn bắt đầu sử dụng điều khiển phiên bản (cụ thể git) để theo dõi các thay đổi tùy chỉnh thay vì dựa vào tập lệnh để thực hiện thay đổi, nhưng không chắc chắn về quy trình làm việc cần sử dụng. Tôi quen với việc phân nhánh và hợp nhất, nhưng không chắc chắn cách tích hợp các thay đổi cũ của chúng tôi khi phát hành bản phát hành mới.

Luồng công việc git của tôi là gì để tích hợp các thay đổi mới từ lõi WordPress, mà còn giữ lại các thay đổi tùy chỉnh cũ hơn của chúng tôi?

Answer 1

Tôi khuyên bạn nên giữ các thay đổi của mình trong chi nhánh và xóa chi nhánh đó khỏi chi nhánh mới nhất từ ​​WordPress bất cứ khi nào bạn cập nhật. Trong một thời gian khó khăn ...

   +-- WordPress 1.0 
       v 
[master] --*--* 
       \ 
[custom]  *--*--*  <- your customizations 

Khi bạn muốn cập nhật WordPress, chuyển sang nắm vững và thực hiện một mới cam kết với souce mới nhất (hoặc sử dụng git-svn để giữ tổng thể đồng bộ):

   +-- WordPress 1.0 
       |  +-- WordPress 1.1 
       v  v 
[master] --*--*--*--* 
       \ 
[custom]  *--*--*  <- your customizations 

Bây giờ bạn có thể thực hiện git rebase master custom để phát lại các thay đổi của mình so với mới nhất, giải quyết mọi xung đột trong quá trình thực hiện. timeline của bạn sau đó sẽ trông như thế này:

   +-- WordPress 1.0 
       |  +-- WordPress 1.1 
       v  v 
[master] --*--*--*--* 
        \ 
[custom]    *--*--*  <- your customizations 

Cập nhật: Để cung cấp một chút lý do ... Tôi thích cách tiếp cận này cho vấn đề này bởi vì nó cung cấp một sự khác biệt rõ ràng giữa mã từ WordPress và các tùy chỉnh của bạn. Khi bạn nhận được một phiên bản mới của WordPress, bạn thực sự không quan tâm đến "tích hợp". Bạn quan tâm đến việc áp dụng lại các tùy chỉnh của mình cho phiên bản WordPress mới. Theo quan điểm của tôi, việc tái sử dụng đó được thực hiện dễ dàng nhất bằng cách cam kết thông qua việc rebase. Bất kỳ xung đột nào có nghĩa là tùy chỉnh có thể bị hỏng, do đó, cam kết tùy chỉnh cũ là rác - tốt hơn là chỉ khắc phục sự cố ở nguồn của nó và giữ cho lịch sử được cập nhật sạch sẽ.

Sau khi master được cập nhật và custom được rebased và đẩy, các cộng tác viên sẽ chỉ rebase công việc của họ trong tiến trình chống lại mới nhất.

Đây chỉ là ý kiến ​​của tôi, với tư cách là công ty rebase> hợp nhất người đề xuất. Vẻ đẹp của Git là hiếm khi có một câu trả lời đúng. Chỉ cần tiếp tục điều chỉnh cho đến khi bạn tìm thấy một cái gì đó phù hợp với bạn.

Answer 2

Cách tiếp cận chung của tôi là có hai chi nhánh, upstream và master. Tạo kho lưu trữ của bạn (sẽ bắt đầu bạn trong chi nhánh master), kiểm tra bản sao mới nhất của mã ngược dòng mà bạn sử dụng và sau đó tạo chi nhánh upsteram với git branch upstream. Ngoài ra, hãy tạo thẻ cho biết phiên bản đầu tiên bạn đã nhập, chẳng hạn như git tag wordpress-1.0. Tôi thường sử dụng các thẻ nhẹ cho điều này (những thẻ không có chú thích nào, về cơ bản là một con trỏ tới bản sửa đổi).

[wordpress-1.0]    Key: [tag] 
v         branch 
* <- upstream      * commit 
^- master 

Bây giờ, trong khi bạn vẫn đang trong chi nhánh master, sao chép thay đổi của bạn và kiểm tra những người trong. Bây giờ bạn có hai chi nhánh, upstream trong đó có nguồn gốc thượng nguồn nguyên sơ, và master trong đó có những thay đổi của bạn, với lịch sử hiển thị những thay đổi bạn đã thực hiện cho upstream.

[wordpress-1.0] 
v 
* <- upstream 
\ 
    +--* <- master 

Thực hiện tất cả các sửa đổi của bạn trong chi nhánh master.

[wordpress-1.0] 
v 
* <- upstream 
\ 
    +--*--*--* <- master 

Khi một phiên bản mới của mã thượng nguồn đến cùng, hãy kiểm tra upstream chi nhánh của bạn (git checkout upstream), hãy bỏ ra tất cả mọi thứ nhưng thư mục .git, và sao chép trong phiên bản ngược dòng mới. Sử dụng git add -A để hiển thị tất cả các thay đổi trong phiên bản ngược dòng, cam kết và gắn thẻ thay đổi đó.

[wordpress-1.0] 
| [wordpress-1.1] 
v v 
*--* <- upstream 
\ 
    +--*--*--* <- master 

Bây giờ, hãy xem master và hợp nhất các thay đổi ngược dòng của bạn. Tại thời điểm này, bạn có thể chọn cách hợp nhất, chẳng hạn như lấy phiên bản luồng mới, lấy phiên bản của bạn hoặc thực hiện các thay đổi đã hợp nhất, giống như bạn thực hiện trong quá trình hợp nhất thông thường.

[wordpress-1.0] 
| [wordpress-1.1] 
v v 
*--*--------+ <- upstream 
\   \ 
    +--*--*--*--* <- master 

Vì vậy, tất cả các thay đổi của bạn xảy ra trên master, và tất cả các phiên bản thượng nguồn tôi cam kết chính xác như là upstream. Điều đó sẽ cho phép bạn thấy dễ dàng nhất chính xác cách mã của bạn khác với phiên bản ngược dòng, nó sẽ giúp theo dõi những thay đổi bạn đã hợp nhất với phiên bản ngược dòng, v.v.

[wordpress-1.0] 
| [wordpress-1.1] 
| |   [wordpress-2.0] 
v v   v 
*--*--------+--*-+ <- upstream 
\   \ \ 
    +--*--*--*--*----*--* <- master 

Hy vọng điều này sẽ giúp, cho tôi biết nếu bạn có thêm bất kỳ câu hỏi nào.