Git获取工作副本SHA

Question

我有一个包含的git仓库

• 大师（准备生产）
• 开发（合理稳定的开发部门）

我们正在使用功能分支，并且通常遵循gitflow 。

我们有很多生产服务器正在运行特定的SHA / master提交，但它们并非都在运行同一服务器，因为不同的客户端对更新有不同的需求。

这些相同的客户端还具有测试服务器，他们希望在这些服务器上试用开发分支的新功能。 这很少是HEAD。 但是通常是在开发过程中做出更强大的承诺，在该过程中，我们付出了额外的努力，以确保客户可以立即看到该软件（因此是Alpha / Beta版本，而不是原始开发版本）。

由于我们有很多服务器，因此我们具有自动部署脚本，该脚本将特定提交部署到服务器。

在原始git命令中，它将类似于以下内容（非常简化）

日期X

客户端测试服务器（已在开发分支上）：

git pull --rebase
git checkout <SPECIFIC_ALPHA_BETA_SHA> .

现在客户A正在测试和试用，并且1个月过去了，现在客户B要求发布新的试用版

日期X + 1个月 （左右）

客户端B测试服务器（已在开发分支上）：

git pull --rebase
git checkout <SPECIFIC_ALPHA_BETA_SHA_LATER_THAN_CLIENT_A> .

题

有什么方法可以获取检出的实际文件的工作副本SHA？

git rev-parse HEAD不起作用，因为它报告的是HEAD的实际修订，而不是检出的文件。

因此，如果我们假设在git pull / git checkout时间上（此处保持SHA数值仅仅是为了便于说明它们的出现顺序）

头= 999
ALPHA_BETA试用= 900

git pull --rebase (now at 999)
git checkout 900 .

如果我使用git rev-parse HEAD

它会给我999

我想要的是900。

是否有git命令可以提供检出文件的修订版本？

背景

我们最近才从Subversion转到Git，因此这个问题受到Subversion以前的实践以及对Git的工作方式可能存在的误解的影响。

对于客户端“演示/测试”服务器，我们以前使用的是修订版本号作为TAG，而不是在Subversion中实际进行标记（因为对每个客户端安装进行标记将导致我们拥有100个标记）。 作为部署给定“修订/提交/ TAG”的一部分，此修订被标记在版本文件中。

现在我们转到了git，客户端仍然要求对其“演示/测试”系统进行频繁的更新。 我们不希望将“演示/测试”系统的更新作为标签/发行版进行跟踪，而是希望继续使用“修订/ SHA”作为标签。

在版本文件中标记修订时，由于部署脚本不是“事务安全”的，因此请勿从输入的参数中获取此值到部署脚本，并且致命错误可能会将存储库保留在一个修订中，并且版本文件说明另一个修订。 因此，为确保版本文件报告了文件系统上文件的实际“修订”，我们之前已经要求修订控制系统提供工作副本当前的“修订号”。

这个问题问如何在Git中做到这一点。

Answer 1

有多种方法可以实现您的目标。 可能最“讨厌”的是使用标签，这样做很有意义。 根据您的描述，不同的客户端正在运行软件的不同“发行版”（每个发行版由SHA标识）。

任何在其他地方记录SHA的尝试都可能会导致位腐烂，纸张丢失等现象。 标记使您可以将“这是ALPHA_BETA_TRIAL_1”的信息与git存储库中的SHA紧密关联。 这样，随着时间的流逝，其他机器/用户克隆或获取更新时，它就会随代码一起传播。 在单行日志中查找相关的提交要容易得多。

从而

$ git tag -a -m "ALPHA_BETA_TRIAL_1" ALPHA_BETA_TRIAL_1
$ git push --tags

清晰地标记您的上游（从中克隆客户端）供所有人查看。

如果您确实需要SHA，那么

$ git show-ref ALPHA_BETA_TRIAL_1

就是全部。

相反，如果您将修订信息记录在提交消息中，则可以使用

