Как создать gitignore visual studio

Обновлено: 02.07.2024

Какие файлы следует включать .gitignore при использовании Git в сочетании с решениями Visual Studio ( .sln ) и Projects?

Я превратил это в вики сообщества и объединил все существующие ответы в посте. Пожалуйста, внесите свой вклад, как вы считаете нужным! Я был бы осторожен, игнорируя .exe и .pdb, вы можете непреднамеренно игнорировать инструменты, которые вы храните вместе с вашим источником (nant, nunit gui и т. Д.). Пожалуйста, обратите внимание. Этот файл содержит запись для игнорирования опубликованных файлов. Как бы ни было написано правило, оно будет игнорировать любую папку, которую вы назвали «Опубликовать», и поэтому будет игнорировать все, что у вас есть под ним. Он не предназначен специально для выходных данных Visual Studio «Публикация». Это будет игнорировать это, но и другие вещи. @starfighterxyz, если вы считаете, что в gitignore есть ошибка, я бы порекомендовал создать запрос на извлечение. Ну, я не знаю (достаточно?), Чтобы сказать, что это ошибка. Я просто использовал публикацию / как имя контроллера и как имя папки проекта. Я думаю, что это просто крайний случай. Просто кое-что, чтобы сэкономить несколько часов вашей жизни :)

20.08.2014, вот файл, созданный для Visual Studio + Windows.

В идеале это будет включать в себя лицензию внутри файла. (В идеале это будет лицензия, которая не вызывает вопросов в корпоративной среде.) @DrewNoakes: Какие файлы ReSharper, по вашему мнению, должны контролироваться ревизиями? @PerLundberg Одной из причин, заслуживающих рассмотрения, является возможность настройки стандартных параметров форматирования проекта и т. Д., А также сохранение файлов конфигурации вместе с проектом. Если это в git, то всем, кто использует Resharper, будет легче поддерживать согласованный формат проекта.

Для тех, кто интересуется тем, что Microsoft считает необходимым включить в gitignore, вот вариант по умолчанию, который Visual Studio 2013 RTM автоматически генерируется при создании нового Git-репозитория:

Хотя вы должны хранить файл NuGet packages.config, вы должны исключить папку пакетов:

Обычно я не храню двоичные файлы или что-либо, сгенерированное из моего источника, в системе контроля версий. Однако существуют разные мнения по этому поводу. Если это облегчит вашу систему сборки, сделайте это! Однако я бы сказал, что вы не управляете этими зависимостями, поэтому они просто займут место в вашем хранилище. На мой взгляд, лучшее решение - хранить двоичные файлы в центральном месте, а затем полагаться на файл packages.config, чтобы указать, какая версия нужна.

Кто-нибудь хочет уточнить, почему вы хотите исключить папку пакетов? не имеет ли смысла включать пакеты для сервера сборки, чтобы иметь зависимости? Стоит отметить, что команда NuGet реализовала функцию «восстановления пакета» именно для этой проблемы. На сайте NuGet есть документ, который объясняет эту функцию и описывает, как ее использовать в Visual Studio. Если вы игнорируете пакеты и используете восстановление пакетов nuget, полезно разрешить nuget.exe. Когда кто-то загружает, это говорит VS помогает сказать, что функция включена для решения: !NuGet.exe <- не игнорируйте этот файл. Для тех из вас, кто использует AppHarbor, стоит отметить, что исключение папки пакетов приведет к сбою развертывания вашей сборки :)

Я предпочитаю исключать вещи по мере необходимости. Вы не хотите, чтобы дробовик исключал все со строкой "bin" или "obj" в названии. По крайней мере , обязательно следуйте за ними с косой чертой.

Вот что я начинаю с проекта VS2010:

И только потому, что я использую ReSharper, также это:

Согласен. Кроме того, это идет для «отладки». Добавьте косую черту к этому, чтобы избежать игнорирования файлов с отладкой в имени.

Я понимаю, что это старый вопрос, по-прежнему делиться информацией. В Visual Studio 2017 вы можете просто щелкнуть правой кнопкой мыши файл решения и выбрать « Добавить решение в систему контроля версий».

Это добавит два файла в вашу исходную папку.

Это самый простой способ.

В Visual Studio 2015 с обновлением 3 и с расширением Git, обновленным на сегодняшний день (2016-10-24), .gitignore, сгенерированный Visual Studio:

