0

我坚持这个想法。

如果我开发一个应用程序，比如说 PHP 论坛或 cms。

大多数 PHP 论坛和 CMS 都有这些（加上一些）共同点：

  • 它们包括一个安装程序目录。
  • 安装后，出于安全原因，应删除安装程序目录。
  • 在删除安装程序目录之前，该应用程序将无法正常工作（显示消息，或根本无法工作）。

现在这是有道理的，但我不太明白应该如何管理开发这个应用程序和版本控制。

目前，我的系统上有两个应用程序副本。

一个“干净”的副本，没有做任何事情。
一个“开发”副本，此副本已安装并且是工作副本。

如果我修复了错误，或者向开发版本添加了新功能，然后我手动将更改复制到干净副本，提交并推送。

这非常耗时，而且在我看来并不实用。

如果应用程序有扩展名，我会执行相同的过程，我的“开发”副本与插件一起安装，并且我有一个干净的扩展副本。

有没有更好的方法来管理这个？

4

4 回答 4

1

您可以删除安装文件夹进行测试，然后将已删除的文件标记为：

git update-index --assume-unchanged [list of filenames]

并且 git 不会提示您从存储库中删除它们。

您可以使用：

git ls-files --deleted

列出所有已删除的文件，以便您可以使用以下命令自动删除它们：

git update-index --assume-unchanged `git ls-files --deleted`
于 2013-02-09T23:21:14.810 回答
1

将所有更改和错误修复提交到dev( develop) 分支；并且仅当您想要发布一系列更改时才从developto clean( )合并。master使用其他分支开发特定的新功能；并使用标记显示发布质量代码

于 2013-02-09T22:58:40.960 回答
1

典型的企业工作流程看起来像这样（当然有无限的变化）：

production分支包含所有实际发布的代码。标签用于标记特定的发行版或版本。

一个staging（或者可能qa；名称是相当随意的）分支用于准备新版本和/或补丁。因此，如果正在进行开发但需要紧急补丁，则可以在此分支中制作它，然后合并到production( git merge staging) 作为部署或发布过程的一部分。

各个development分支机构跟踪特定的开发工作。新功能等。当它们准备好发布时，它们会合并到staging/qa等中，直到它们实际发布。如果您的工作流程中有更多步骤，您可以在必要时将更多分支添加到列表中（生产 -> 登台 -> qa -> 集成 -> 测试 -> 等）。

这个工作流程的想法是你总是可以从production-> staging->development分支安全地向下合并。当您想将一些代码推进到启动时，您会以相反的方向合并。

git 中的分支很便宜，所以如果你愿意，你甚至可以对简单的错误修复进行分支。如果您的分支很忙，您可以git branch从本质上为您的紧急错误修复制作一个临时迷你版，将这个新分支合并到完成后，然后合并回您的正常分支。完成后只需删除临时分支。productionstagingstagingproductionproductionstaging

有时会出现的一种情况是：你想做一个紧急补丁，但你正处于开发过程中，你不想制作一个新的克隆并检查staging它。在这种情况下，您可以使用git stash来保存您的工作，然后签出您想要的分支，修复错误，然后返回development分支并git stash pop获取最后一个存储并恢复您的工作。

于 2013-02-09T23:12:42.730 回答
0

git 可以很容易地在不同版本的代码之间切换，因此从技术上讲，您不需要多个副本。您可以在开发时创建一个dev包含所有杂乱提交的分支。您甚至可以创建专门针对特定错误功能或功能实现的分支。当您完成某个稳定状态时，您可以将分支合并到master分支中。然后，每当您需要“干净副本”时，您只需签出master分支即可。如果您确实想要一个单独的干净副本，您可以简单地克隆您正在工作的仓库或将您的主分支从本地仓库推送到远程仓库。

于 2013-02-09T23:07:02.173 回答