git 工作流程使自定义修改的开源软件保持最新状态？

Question

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

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

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

我的 git 工作流程应该如何集成 WordPress 核心的新更改，同时保留旧的自定义更改？

Answer 1

我建议将您的更改保留在一个分支中，并在每次更新时根据 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 基础之后，协作者只需根据最新的工作重新设置正在进行的工作。

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

Answer 2

我的一般方法是有两个分支，upstream 和 master。创建您的存储库（这将在 master 分支中启动您），签入您使用的上游代码的最新副本，然后使用 创建 upsteram 分支>git 分支上游。另外，创建一个标记来指示您导入的上游版本，例如 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 checkoutupstream)，清除除 .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 

希望这会有所帮助，如果您还有任何其他问题，请告诉我。