针对Git Repo的建议,即在测试开发过程中需要能够在合并目录文件中累积文件以保护特定文件

时间:2019-02-16 05:12:51

标签: git github

我有一个git repo供我的团队使用,以跟踪模型的测试体系结构和测试用例。

在此版本库中,有一个“特殊文件”用于执行测试,因为工程师开发并测试了他们的新测试用例后,该文件将被修改。

为了合并对此文件的更改,将导出测试,然后将其添加到仓库中的合并目录中。

我当时想让多个人可以在同一分支上处理测试用例,将他们的测试用例添加到合并目录,然后在一个或多个人进行一次或多次推送之后的某个时刻,指定的人可以更新“包含新测试用例的特殊文件”,然后清除合并文件夹。

在此过程中,我有一些担忧:

  1. 我描述的过程似乎合理吗?

  2. 是否可以让测试用例编写者仅向合并文件夹添加/提交/推送更改,而不会覆盖“特殊文件”。 (与此同时,他们不应该删除此目录中的任何其他文件,我认为git add。testCases \ toBeMerged可以处理此问题,尽管我不确定是否完全如此)?

  3. 我发现,如果一个测试编写者进行了推送,那么下一个测试编写者必须先进行推送,然后才能添加更改。如果在拉动过程中忽略了本地特殊文件,那将是不好的,我该如何保护它?

  4. 有时候,测试编写者想“重新开始”,在这种情况下,如何使他们能够拉动和覆盖所有本地文件,包括特殊文件?

1 个答案:

答案 0 :(得分:0)

  

如果在拉动过程中忽略了本地特殊文件,那将是不好的,我该如何保护它?

然后...不要对其进行版本控制。它不会成为拉/合并过程的一部分,也不会受到影响/擦除。

相反:在结帐时,使用content filter driver使用 .gitattributes declaration smudge脚本部分自动生成它。

smudge (来自“ Customizing Git - Git Attributes”的图像,来自“ Pro Git book”的图像)

生成的实际文件仍然被.gitignore忽略:您的实际工作树不会“脏”。

smudge脚本:

  • 检测正确的环境(例如使用branch=$(git rev-parse --symbolic --abbrev-ref HEAD)的分支)
  • git checkout期间,根据模板选择正确的值文件(如“要合并的测试用例”)并根据模板生成