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

Question

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

gitopen-sourceworkflowbranching-and-merging

8

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

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

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

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

- John Kary

2个回答

2

我的一般做法是有两个分支：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

希望这可以帮到您，如果您有任何进一步的问题，请告诉我。

- Brian Campbell

这个技术上可行，但每次重新将更改应用于最新的源代码似乎更合乎逻辑，因此重新设置基础听起来比合并更好。 - John Kary

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- dahlbyk · Accepted Answer

我建议将你的更改保存在一个分支中，每当你更新时，将该分支与来自WordPress的最新版本进行变基。粗略的时间线如下...

              +-- 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。在我的观点中，最容易通过逐次提交进行重新定制。任何冲突意味着自定义可能被破坏了，所以旧的自定义提交无论如何都是无效的-最好只在源头上修复问题，并保持更新的历史记录干净。

在master更新并且重新创建并推送custom后，协作者只需针对最新版本重新创建他们正在进行的工作。

这只是我作为一个坚定的重新创建>合并支持者的观点。Git的优美之处在于很少有一个正确答案。只要不断调整，直到找到适合自己的东西即可。