保持定製修改的開源軟件最新的git工作流程？

我們的大學爲我們管理的服務器上的校園部門提供虛擬主機。安裝開源第三方程序需要在程序運行之前修改程序中的文件權限和代碼。（如果您熟悉，我們使用suEXEC。）保持定製修改的開源軟件最新的git工作流程？

我們目前通過安裝程序腳本提供WordPress。用戶上傳最新的穩定版本，並通過SSH運行服務器端PHP腳本。這個PHP腳本修改所有文件/文件夾的文件權限，添加/刪除各種文件中的一些代碼，並創建一些新文件。當新的穩定版本發佈時，此安裝程序腳本是一項麻煩的平衡操作。

我想開始使用版本控制（特別是git）來跟蹤我們的自定義更改，而不是依賴腳本進行更改，但我不確定要使用的工作流程。我熟悉分支和合並，但不知道在發佈新版本時如何整合舊版本的變更。

我的git工作流程應該如何整合來自WordPress核心的新變更，同時保留舊的自定義更改？

來源

2010-09-29 John Kary

我會建議在分支中保留更改，並在更新時將分支與最新的分支進行重新分配。在一個粗略的時間表...

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

當你想更新WordPress的，切換到主，並與最新的烴源新的提交（或使用git-SVN保持同步主）：

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

現在你可以做一個git rebase master custom重播你最新的變化，解決任何衝突。然後，您的時間安排是這樣的：

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

更新：提供有點理由的......我喜歡這種方法，對於這個問題，因爲它從WordPress和您的自定義代碼提供了明確區分。當你得到一個新版本的WordPress時，你對「整合」真的不感興趣。您有興趣將自定義設置重新應用到新版本的WordPress。在我看來，這種recustomization是最容易做的承諾通過承諾通過rebase。任何衝突都意味着定製化可能會破壞，所以舊的定製提交無論如何都是垃圾 - 最好是從源頭解決問題並保持更新的歷史記錄清潔。

在master更新後，custom重新設置並推送後，合作者只會根據最新進行重新設置其正在進行的工作。

這只是我的看法，作爲一個堅定的rebase>合併支持者。 Git的美妙之處在於很少有正確的答案。只要不斷調整，直到找到適合你的東西。

來源

2010-09-29 16:42:51 dahlbyk

我會對此建議，因爲重新佈局可能會導致很多問題。它失去了歷史（你不能回到以前實際部署的版本，也不能告訴你什麼時候進行了合併），並且讓工作分支一直重新分配，這使得你很難與之協作其他人，因爲現在他們還需要重新設計他們所做的一切。對於尚未與其他任何人共享的變化或者已知易變的變化，重新制作是最適合的變化，而不是在每次有新版本發佈時在上游對整個歷史進行重新設計。 – 2010-09-29 21:29:47

如果溝通失敗，重新激活可能會導致問題，但完全可以管理。如果您不保留對提交的引用，則歷史記錄將丟失 - 只需標記已部署的版本即可，並且不會丟失任何內容。 – dahlbyk 2010-09-30 05:18:05

在我們的案例中，rebasing似乎是一個很好的解決方案，因爲我們只將源代碼作爲壓縮包共享。沒有其他使用最終產品的開發人員像我們一樣對核心進行更改，因此不需要與其他人共享。 – 2010-10-01 16:59:47

我的一般做法是有兩個分支，upstream和master。創建您的資源庫（將在master分支中啓動您），檢入您使用的上游代碼的最新副本，然後使用git branch upstream創建upsteram分支。另外，創建一個標籤，指出您已導入的上游版本，如git tag wordpress-1.0。我通常使用輕量級標籤（沒有任何註釋，基本上是指向修訂版的指針）。

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

現在，當你仍然在master分支，複製更改並檢查這些在現在你有兩個分支，upstream其中包含原始上游源，並master其中包含你的變化，歷史記錄顯示您對upstream所做的更改。

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

使所有在master分支的修改。

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

當上遊代碼的新版本的時候，看看你的upstream分支（git checkout upstream），清除一切，但.git目錄，並在新的上游版本複製。使用git add -A可以對上游版本中的所有更改進行處理，提交併對其進行標記。

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

現在，檢出master，併合並您的上游更改。此時，您可以選擇如何合併，如採用新的上游版本，採用您的版本，或者採用合併的更改，就像您在正常合併中一樣。

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

因此，所有的更改發生在master，和所有上游版本正是致力於爲的是upstream。這會讓你更容易地看到你的代碼與上游版本的區別，這將有助於跟蹤你已經與上游版本合併了哪些更改，等等。

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

希望這有助於，讓我知道如果您有任何進一步的問題。

來源

2010-09-29 16:42:33

這在技術上是有效的，但每次重新應用我們對最新源代碼的更改聽起來更合理，因此重新綁定聽起來像是一種比合並更好的選擇。 – 2010-10-01 19:50:13

保持定製修改的開源軟件最新的git工作流程？

回答

相關問題