Игнорирование файлов из проверки с определенным шаблоном изменения
С тех пор, как я начал использовать Аннотации JetBrains, для себя лично я украсил все методы с помощью [CanBeNull]
или [NotNull]
Например, следующая строка:
public AccountController(IAccountService accountService)
Будет изменено на:
public AccountController([CanBeNull] IAccountService accountService)
Другим примером может быть:
public Account CreateAccountEntity(Account accountEnttity)
будет изменено на:
[CanBeNull]
public Account CreateAccountEntity([NotNull] Account accountEnttity)
Как я могу обойти ожидающие изменения для аннотаций, в частности "[CanBeNull]", и TFS полностью игнорирует это изменение?
Ответы
Ответ 1
Вы не можете заставить TFS игнорировать это изменение. Такова цель TFS - отслеживать изменения all.
Как я интерпретирую ваш вопрос, вы хотите избежать шума потенциально многих небольших, но безобидных проверок из-за ваших комментариев. Если это так, то есть способ использовать TFS, который минимизирует шум:
- создайте ветку, с которой вы сейчас работаете (назовите ее "BranchA" ), затем внесите все изменения аннотации в эту новую ветку ( "BranchB" ), регулярно проверяя их
- если это займет некоторое время (дни, недели), чтобы завершить, убедитесь, что вы регулярно слияния с BranchA на BranchB
- когда вы думаете, что закончили, завершите объединение из BranchA в BranchB. Если вы перетащили все новые методы, убедитесь, что вы их аннотируете. Повторите этот шаг, если вы внесли изменения.
- объединить все изменения из BranchB обратно в BranchA. Это приведет к объединению всех ваших небольших изменений в один большой набор проверок/изменений в BranchA. Если вы регулярно делаете регулярные слияния из BranchA в BranchB, это должно быть проблемно, даже если прошло много времени с тех пор, как вы начали работу по декорированию.
Ответ 2
Короче говоря, вы не должны, ближайшая функция tfignore, но это будет игнорировать весь файл.
С другой стороны, если вы действительно этого хотите, вы можете создать инструмент с использованием TFS API, и вам нужно будет запустить его перед регистрацией, и он проверит все ожидающие файлы в вашем решении и ищет это небольшие изменения и исключение файлов, но это может привести к тому, что в какой-то момент вы можете внести изменения в исключенный файл, и он не будет проверен и не вызовет проблем. Вам нужно будет добавить дополнительный код, чтобы проверить, какие файлы должны быть включены из исключенного списка.
Внешний инструмент, используемый внутри VS Здесь вы можете увидеть, как добавить инструменты в меню "Инструменты" и отправить ему аргументы.
Пример API TFS
В этом примере показано, как использовать TFS API. Существует "workspace.AddIgnoreFileExclusion()", но здесь у меня нет TFS, поэтому я проверю, как проигнорировать файлы позже.
Теперь, по моему опыту, единственной причиной, по которой я не хотел бы проверять эти изменения, было бы избежать конфликтов с командой.
Если я вижу большую ценность в некоторой практике, например, используя аннотации, я бы поговорил с командой, чтобы заставить их купить идею идеи использования аннотаций, таким образом, каждый будет ее использовать, и вскоре каждый файл будет содержать аннотации и конфликтов не будет.
Ответ 3
Вы не можете выборочно игнорировать изменения в файлах, в TFVC или в любом другом SCM, с которым я когда-либо встречался.
Ответ 4
Я согласен с другими ответами, что такая функция официально не поддерживается Microsoft.
Но вы также можете перезаписать TFVC в несколькими способами, если это действительно необходимо. Вы можете написать собственный подключаемый модуль Visual Studio или Source Control VSPackage.
Ответ 5
Если ваша основная цель - написать лучший код с помощью ReSharper, который говорит вам, следует ли ожидать нулевых значений или не создавать другие предупреждения, и вы не хотите беспокоить других членов команды, я бы предложил вам рассмотреть возможность использования Внешние аннотации вместо атрибутов аннотации в коде.
Затем вы можете решить, хотите ли вы зафиксировать эти файлы или сохранить их локально. И даже если вы зафиксируете свой код, все равно будет чистым без этих дополнительных атрибутов.
По крайней мере, я бы попробовал.