我坚持这个想法。
如果我开发一个应用程序，那就说一个PHP论坛或者cms。
大多数PHP论坛和CMS'都有这些东西（加上一些）：
现在这是有道理的，但我不知道如何管理开发此应用程序和版本控制。
目前我的系统上有两份应用程序副本。
一份“清洁”副本，对此没有任何影响。
一个“Dev”副本，此副本已安装并且是工作副本。
如果我修复了错误，或者在dev版本中添加了新功能，我会手动将更改复制到干净副本，提交和推送。
这非常耗时，而且在我看来并不实用。
如果应用程序说扩展程序，我在插件中安装了“dev”副本，并且我有一份干净的扩展副本，我会执行相同的过程。
有没有更好的方法来管理它？
答案 0 :(得分：1)
将所有更改和错误修正提交到dev（develop）分支;当您要发布一系列更改时，只能从develop合并到clean（master）。使用其他分支来开发特定的新功能;并使用标记来显示发布质量代码
答案 1 :(得分：1)
典型的企业工作流程看起来像这样（当然有无限变化）：
production分支包含实际已发布的所有代码。标签用于标记特定版本或版本。
A staging（或可能qa;名称相当随意）分支用于准备新版本和/或补丁。因此，如果正在进行开发但需要紧急补丁，则可以在此分支中进行，然后将其合并到production（git merge staging）中，作为部署或发布过程的一部分。
各种development分支跟踪特定的开发工作。新功能等。当它们准备好发布时，它们会合并到staging / qa等，直到它们实际发布为止。如果您的工作流程中有更多步骤，您可以在列表中添加更多分支（生产 - >分段 - ＆gt; qa - ＆gt;集成 - ＆gt;测试 - ＆gt;等），如果有必要的话。
此工作流程的想法是，您始终可以安全地从production - ＆gt;合并。 staging - ＆gt; development个分支机构。如果要将某些代码推进启动，则可以反向合并。
在git中分支是便宜的，所以如果你愿意，你甚至可以分支简单的错误修正。如果您的git branch分支正忙，您可以production staging，基本上为您的紧急错误修正临时迷你staging，将此新分支合并到production完成后，然后将production合并回正常的staging分支。只需在完成临时分支后删除它们。
有时出现的一种情况是：您想要做一个紧急补丁，但是您正处于开发过程中，并且您不想制作新的克隆并在其上查看staging。在这种情况下，您可以使用git stash保存您的工作，然后检查您想要的分支，修复错误，然后返回development分支和git stash pop以获取最后一个藏匿并恢复您的工作
答案 2 :(得分：1)
您可以删除用于测试的安装文件夹，然后使用以下命令标记已删除的文件：
git update-index --assume-unchanged [list of filenames]
并且git不会提示您将其从存储库中删除。
您可以使用：
git ls-files --deleted
列出所有已删除的文件，以便您可以使用以下命令自动删除它们：
git update-index --assume-unchanged `git ls-files --deleted`
答案 3 :(得分：0)
git可以轻松地在不同版本的代码之间切换，因此从技术上讲，您不需要多个副本。您可以在开发过程中创建一个包含所有混乱提交的dev分支。您甚至可以创建专门用于特定错误功能或功能实现的分支。当您完成某个稳定状态时，您可以将分支合并到master分支中。然后，只要您需要“干净副本”，就可以签出master分支。如果你想要一个单独的干净副本，你可以简单地克隆你正在工作的仓库，或者将你的主分支从本地仓库推送到远程仓库。