如何在Git中记录Web项目的发布历史记录？(How to record a history of releases for a web project in Git?)

如何在Git中记录Web项目的发布历史记录？(How to record a history of releases for a web project in Git?)

我正在研究一个经常合并并发布到生产中的Web项目。 我希望存储库包含所有被推送到生产服务器上的所有内容的完整记录，主要是为了让我可以分析三周前的错误日志条目，确切知道当时生产的代码是什么。

我不能使用release分支，因为在Git中，没有关于特定分支的提交历史的概念。 我们目前使用release分支，但它无法让我回答“三周前生产的代码是什么”的问题。

那么，我应该如何在Git中做到这一点？

I'm working on a web project with frequent merges and releases into production. I'd like the repository to contain a full record of everything that was ever pushed onto the production server, mainly so that I can analyse an error log entry from three weeks ago knowing exactly what code was in production at that time.

I cannot use a release branch for this because in Git, there is no concept of a history of commits made on a specific branch. We do use a release branch currently, but it does not enable me to answer the question of "what code was in production three weeks ago".

So, how should I do this in Git?

最满意答案

标签适用于git上的这种用途。 你可以在这里阅读标签。

根据您的问题，您可以拥有所有标签的列表，从而了解已发布的内容。 git scm-book上的这个例子是：

$ git tag -l 'v1.4.2.*' v1.4.2.1 v1.4.2.2 v1.4.2.3 v1.4.2.4

签出特定标签会使您处于与发布代码时完全相同的条件。

您甚至可以在标签上签名，这可能对共享存储库有帮助，如果您打扰任何人混淆（无论是故意还是偶然）。

请注意：

默认情况下，git push命令不会将标记传输到远程服务器。 在创建标记后，您必须明确地将标记推送到共享服务器。 这个过程就像共享远程分支一样 - 你可以运行git push origin [tagname]。

因为如果你认为这样做会导致严重的头痛。

就像在git中一样，你真正需要的只是提交的sha，所以根据你的需要写下来就足够了。

Tags are intended for this kind of use on git. You can read about tags here.

As per your question, you can have a list of all tags, hence knowing what has been released. The example for this on git scm-book is:

$ git tag -l 'v1.4.2.*' v1.4.2.1 v1.4.2.2 v1.4.2.3 v1.4.2.4

Checking out a specific tag would put you in the exact same condition as when the code was released.

You can even GPG sign the tags, which can be helpful in a shared repository, should you bother about anybody mixing things up (either on purpose or by accident).

Please note that:

By default, the git push command doesn’t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them. This process is just like sharing remote branches — you can run git push origin [tagname].

as this could result in a terrible headache if you assumed it did.

As always in git, all you really need is the sha of the commit, so that writing that down could be sufficient, depending on your needs.