2014-09-21 4 views
-1

Я совершенно новый для SourceTree и как-то новый для систем управления версиями. Каковы наилучшие методы использования типов файлов в вашем репозитории? Включите сторонние DLL-файлы, которые вы не меняете? Как насчет вашего окончательного скомпилированного кода или вы просто включаете исходный код? Мне не имеет смысла включать что-либо третье лицо или вашу собственную скомпилированную версию кода, но, наблюдая за некоторыми учебными материалами в Интернете, я вижу, что они включены. С другой стороны, я испытал боль в том, что мне нужно найти и загрузить библиотеки, которые разработчики предположили, когда я загрузил их проекты Git. Я подозреваю, что ответы могут отличаться в зависимости от того, на каком языке вы программируете, и есть ли у вас что-то вроде Maven или нет.sourcetree GIT - какие файлы включить, лучшие практики

Мне было поручено использовать Git для Java и C#, поэтому любая помощь в направлении того, что я должен или не должен включать, будет очень признательна.

+1

Concatonate один или два или три из них в зависимости от платформы и языка: https://github.com/GitHub/gitignore –

+0

Это отличается от проекта и мнения. –

+1

И не забывайте о выпусках tag'd. Будете ли вы включать файлы символов для отгруженных двоичных файлов, чтобы иметь смысл из дампа сбоя? – jww

ответ

1

У этого действительно много вариантов с вашими личными предпочтениями, языком, который вы используете, и зависимостями проекта.

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

Вот несколько общих советов:

  • Не включайте, если скомпилированный код можно скомпилировать его из исходных файлов проекта.

  • Включите необходимые библиотеки, которые нельзя легко установить/автоматически установить и игнорировать остальные.

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

+0

Спасибо. Это то, что мне нужно было знать. – Trebor

+1

* «Не включайте скомпилированный код, если его можно скомпилировать из исходных файлов проекта» * - вы уверены в этом? Вы когда-нибудь пытались точно воссоздать двоичный файл, чтобы иметь возможность свалить с поля? Его недостаточно, чтобы проверить ревизию. Все, что связано со средой и инструментальными связями с зависимыми библиотеками, должно соответствовать или быть воссоздано. – jww

+1

Для отладки вашего скомпилированного кода это полезно. Хотя вы должны помнить, что исправление и перекомпиляция в другой системе все равно не будет использовать старую среду, и поэтому вы не можете знать, действительно ли вы исправили проблему или она просто не существует в вашей среде. Поэтому для управления версиями в распределенной разработке я бы, конечно, не включил скомпилированный код и, скорее, обменивался сбойным двоичным кодом в другом месте, если ошибка не сохранилась после перекомпиляции в другой системе. Это также полезно для отладки, так как вы знаете, что ошибка является средой. – dfherr

Смежные вопросы