Мне понравилась эта часть: Backup & report files from converting an old project file to a newer Visual Studio version. Backup files are not needed, because we have git ;-)

В Visual Studio 2015 Team Explorer> Локальные репозитории Git> Проект> Настройки> Git> Настройки репозитория> Игнорировать и файлы атрибутов. Вы можете добавить файл .gitignore с элементами, которые по умолчанию игнорируются в решениях Visual Studio.

Добавленный InstallShield игнорирует развертывание сборки. InstallShield - это новое направление, которое Microsoft возглавляет над установщиком Visual Studio, поэтому мы начали использовать его во всех новых проектах. Эта добавленная строка удаляет установочные файлы SingleImage. Другие типы InstallShield могут включать распространение DVD среди других. Вы можете добавить эти имена каталогов или просто [Ee] xpress / для предотвращения попадания любых файлов установки InstallShield LE в репозиторий.

Я цитирую комментарий Джеймса Грегори здесь: «Я был бы осторожен, игнорируя файлы .exe и .pdb, вы можете непреднамеренно игнорировать инструменты, которые вы храните вместе с вашим источником (nant, nunit gui и т. Д.). - Джеймс Грегори 21 мая 2010 года в 13:32 " Просто пояснение - это фактически перенос BACK в InstallShield, который существовал до установки VisualStudio, по крайней мере, еще в 1998 году!

Я знаю, что это старая ветка, но для новых и старых, которые посещают эту страницу, существует веб-сайт gitignore.io. который может генерировать эти файлы. Поищите «visualstudio» при входе на сайт, и он сгенерирует эти файлы для вас, также вы можете иметь несколько языков / идентификаторов, игнорируя файлы, объединенные в один документ.

Вот выдержка из .gitignore недавнего проекта, над которым я работал. Я извлек те, которые, как я считаю, связаны с Visual Studio, включая результаты компиляции; это кроссплатформенный проект, поэтому существуют различные другие правила игнорирования для файлов, созданных другими системами сборки, и я не могу гарантировать, что я точно их выделил.

Возможно, этот вопрос должен быть вики-сообщества, так что мы все можем редактировать один общий список с комментариями о том, какие файлы следует игнорировать для каких типов проектов?

См. Комментарий Джеймса Грегори к другому ответу: «Я был бы осторожен, игнорируя файлы .exe и .pdb, вы можете непреднамеренно игнорировать инструменты, которые вы храните вместе с вашим источником (nant, nunit gui и т. Д.). - Джеймс Грегори 21 мая '10 в 13:32 " @JimRaden В общем, лучше не проверять двоичные инструменты в Git. Лучшая практика - проверять только ваш источник на Git; если вам нужны бинарные инструменты, включите скрипт для их установки или субмодуль только с этими инструментами.

Благодарим Дженса Леманна за это - если вы храните исходные каталоги отдельно от файлов проекта компилятора и строите выходные данные, вы можете упростить ваш .gitignore, отрицая его:

Вы не говорите, какой язык (языки) вы используете, но вышесказанное должно работать для проектов C ++.

Я не знал, что в .gitignore был флаг отрицания. Полезный совет!

Опоздал на вечеринку здесь, но я также обнаружил, что я использую следующее. Некоторые могут быть полезны только для сокрытия конфиденциальных файлов при передаче на общедоступный пульт.

В последней версии не нужно явно игнорировать nuget.exe

Если вы используете dbproj в своем решении, вам нужно добавить следующее:

В Visual Studio есть ярлык , потому что он поддерживает Git из коробки в 2015 году или выше. Для новых решений (или некоторых, у которых нет .git папки) используйте функции контроля версий в обозревателе решений. :

Щелкните правой кнопкой мыши по вашему решению и выберите Add Solution to Source Control. пункт во всплывающем меню.

Он автоматически инициализирует .git репозиторий, добавляет .gitignore необходимые вещи в ваше решение и даже .gitattributes файл (окончания строк и т. Д.).

Текст появится в консоли VS:

Это в значительной степени подход MS, который использует встроенный тестер Visual Studio и проект, который также может иметь некоторые привязки TFS.

Как упомянуто другим автором, Visual Studio генерирует это как часть своего .gitignore (по крайней мере для MVC 4):

