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 回答