我希望借助git开始建模/预测任务。我想建立一个git架构来促进这一点，但我遇到了一些问题。
目标：在区域/子区域分支中的建模任务结束时（需要人工修订，人工修订=提交），合并到主人以使所有预测可用于审核它运行的代码和数据集的版本。如果以后需要进行修订，建模者应该能够从完成预测的时间开始分支，并使用正确的（可能是较旧的）版本的代码进行处理。
问题：数据和代码版本可能会发生变化。较旧的模型运行将与旧的代码/数据不兼容（例如，在区域1中，可以使用代码版本1和数据版本2，但在区域2，代码4和数据6中），并且在结束时项目，预测必须能够再现。
我的解决方案：这似乎违反了git的理念，但每次有数据集或代码更新时，请将其放在master中，并在文件名后附加一个版本号。有区域/子区域分支并标记每个预测完成提交然后当预测完成时，合并到主服务器，并添加另一个文件，说明运行代码和数据的版本。如果需要进行修订，请找到完成标记，并使用正确版本的代码进行重新构建，然后合并回区域，然后再合并到master。如果需要复制模型，请使用正确的代码/数据（来自创建的附加文件）运行它。
这是使用git跟踪此过程的最佳方式，还是有更好/更简单的方法？这个过程是否有效，或者是否存在可能因此而产生的意外问题？
答案 0 :(得分：1)
数据和代码版本可以更改
这意味着你有两组文件，具有强耦合，但在这种耦合中有自己的演变。
这是Git submodules的工作：您将代码和数据分别放在各自的git存储库中，并在主父存储库中为每个代码和数据引用固定的SHA1：
parent/
code/
data/
这样，从父级仓库开始，您可以创建一个code和data都会发生变化的分支。预测完成后，您合并到master（在父级中）的内容是code和data的最新SHA1。
子模块的兴趣在于您在父仓库中记录应该与repo仓库兼容的数据code的确切SHA1。
而且你完全避免像重命名文件一样“黑客”。