我有一个git repo供我的团队使用,以跟踪模型的测试体系结构和测试用例。
在此版本库中,有一个“特殊文件”用于执行测试,因为工程师开发并测试了他们的新测试用例后,该文件将被修改。
为了合并对此文件的更改,将导出测试,然后将其添加到仓库中的合并目录中。
我当时想让多个人可以在同一分支上处理测试用例,将他们的测试用例添加到合并目录,然后在一个或多个人进行一次或多次推送之后的某个时刻,指定的人可以更新“包含新测试用例的特殊文件”,然后清除合并文件夹。
在此过程中,我有一些担忧:
我描述的过程似乎合理吗?
是否可以让测试用例编写者仅向合并文件夹添加/提交/推送更改,而不会覆盖“特殊文件”。 (与此同时,他们不应该删除此目录中的任何其他文件,我认为git add。testCases \ toBeMerged可以处理此问题,尽管我不确定是否完全如此)?
我发现,如果一个测试编写者进行了推送,那么下一个测试编写者必须先进行推送,然后才能添加更改。如果在拉动过程中忽略了本地特殊文件,那将是不好的,我该如何保护它?
有时候,测试编写者想“重新开始”,在这种情况下,如何使他们能够拉动和覆盖所有本地文件,包括特殊文件?
答案 0 :(得分:0)
如果在拉动过程中忽略了本地特殊文件,那将是不好的,我该如何保护它?
然后...不要对其进行版本控制。它不会成为拉/合并过程的一部分,也不会受到影响/擦除。
相反:在结帐时,使用content filter driver使用 .gitattributes
declaration 的smudge
脚本部分自动生成它。
(来自“ Customizing Git - Git Attributes”的图像,来自“ Pro Git book”的图像)
生成的实际文件仍然被.gitignore
忽略:您的实际工作树不会“脏”。
smudge
脚本:
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)
的分支)git checkout
期间,根据模板选择正确的值文件(如“要合并的测试用例”)并根据模板生成。