我们如何对 JavaScript 文件进行版本控制答案

【问题标题】：How can we version our JavaScript files我们如何对 JavaScript 文件进行版本控制
【发布时间】：2017-09-07 06:04:04
【问题描述】：

上下文：我们正在使用许多 JavaScript 文件在 Windows 操作系统（VS 2017，VS Code）上工作，例如：在“控件”文件夹中，我们将有 control1.js、control2.js 等（不同的人从事不同的工作控制）。

|- controls
     |- control1.js
     |- control2.js

On the 'apps' folder we will have : 

|-apps
    |- app1
        |- view.js
        |- controller.js
        |- model.js
    |- app2
        |- view.js
        |- controller.js
        |- model.js

现在，我们的想法是测试团队将/可能会发现需要修复的错误。我们将修复代码并将修复的文件（例如 control1.js）重新部署到特定的测试团队。如果另一个团队（在不同环境中工作）在同一个文件（control1.js）中报告另一个错误，我们无法知道当前环境是否有上述修复（只有代码比较会告诉我们） . 没有文件版本可以帮助我们了解问题发生的位置（在哪个版本中）以及在哪个版本中修复。

我们想要什么——（也许这个问题已经解决了，但我什么都没找到）——我们希望 @check-in-time 增加 JavaScript 文件的版本（可能是 C# 中的版本号）。
我们将 TFS（本地）和 VSTS/Git（在 visualstudio.com 上在线）用作版本控制。

如何？ - 每个 JavaScript 文件都会有某种标题（文件顶部的一个大区域，带有一些注释文本），其中包含有关公司等的一些信息......以及文件的版本，例如：1.0.2.23 . 通过这种方式，我们将知道在哪个版本中完成了修复（错误跟踪系统要求我们提及发现错误的版本以及修复的版本。

我们如何在 VS 2017 (2015) 和 VS Code 中模拟这一点？
我们能否拥有一个所有 JavaScript 文件共有的文件（与 C# 中的 AssemblyInfo.cs 相同），然后将该文件...与每个 JavaScript 文件合并？
这样，如果我们需要全局更改某些内容我们不需要...到处查找/替换？

提前谢谢你。

【问题讨论】：

标签： javascript git version-control version

【解决方案1】：

对于一个文件（如control1.js）需要多人修改的情况：

如果修复后需要测试团队对文件进行双重测试，您可以在另一个分支上修改该文件，然后由测试团队合并到当前工作分支中。
如果测试团队不测试固定文件，您可以直接在当前分支上修改文件，并将分支推送到 TFS/VSTS。之后，如果其他团队成员也需要修改同一个团队，他们可以拉取您所做的更改并根据最新版本修复文件。

对于文件的版本：

其实每次commit更改都是新版本，git会计算一个新的SHA-1校验和（commit id）如a11bef06a3f659402fe7563abf99ad00de2209e6，你可以在VS-> Team Explorer -> Branches -> 右键查看分支 -> 查看历史记录。

如果你想要一个更具可读性的版本，你可以为一个提交添加一个标签，例如在查看历史 -> 右键单击一个提交 -> 创建标签 -> 然后输入一个标签名称，如1.0.2.23。

而且您不需要单个文件来记录文件版本，因为 git 可以管理您所做的每项更改的版本。

要获取测试团队部署的版本，您可以使用以下步骤：打开发布 -> 工件 -> 找到构建定义和构建版本 -> 在构建选项卡中找到构建版本 -> 在摘要页面中您可以在 Source 版本中查找 git 版本。

【讨论】：

嗨 Marina - 感谢您的快速回答，但这并不能真正解决问题，因为一旦部署了应用程序，我们就无法知道每个测试团队正在运行的版本。我们需要的正是 C# 对 AssemblyInfo.cs 所做的事情，并且每次编译都会增加程序集的发布版本。我们知道 JavaScript 中没有编译步骤 - 这就是为什么我建议将签入时间作为文件将被增加版本标记的点。现在，我们如何才能做到这一点？
应用部署后可以找到版本，我在回答中添加了方式。
现在能找到版本吗？答案是否帮助您解决了问题？
Marina，正如我所说，解决方案对我们没有帮助，但我认为这是由“通信故障”引起的 :-)。长话短说：当报告错误时，我们会调试远程系统并在某个 .js 文件中查明它。从该文件的标题（应该包含一些公司信息、代码哈希和代码版本）我们可以提交一个错误，上面写着：“文本框”控制版本 Mmrb 在按两次键时出现错误 ;-) 。然后我们可以继续修复错误并将“已解决”状态与已解决的版本一起归档。是否缩小文件 - 我们会做出反应同样的方式。
作为这种行为的解决方案，我认为我可能会与 git 的钩子集成。所以，我正在考虑做同样的事情，你可以用 ESLint 做，在签入时代码被 linted。现在，在我们的例子中，在成功 linting 之后，我们继续使用必要的信息解析-find-increment 或 parse-injectNew 标头。我并不是说我已经建立了这个机制，但这就是它的要点。现在，您如何看待这种方法？（这里的限制是该机制绑定到 Git 控制系统 - 这不是 100% OK）。

【解决方案2】：

我们使用形成为<major>.<minor>.<changeset>-<buildid>-<branch> 的版本来跟踪部署的版本。在每次部署自定义 IIS 响应标头字段时，“X-Release”都会更新版本号，以便 QA/PM 始终可以检查他们在开发人员工具中使用的代码版本：

但是，我们正在使用 Octopus Deploy，因此无法在 TFS 版本中说明如何执行此操作。

【讨论】：