Поскольку ваш проект может быть вложенной папкой вашего решения, а файл .gitignore хранится в корне решения, это на самом деле не затронет файлы локальной базы данных (Git видит их в projectfolder/App_Data/*.mdf ). Чтобы учесть это, я изменил эти строки так:

На самом деле, git также соответствует шаблонам, относящимся к подкаталогам, если только вы не начинаете их с " / ", и в этом случае они соответствуют только вещам в том же каталоге, что и .gitignore файл.

Некоторые проекты могут захотеть добавить *.manifest в свой файл Visual Studio gitignore.io .

Это связано с тем, что некоторые свойства проектов Visual Studio новых проектов настроены для создания файла манифеста.

Но если вы сгенерировали их, и они статичны (не меняются с течением времени), рекомендуется удалить их из .gitignore файла.

Это то, что проект, как Git для Windows (для Git 2.24, Q4 2019)

.gitignore : перестать игнорировать .manifest файлы

В Windows можно встраивать дополнительные метаданные в исполняемый файл, связывая его в «манифесте», то есть в XML-документе, описывающем возможности и требования (например, минимальная или максимальная версия Windows).
Предполагается, что эти XML-документы будут храниться в .manifest файлах.

По крайней мере, некоторые версии Visual Studio автоматически генерируются .manifest файлы, когда ни одна не указана явно, поэтому мы обычно просили Git игнорировать их.

Тем не менее, у нас теперь есть красивый .manifest файл: compat/win32/git.manifest так что Visual Studio не генерирует для нас и автоматически, и мы не хотим, чтобы Git больше игнорировал .manifest файлы.

Вы можете создать или отредактировать файл .gitignore для своего репозитория, перейдя в представление «Настройки» в Team Explorer и выбрав «Настройки репозитория». Выберите Edit для вашего .gitignore.

Он автоматически создает фильтры, которые игнорируют все директории сборки VS и т. Д.

Git является интерфейсом системы управления версиями по умолчанию в Visual Studio. Мы продолжаем расширять набор возможностей Git, постоянно анализируя результаты и учитывая ваши отзывы. Дополнительные сведения о недавно обновленных компонентах и ссылки на опрос, через который вы можете оставить свой отзыв, см. в записи блога, посвященной поддержке нескольких репозиториев в Visual Studio.

Теперь GIT является интерфейсом системы управления версиями по умолчанию в Visual Studio 2019. Начиная с версии 16.6 мы работаем над созданием набора функций на основе ваших отзывов. В версии 16.8 Git стал интерфейсом управления версиями по умолчанию для всех.

Мы продолжаем расширять набор возможностей Git в Visual Studio 2022. Дополнительные сведения о последнем обновлении компонентов см. в записи блога Поддержка нескольких репозиториев в Visual Studio.

Дополнительные сведения о Git

Использование GIT в Visual Studio

Мы подробно расскажем вам о том, как использовать новый интерфейс Git в Visual Studio. Однако если вы хотите сначала ознакомиться с кратким обзором, посмотрите следующее видео:

Длительность видео: 05:27 мин.

Существует три способа начать использование Git в Visual Studio для повышения производительности:

. Если ваш код не связан с GIT, можно создать новый репозиторий GIT. . Если код, с которым вы хотите работать, не находится на вашем компьютере, можно клонировать любые существующие удаленные репозитории. . Если у вас уже есть код на компьютере, его можно открыть с помощью пункта меню Файл > Открыть > Решение/проект (или Папка). Visual Studio автоматически определяет, имеется ли инициализированный репозиторий GIT.

Начиная с версии 16.8 Visual Studio 2019 включает полностью интегрированный интерфейс для работы с учетными записями GitHub. Теперь вы можете добавить в цепочку ключей учетные записи GitHub и GitHub Enterprise. Вы сможете добавлять и использовать их так же, как и учетные записи Майкрософт. Это позволит упростить доступ к ресурсам GitHub в Visual Studio. Дополнительные сведения см. на странице Работа с учетными записями GitHub в Visual Studio.

Visual Studio включает полностью интегрированную учетную запись GitHub. Вы не только можете добавить учетные записи GitHub и GitHub Enterprise в цепочку ключей, но и использовать их так же, как учетные записи Майкрософт. Дополнительные сведения см. на странице Работа с учетными записями GitHub в Visual Studio.

Создание репозитория GIT

Если ваш код не связан с GIT, можно начать с создания нового репозитория GIT. Подробные сведения см. в разделе Создание репозитория в Visual Studio.

Если ваш код не связан с GIT, можно начать с создания нового репозитория GIT. Для этого в строке меню выберите GIT > Создать репозиторий GIT. Затем в диалоговом окне Создание репозитория GIT введите свои данные.

Независимо от того, является ли репозиторий общедоступным или частным, лучше создать удаленную резервную копию кода, которая будет безопасно храниться в GitHub, даже если вы работаете сами по себе. Это также позволит вам получать доступ к коду с любого компьютера.

Вы можете создать исключительно локальный репозиторий GIT, выбрав параметр Только локальный. Вы также можете связать локальный проект с любым существующим пустым удаленным репозиторием, размещенным в Azure DevOps или у любого другого поставщика Git, с помощью параметра Существующий удаленный репозиторий.

Клонирование существующего репозитория GIT

В Visual Studio процесс клонирования прост. Пошаговые инструкции см. в разделе Клонирование репозитория в Visual Studio.

В Visual Studio процесс клонирования прост. Если вы знаете URL-адрес репозитория, который нужно клонировать, можно вставить его в разделе Расположение репозитория, а затем выбрать место на диске, в которое будет клонирован репозиторий.

Если вы не знаете URL-адрес репозитория, в Visual Studio можно легко перейти к существующему репозиторию GitHub или Azure DevOps и выбрать его.

Открытие существующего локального репозитория

После клонирования или создания репозитория GIT Visual Studio обнаружит его и добавит в список Локальные репозитории в меню GIT.

В нем можно быстро открывать репозитории GIT и переключаться между ними.

Просмотр файлов в обозревателе решений

При клонировании репозитория или открытии локального репозитория Visual Studio переключается в этот контекст GIT, сохраняя и закрывая все ранее открытые решения и проекты. Обозреватель решений загружает папку в корне репозитория Git и проверяет дерево каталогов на наличие просматриваемых файлов. К ним относятся такие файлы, как CMakeLists.txt или файлы с расширением SLN.

Visual Studio настраивает представление в зависимости от файла, загруженного в обозреватель решений:

При клонировании репозитория, содержащего один SLN-файл, обозреватель решений напрямую загружает это решение.
Если обозреватель решений не обнаруживает файлов SLN в репозитории, по умолчанию он загружает представление папки.
Если репозиторий содержит несколько файлов SLN, то обозреватель решений выводит список доступных представлений для выбора.

Переключаться между текущим представлением и списком представлений можно с помощью кнопки Переключить представления на панели инструментов обозревателя решений.

Окно "Изменения GIT"

GIT отслеживает изменения файлов в репозитории в процессе работы и разделяет файлы на три категории. Это те же изменения, которые отображаются при вводе команды git status в командной строке.

Файлы без изменений: эти файлы не были изменены с момента последней фиксации.
Измененные файлы: эти файлы изменились с момента последней фиксации, но еще не были подготовлены для следующей фиксации.
Промежуточные файлы: эти файлы содержат изменения, которые будут добавлены в следующую фиксацию.

В процессе работы Visual Studio отслеживает изменения в файлах проекта в разделе Изменения окна Изменения GIT.

Когда вы будете готовы подготовить изменения, нажмите кнопку + (плюс) для каждого из файлов, которые необходимо подготовить, или щелкните файл правой кнопкой мыши и выберите пункт Промежуточно сохранить. Можно также подготовить все измененные файлы одним щелчком мыши, используя кнопку "Промежуточно сохранить все" ( + ) в верхней части раздела Изменения.

При подготовке изменения Visual Studio создает раздел Подготовленные изменения. Только изменения из раздела Подготовленные изменения добавляются к следующей фиксации, которую можно выполнить, выбрав команду Зафиксировать промежуточные. Эквивалентная команда для этого действия — git commit -m "Your commit message" . Можно также отменить подготовку изменений, нажав кнопку – (минус). Эквивалентная команда для этого действия — git reset <file_path> для отмены размещения одного файла или git reset <directory_path> для отмены размещения всех файлов в каталоге.

Выбор существующей ветви

В Visual Studio текущая ветвь отображается в селекторе в верхней части окна Изменения GIT.

Текущая ветвь также доступна в строке состояния в правом нижнем углу интегрированной среды разработки Visual Studio.

В обоих местах можно переключаться между имеющимися ветвями.

Создание ветви

Можно также создать новую ветвь. Эквивалентная команда для этого действия — git checkout -b <branchname> .

Чтобы создать ветвь, достаточно ввести ее имя и указать существующую ветвь, на основе которой будет создана данная.

В качестве базовой можно выбрать существующую локальную или удаленную ветвь. Если флажок Извлечь ветвь установлен, вы автоматически переключитесь на новую ветвь после ее создания. Эквивалентная команда для этого действия — git checkout -b <new-branch><existing-branch> .

Окно "Репозиторий GIT"

В Visual Studio имеется новое окно Репозиторий GIT, в котором представлены все сведения о репозитории, включая все ветви, удаленные репозитории и журналы фиксации. Открыть это окно можно из меню GIT или Вид либо непосредственно из строки состояния.

Управление ветвями

При выборе в меню GIT пункта Управление ветвями отображается древовидное представление ветвей в окне Репозиторий GIT. В левой области можно использовать контекстное меню для извлечения, создания, объединения ветвей, перемещения изменений из одной ветви в другую, отбора изменений и других действий. Щелкнув ветвь, можно просмотреть ее журнал фиксаций в правой области.

При принесении ветви в окне Изменения GIT под раскрывающемся списком ветвей отображается индикатор, который показывает количество фиксаций, которые не были вытянуты из удаленной ветви. Он также показывает число локальных фиксаций, которые не были отправлены.

Сведения о фиксации

Разрешение конфликтов слияния

Во время слияния могут возникать конфликты, если два разработчика изменяют одни и те же строки в файле и GIT неизвестно, какой вариант правильный. В этом случае GIT прерывает слияние и сообщает о конфликтном состоянии.

Дополнительные сведения о конфликтах слияния и способах их обработки см. на странице Устранение конфликтов слияния.

В Visual Studio можно легко выявлять и устранять конфликты слияния. Во-первых, в верхней части окна Репозиторий GIT имеется золотистая информационная панель.

Но если ни одно из этих окон не открыто и вы переходите к файлу с конфликтами слияния, вам не придется искать следующий текст:

Редактор слияния

Редактор слияния в Visual Studio позволяет выполнять трехстороннее сравнение: в нем приводятся входящие изменения, текущие изменения и результат слияния. С помощью панели инструментов вверху редактора слияния можно переходить между конфликтами и просматривать результаты автоматического слияния в файле.

Настройка параметров GIT

Чтобы настроить параметры GIT на уровне репозитория, а также на глобальном уровне, выберите в строке меню пункты GIT > Параметры или Сервис > Параметры > Управление исходным кодом. Затем выберите нужные параметры.

Использование всех возможностей Team Explorer в Visual Studio

Новый интерфейс GIT — это система контроля версий по умолчанию в Visual Studio 2019 начиная с версии 16.8. Однако при желании этот интерфейс можно отключить. Чтобы вернуться в Team Explorer для Git, выберите Средства > Параметры > Среда > Функции предварительной версии и снимите флажок Новый пользовательский интерфейс Git.

Что дальше?

Хотя новый интерфейс Git теперь включен по умолчанию в Visual Studio 2019 начиная с версии 16.8, мы продолжаем добавлять новые функции для его совершенствования. Чтобы ознакомиться с новыми обновлениями интерфейса Git в предварительном выпуске, скачайте и установите его со страницы Visual Studio 2022, предварительная версия.

Мы продолжаем добавлять новые функции для расширения возможностей Git в Visual Studio. Дополнительные сведения о недавно обновленных компонентах и ссылки на опрос, через который вы можете оставить свой отзыв, см. в записи блога, посвященной поддержке нескольких репозиториев в Visual Studio.

Если у вас есть предложение, отправьте его нам. Мы будем рады вашему участию в работе над решением на портале Сообщества разработчиков.

Not every file created or updated in your code should be committed to Git. Temporary files from your development environment, test outputs, and logs are all examples of files that you create but aren't part of your codebase. Customize which files Git tracks through the gitignore feature.

In this tutorial you learn how to:

Use gitignore to prevent tracking of files
Ignore files only on your system
Ignore files across all repos on your system
Ignore changes to committed files

Use gitignore to prevent tracking of files

Create a .gitignore file in your Git repo to prevent Git from staging unwanted files. Share .gitignore in the default branch in your repo. You and your team can update the file to change which types of files to ignore.

Create a .gitignore

If you're using Visual Studio 2019 version 16.8 or later, try the Git version control experience. Learn more about how the Git experience compares with Team Explorer on this Side-by-side comparison page.

Visual Studio automatically creates a .gitignore file in your repo when you create new repo for your project.

Download a template .gitignore file for your project type and customize it to meet your needs. If your project doesn't fit a template, you can create an empty .gitignore from the command line. Go to your Git repo and run one of the following commands, using your repository information:

Windows

Linux and macOS

Git applies .gitignore to the folder and any child folders where it's located. We recommend you place your .gitignore in the root folder of your repo to prevent confusion.

Customize your .gitignore

Modify your .gitignore to include files types, paths, and file patterns in your repo. Git starts ignoring these files as soon as you update .gitignore. If others on your team need the same set of ignored files, be sure to commit your changes.

You can edit your .gitignore file for your repo by going to the Settings view in Team Explorer, then selecting Repository Settings. Select Edit for your .gitignore.

Use a text editor, such as the following example that uses Vim:

Each line in the .gitignore excludes a file or set of files that match a pattern. The full gitignore syntax is very flexible. Here are some examples of the most common entries:

Windows users: All file paths in the .gitignore file use a forward slash separator, not a backslash.

Ignore files only on your system

Your .gitignore is shared across team members as a file committed and pushed to the Git repo. To exclude files only on your system, edit the .git/info/exclude file in your local repo. Changes to this file aren't shared with others. They apply only to the files in that repo. The syntax for this file is the same as the one used in .gitignore.

Ignore files across all repos on your system

Set up a global .gitignore for use across all repos on your system using the command line git config tool, as in the following example:

This approach is useful for ignoring entire file types you don't want to ever commit, such as compiled binaries.

Ignore changes to committed files

Temporarily ignore changes

During development, it's convenient to stop tracking file changes to a file committed into your git repo. This approach is useful when you customize settings or configuration files that are part of your project source for your own work environment.

Resume tracking files with the following command:

Instead, you can use the following parameters. These parameters are primarily for marking files that should not be changed by developers.

To disable change tracking:

To resume change tracking:

Permanently stop tracking a file

If a file is already tracked by Git, .gitignore doesn't apply. Git will continue to track changes to that file.

If you want to stop tracking a file, you need to explicitly tell Git you want it removed from tracking. By following these directions, the file will remain in your local working directory but will no longer be tracked in Git.

Add the file in your .gitignore .

Run the following command:

Commit the removal of the file and the updated .gitignore to your repo.

Which files should I include in .gitignore when using Git in conjunction with Visual Studio Solutions ( .sln ) and Projects?

22 Answers 22

Please note. This file contains an entry to ignore published files. However the way the rule is written, it will ignore Any folder you have called "Publish", and will there fore ignore anything you have under neath it. It does not specifically target the Visual Studio "Publishing" output. It will ignore it, but also other things. @starfighterxyz if you think there is a bug in the gitignore, I would recommend creating a pull request. Well, I dont know (enough?) to say its a bug. I just happend to be using Publish/ as a Controller name, and as Project Folder names. I think this is just an edge case. Just something to save a few hours of your life :) Any idea why Windows specific files like Thumbs.db and Desktop.ini are not listed in the file from the mentioned link?

On 8/20/2014, here's the file that is generated for Visual Studio + Windows.

Ideally, it would include a license inside the file. (Ideally, that would be a license that raises no questions in a corporate environment.) @DrewNoakes: What are the ReSharper files that you believe should be revision controlled? @PerLundberg One reason worth considering is you can configure standard project formatting options, etc, and save the config files with the project. If this is in git, it makes it easier for everyone using Resharper to keep the project formatted consistently.

For those interested in what Microsoft thinks should be included in the gitignore, here's the default one which Visual Studio 2013 RTM automatically generates when creating a new Git-Repository:

While you should keep your NuGet packages.config file, you should exclude the packages folder:

I typically don't store binaries, or anything generated from my source, in source control. There are differing opinions on this however. If it makes things easier for your build system, do it! I would however, argue that you are not versioning these dependencies, so they will just take up space in your repository. Storing the binaries in a central location, then relying on the packages.config file to indicate which version is needed is a better solution, in my opinion.

I understand this is an old question, still sharing an information. In Visual Studio 2017, you can just right click on the solution file and select Add solution to source control

This will add two files to your source folder.

This is the easiest way.

How do you view those files in Visual Studio? they are created in the solution folder but not visible in the solution explorer

I prefer to exclude things on an as-needed basis. You don't want to shotgun exclude everything with the string "bin" or "obj" in the name. At least be sure to follow those with a slash.

Here's what I start with on a VS2010 project:

And only because I use ReSharper, also this:

Agree. Also, this goes for "debug". Add the trailing slash to this to avoid ignoring files with debug in the name.

In Visual Studio 2015 Team Explorer > Local Git Repositories > Project > Settings > Git > Repository Settings > Ignore & Attribute Files.You can add .gitignore file with items should be ignored in visual studio solutions by default.

On Visual Studio 2015 Update 3, and with Git extension updated as of today (2016-10-24), the .gitignore generated by Visual Studio is:

I loved this part: Backup & report files from converting an old project file to a newer Visual Studio version. Backup files are not needed, because we have git ;-)

Added InstallShield ignores for the build deployment. InstallShield is the new direction Microsoft is headed over Visual Studio Installer, so we've started using it on all new projects. This added line removes the SingleImage installation files. Other InstallShield types may include DVD distribution among others. You may want to add those directory names or just [Ee]xpress/ to prevent any InstallShield LE deployment files from getting into the repo.

I know this is an old thread but for the new and the old who visit this page, there is a website called gitignore.io which can generate these files. Search "visualstudio" upon landing on the website and it will generate these files for you, also you can have multiple languages/ides ignore files concatenated into the one document.

Here's an extract from a .gitignore on a recent project I was working on. I've extracted the ones that I believe are related to Visual Studio, including the compilation outputs; it's a cross platform project, so there are various other ignore rules for files produced by other build systems, and I can't guarantee that I separated them out exactly.

Perhaps this question should be Community Wiki, so we can all edit together one master list with comments about which files should be ignored for which types of project?

Credit to Jens Lehmann for this one - if you keep source directories separate to your compiler project files and build output, you could simplify your .gitignore by negating it:

You don't say what language(s) you're using, but the above should work for C++ projects.

Late to the party here, but I also find that I use the following. Some may only be useful for hiding sensitive files when pushing to a public remote.

Latest version does not need to explicitly unignore nuget.exe

Open Visual Studio and the solution needing an ignore file. From the top menu select Git > Settings.

The above will open Visual Studio’s Options with Source Control > Git Global Settings selected. From the list on the left select Git Repository Settings and then click the Add button for Ignore file.

The above will add a .gitignore file with all the proper files ignored for a typical Visual Studio setup.

If you are using a dbproj in your solution you will want to add the following:

You can create or edit your .gitignore file for your repo by going to the Settings view in Team Explorer, then selecting Repository Settings. Select Edit for your .gitignore.

It automatically creates filters that will ignore all the VS specific build directories etc.

More info have a look here.

There is a shortcut in Visual Studio, because it supports Git out of the box in 2015 or above. For new solutions (or some which don't have .git folder) use source control features in Solution Explorer:

Right-click on your solution and select Add Solution to Source Control. item in the popup menu.

It automatically initializes .git repository, adds .gitignore with necessary things to your solution and even .gitattributes file (line endings, etc.).

The text will appeared in the VS console:

This is pretty much an all MS approach, that uses the built in Visual Studio tester, and a project that may have some TFS bindings in there too.

As mentioned by another poster, Visual Studio generates this as a part of its .gitignore (at least for MVC 4):

Since your project may be a subfolder of your solution, and the .gitignore file is stored in the solution root, this actually won't touch the local database files (Git sees them at projectfolder/App_Data/*.mdf ). To account for this, I changed those lines like so:

It should depend on the project or language you are using. So extensions related to build, vs folder , sln file , bin folder etc are to be included. For full list of git ignore files you can check this repo gitignore for visual studio

Some project might want to add *.manifest to their visual studio gitignore.io file.

That is because some Visual Studio project properties of new projects are set to generate a manifest file.

But if you have generated them and they are static (not changing over time), then it is a good idea to remove them from the .gitignore file.

That is what a project like Git for Windows just did (for Git 2.24, Q4 2019)

Читайте также: