8

我们的大学在我们管理的服务器上为校园部门提供网络托管。安装开源第三方程序需要在程序运行前修改文件权限和代码。（如果您熟悉的话，我们使用的是 suEXEC。）

我们目前通过安装程序脚本提供 WordPress。用户上传最新的稳定版本，并通过 SSH 运行服务器端 PHP 脚本。这个 PHP 脚本修改所有文件/文件夹的文件权限，添加/删除各种文件中的一些代码，并创建一些新文件。当发布新的稳定版本时，此安装程序脚本是一个繁琐的平衡操作。

我想开始使用版本控制（特别是 git）来跟踪我们的自定义更改，而不是依赖脚本来进行更改，但我不确定要使用的工作流程。我熟悉分支和合并，但不确定在发布新版本时如何集成我们的旧更改。

我的 git 工作流程应该是什么来集成来自 WordPress 核心的新更改，同时保留我们旧的自定义更改？

4

2 回答 2

10

我建议将您的更改保留在一个分支中，并在您更新时根据 WordPress 的最新版本将该分支重新定位。在粗略的时间线...

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

当你想更新 WordPress 时，切换到 master 并使用最新的源进行新的提交（或使用 git-svn 保持 master 同步）：

              +-- 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。在我看来，重新定制最容易通过 rebase 提交来完成。任何冲突都意味着自定义可能会中断，因此旧的自定义提交无论如何都是垃圾 - 最好从源头解决问题并保持更新的历史记录干净。

在master更新并custom重新定位和推送之后，合作者只需将他们正在进行的工作重新定位到最新的。

这只是我的观点，作为一个坚定的 rebase > merge 支持者。Git 的美妙之处在于很少有一个正确的答案。只要不断调整，直到你找到适合你的东西。

于 2010-09-29T16:42:51.157 回答
2

我的一般方法是有两个分支，upstream并且master. 创建您的存储库（它将在master分支中启动您），签入您使用的上游代码的最新副本，然后upsteram使用git branch upstream. 此外，创建一个标签，指示您已导入哪个上游版本，例如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-29T16:42:33.577 回答