使用 Git 管理网站的多个版本的最佳实践是什么？

Question

我们目前正在从 Subversion 迁移到 Git。在 Subversion 中，我们遇到了完全的分支噩梦，完全不清楚如何找到任何东西或同步到哪个分支。基本上，每次我们将应用程序的新版本推送到生产服务器时，都会有人创建一个新分支。所以会有一个名为 1457 的分支，其中包含该构建中的所有位。然后，在构建完成后，他们将创建一个名为 1458 的新分支并开始在那里签入。当该构建准备就绪时，我们会将所有内容复制到生产环境并重复。有时，会有一些奇怪的子版本，并且会有一个名为 1457_B 之类的分支。搞得一头雾水。

他们似乎也想继续将此系统与 Git 一起使用。我认为每次发布版本时都必须“切换分支”会很烦人。似乎更好的方法是只拥有一个与当前生产中的任何内容同步的“主存储库”，然后拥有一个带有增量更改的单个“开发”分支，我可以每隔几天左右推送一次。然后，当一个构建准备好部署时，将 Development 分支合并回 main 并调用它。

我认为他们的论点是他们希望能够及时看到任何特定构建的位 - 这很奇怪，因为我从未真正遇到过这样做的需要。使用 Git，是否有更好的方法来“标记”时间点，以便您可以快速查看存储库，因为它存在于某个检查点？为每个构建创建一个分支对我来说似乎有点矫枉过正。我知道这些问题有点含糊，主要是我只是在为这个工作流程寻找推荐的最佳实践，我敢肯定这很常见。

Answer 1

我强烈建议调查 git 标签。使用分支意味着将在该行上进行进一步的开发。但是，如果他们想做的只是标记发布，请拥有一个“生产”分支并简单地标记发布。现在，如果他们想要同时发布多个版本，分支可能确实会派上用场。

Answer 2

Git 支持标签，这些标签要么是指向提交的指针，要么是带有签名、作者和显然是对提交的引用的成熟对象。

因此，对于每个版本，您都会有一个描述特定时间点的标签。

你拥有一个主分支和一个开发分支的方法绝对是常用的方法，不像每个版本只有一个分支。此类分支仅在维护旧版本（例如错误修复）时才会发挥作用，但这适用于应用程序的上下文，而不是网站。