$ git log --grep="Revision\:" --oneline --decorate

以获取仅在其提交消息中包含字符串“ Revision：”的那些提交的日志。 “ oneline”和“ decorate”命令将提供一个不错的密集日志输出，该输出将给出简短的SHA，提交摘要以及与模式匹配的每次提交的任何关联标签。

Answer 2

如果我的解释正确，那么您使用git checkout $SPECIFIC_ALPHA_BETA_SHA -- .做什么git checkout $SPECIFIC_ALPHA_BETA_SHA -- . 是未记录的合并，使用合并策略“从上游历史记录中的每个当前文件覆盖，同时忽略对其的删除”。 Git对此策略没有自己的名字，那又如何呢？ 这很容易，您已经在做，剩下的唯一事情就是正确记录它：

# Merge from $SPECIFIC_ALPHA_BETA_SHA using our own merge strategy:
git merge -s ours --no-commit $SPECIFIC_ALPHA_BETA_SHA

# our merge strategy:
git checkout $SPECIFIC_ALPHA_BETA_SHA -- .

# commit the result
git commit -m "Incorporating upstream"

现在git的工具包总是知道在哪里寻找相关的提交。

为自己节省一些非常流行的日志选项的输入，

git config --global alias.lgdo 'log --graph --decorate --oneline'

（ --global不会创建系统范围的别名，只有您自己，但是您可以在任何地方使用它）

列出影响签出路径内容的提交的各种方法：

git lgdo -1 --no-merges -- path/to/file  # last ordinary commit affecting path
git lgdo --no-merges -- path/to/file     # all ordinary commits affecting path
git lgdo -- path/to/file                 # above, plus full merge history

# ordinary commits as above plus all searched commits w/ branch or tag names
git lgdo --no-merges --simplify-by-decoration -- path/to/file

尽管这甚至还不是您寻找内容更改方式的开始，但我认为其中一个或多个将在此处使用。

Answer 3

对于每个客户都基于上游分支之一维护私有分支的可能性，您可能不希望git pull --rebase因为它会基于所获取分支的尖端。 代替，

git fetch                             # just fetch
git rebase $SPECIFIC_ALPHA_BETA_SHA   # rebase to specific stable commit
git merge-base @ @{u}                 # show where my history meets upstream's

为了对最后一条命令有更多的了解，您可以

git log --oneline --decorate -1 $(git merge-base @ @{u})

这将向您显示合并基础的提交主题以及该提交上的所有标签或其他引用。

Answer 4

只是想想，在经过反复试验之后，根据此处的输入，我将分享最终为我们工作的内容。

在单个客户端服务器上，当我们要针对构建脚本的特定修订版作为目标时，我们在该服务器上创建了一个新的“本地”分支。

如果我们感兴趣的修订/提交是7d65769ae9ba4ac9f92349feca8be3c70aacfcd6，那么我们运行以下命令

git checkout -b 7d65769ae9ba4ac9f92349feca8be3c70aacfcd6 7d65769ae9ba4ac9f92349feca8be3c70aacfcd6

这为我们提供了本地分支机构，其最新修订版号为7d65769ae9ba4ac9f92349feca8be3c70aacfcd6

正在运行

git rev-parse --abbrev-ref HEAD

返回预期的修订/提交（显然是7d65769ae9ba4ac9f92349feca8be3c70aacfcd6-），因此构建脚本将运行。 我们不添加任何远程跟踪（因为没有远程等效分支，并且我们不将该本地分支推送到源），因此我们不会使用分支或标记污染远程/起源，而分支或标记本质上是指向客户特定测试的指针安装。

所以总而言之-

git checkout -b <commitSHA> <commitSHA>
git rev-parse --abbrev-ref

提供与旧的subversion命令相同的结果

svn up -r <revisionNumber>
svn info -R | grep "Revision\:" | sort -k2nr | head -n1
(get revision info recursively, order by revision number desc, limit 1)

感谢您花所有时间来回答。