使用 Git 管理网站的多个版本的最佳实践是什么？
我们目前正在从 Subversion 迁移到 Git。在 Subversion 中，我们经历了分支的噩梦，完全不清楚如何找到任何内容或同步到哪个分支。基本上，每次我们将应用程序的新版本推送到生产服务器时，都会有人创建一个新分支。因此，会有一个名为 1457 的分支，其中包含该版本的所有位。然后，在构建完成后，他们将创建一个名为 1458 的新分支并开始在那里检查。当该构建准备就绪时，我们会将所有内容复制到生产中并重复。有时，会有奇怪的子版本，并且会有一个名为 1457_B 之类的分支。事情变得完全混乱了。
看起来他们也想继续使用这个系统和 Git。我认为每次发布版本时都必须“切换分支”会很烦人。似乎更好的方法是只拥有一个与当前生产中的内容同步的“主存储库”，然后拥有一个带有增量更改的“开发”分支，我可以每隔几天左右推送一次。然后，当构建准备好部署时，将开发分支合并回主分支并调用它。
我认为他们的论点是他们希望能够及时看到任何特定构建的位 - 这很奇怪，因为我实际上从未遇到过这样做的需要。使用 Git，是否有更好的方法来“标记”某个时间点，以便您可以快速查看存储库在某个检查点的存在情况？对我来说，为每个构建创建一个分支似乎有点矫枉过正。我知道这些问题有点模糊，主要是我只是在寻找此工作流程的推荐最佳实践，我确信这很常见。
We're currently in the process of migrating from Subversion to Git. In Subversion, we had this complete nightmare of branches and it was totally unclear how to find anything or what branch to sync to. Basically, someone created a new branch every time we pushed out a new version of our app to the production server. So there would be a branch called 1457 with all the bits from that build. Then, after that build was done they'd create a new branch called 1458 and start checking in there. When that build was ready, we'd copy everything out to production and repeat. Sometimes, there'd be weird sub-releases and there'd be a branch called like 1457_B or something. It got totally confusing.
It seems they want to keep using this system with Git as well. I think it would be annoying to have to "switch branches" every time we release a version. It seems a better approach would be to just have a "main repository" that's in sync with whatever currently is in production, and then have a single "Development" branch with incremental changes I can push to every few days or so. Then, when a build is ready to be deployed, merge the Development branch back into main and call it good.
I think their argument is that they want to be able to see the bits from any specific build in time - which is odd because I've never actually come across a need to do this. With Git, is there a better way to "label" a point in time so that you can quickly see a repository as it existed at a certain checkpoint? Creating a branch for each build seems like overkill to me. I know these questions are kind of vague, mainly I'm just looking for the recommended best practices for this workflow, which I'm sure is quite common.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我强烈建议研究 git 标签。使用分支意味着进一步的开发将在该线上进行。但是，如果他们想做的只是标记版本，则拥有一个“生产”分支并简单地标记版本。现在，如果他们想要同时发布多个版本，分支可能确实会派上用场。
I would strongly recommend investigating git tags. Using a branch implies that further development will happen on that line. However, if all they want to do is mark releases, have a "production" branch and simply tag the releases. Now, if they want to have multiple simultaneous releases, branches might indeed come in handy there.
Git 支持标签，标签要么是指向提交的指针，要么是带有签名、作者和显然是对提交的引用的完整对象。
因此，对于每个版本，您都会有一个描述特定时间点的标签。
拥有一个主分支和一个开发分支的方法绝对是通常的方法，这与每个版本有一个分支不同。此类分支仅在维护旧版本（例如错误修复）时才会发挥作用，但这适用于应用程序的上下文，而不是网站。
Git has support for tags, which are either pointers to commits, or full-blown objects with signature, author and obviously a reference to a commit.
So for each release you'd have a tag that describes a specific point in time.
Your approach of having a main branch and a development branch is definitely the usual approach, unlike having one branch per release. Such branches would only come into play when maintaining an older version (e.g. bug fixes), but that rather applies to the context of applications, not websites.