Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
Интересно, что в некоторых проектах есть .gitignore, но в нём куча всякого мусора, только не то, что нужно
Надо было добавить ответ «Теперь — да» :-)
Нужно только не забыть, что в Git можно достать любую версию любого файла, и если конфигурации нет в последнем коммите, это не значит, что её нельзя достать.
Ну и кэш в поисковых системах работает, так что желательно пересоздать репозиторий без конфига, сменить пароль, ну и раскошелиться на приватный репозиторий.
Ну и кэш в поисковых системах работает, так что желательно пересоздать репозиторий без конфига, сменить пароль, ну и раскошелиться на приватный репозиторий.
>> раскошелиться на приватный репозиторий
Или просто юзать bitbucket, где приватные репы бесплатны.
Или просто юзать bitbucket, где приватные репы бесплатны.
Согласен.
Профит очевиден — поддержка Git, SVN и закрытые репозитории.
Профит очевиден — поддержка Git, SVN и закрытые репозитории.
О святые Торвальдсы! Вы еще юзаете SVN?
Вашего техдира случаем не Воланд зовут?
Вашего техдира случаем не Воланд зовут?
А что не так с SVN?
Он superstar :-)
А серьезно? Какие нарекания, интересно же. А то получается, как в презентации Торвальдса по GIT: «Вы пробовали когда-нибудь смерджить что-то в xyz? Это ужас» и закатывание глаз к потолку. Толку-то с такой критики.
Я не спорю — возможно, действительно, есть жуткие косяки, которые мне из-за небольшого опыта не увидеть. Вот и интересно, почему критикуют.
Я не спорю — возможно, действительно, есть жуткие косяки, которые мне из-за небольшого опыта не увидеть. Вот и интересно, почему критикуют.
Косяк есть один — вся история хранится на сервере, где бэкапы еще не делаются. GIT же — сам себе бэкап, при потере центрального сервера репозиторий можно восстановить из любой рабочей копии. Также в SVN нельзя работать с репозиторием в случае временной недоступности сервера — это мешает делать атомарные коммиты.
Это проблема не собственно SVNа, а идеологии центрального репозитория вообще. Разным задачам разные средства. Мне, в небольшой команде, удобно иметь центральный, reference так сказать, репозиторий. То, что svn не работает при недоступности сервера, кмк, сродни жалобе, что компьютер не работает при отсутствии электричества, а человек — кислорода.
И почему нельзя восстановить svn из рабочей копии (при условии, что она не изменена сильно, максимум, +- дневные изменения)?
Я использую GIT поверх SVN для локальных веток при работе над разными тикетами.
И почему нельзя восстановить svn из рабочей копии (при условии, что она не изменена сильно, максимум, +- дневные изменения)?
Я использую GIT поверх SVN для локальных веток при работе над разными тикетами.
Все очень просто.
Скажем, над проектом работают 3 программиста — A, B и С
Программист A написал фичу, которая успешно прошла тестирование и готова к продакшену
Фича программиста B не прошла и ее в текущем билде выкладывать не надо
А программист C Вообще все это время занимался рефакторингом, и его тестирование займет много времени, которого у тестировщиков нет
А теперь наступило время релиза
В SVN невозможно собрать билд, откинув все что писали B и C, но при этом сохранив весь код ими написанный, т.к. ветка одна
В Git же просто мержишь ветку программиста A в билд, оставляя в покое ветки B и C — и вуаля билд готов, никаких проблем.
И это только верхушка айсберга, с гитом можно делать такие штуки, которые SVN даже не снились, но почувствовать это можно, только работая в команде, и чем больше команда, тем четче видо, какая все-таки SVN ущербная.
Скажем, над проектом работают 3 программиста — A, B и С
Программист A написал фичу, которая успешно прошла тестирование и готова к продакшену
Фича программиста B не прошла и ее в текущем билде выкладывать не надо
А программист C Вообще все это время занимался рефакторингом, и его тестирование займет много времени, которого у тестировщиков нет
А теперь наступило время релиза
В SVN невозможно собрать билд, откинув все что писали B и C, но при этом сохранив весь код ими написанный, т.к. ветка одна
В Git же просто мержишь ветку программиста A в билд, оставляя в покое ветки B и C — и вуаля билд готов, никаких проблем.
И это только верхушка айсберга, с гитом можно делать такие штуки, которые SVN даже не снились, но почувствовать это можно, только работая в команде, и чем больше команда, тем четче видо, какая все-таки SVN ущербная.
Напомню, что в SVN тоже есть ветки.
ой, а разве в SVN нет бранчей? когда я её использовал, то там были бранчи, или что-то подобное, но мержить было действительно неудобно
В SVN невозможно собрать билд, откинув все что писали B и C, но при этом сохранив весь код ими написанный, т.к. ветка одна
А что мешает в SVN иметь release ветку и dev и не выкладывать рефакторинг и опасные фичи в релиз ветку?
Кто мешает выкладывать все фичи _только_ в dev и мерджить их в продакшн только после тестирования?
Да и далеко не всегда можно просто «откинуть все, что писали B и C». У нас полно ситуаций, когда коммиты совсем-совсем не атомарные, и их нельзя полностью откинуть. Например, допустим, я пррограммист B, дебажу что-то, исправляю ошибку, чекиню код. А паралелльно пишет свою фичу, но она затрагивает куски, над которым работал и я, B. После того, как я закинул свой код, А подкорректировал свой. Его фияа прошла тестирование. Потом оказалось, что мой фикс ломает что-то другое. А откатить его атомарно нельзя — фича А в своем коде уже пользуется переименованными мною переменными, функциями, вновь созданными мною функциями взамен удаленных. Если откатить мой коммит, код просто не соберется теперь. И тут Git (классный инструмент, согласен) никак не поможет. И в моем случае коммитов, которые можно откатить автоматом, да так, чтобы ничего не сломать, да хотяб чтобы проект собрался — мизер. «Магия» Git в стиле, описанном вами (повторю — гит классный инструмент и я им тоже пользуюсь) напоминает мне юмореску про магазин на диване, продававший штаны с подогревом. Вот мол, допустим, вы в голом поле, вы замерзли. Вам надо все-го то найти столб с проводами, залезть на него, подключить штаны и можно греться. Так и тут — еще поищи такой случай, когда можно коммиты отдельно друг от друга рассматривать.
или просто развернуть на серваке gitolite. я думаю, что сейчас не проблема обзавестись маленьким VPS,
Угу, а заодно и «Теперь — Да, но это не значит, что стало безопасне»
Когда марсианские агенты влияния управляют оппозицией, а жидорептилоиды и Михалков прочно укрепились в правительстве, безопасность — лишь иллюзия, которую создает правительство для успокоения народных масс.
А если серьезно — нет системы, которую взломать невозможно, есть просто системы которые невыгодно взламывать, поэтому информационная безопасность — такая же иллюзия, что и безопасность юридическая, и в этом вина теории вероятности, а не злобных хакеров и их подельников — поисковиков
А если серьезно — нет системы, которую взломать невозможно, есть просто системы которые невыгодно взламывать, поэтому информационная безопасность — такая же иллюзия, что и безопасность юридическая, и в этом вина теории вероятности, а не злобных хакеров и их подельников — поисковиков
Если серьёзно, то речь о том, что изменение .gitignore не обладает свойствами машины времени, т.е. то, что было выпущено наружу, увы уже ушло.
И лучший вариант ответа: «Теперь — Да, и сменил все пароли и явки».
Кстати, .gitignore это ещё что — достаточно поставить какой-нибудь P2P клиент с поиском (например для сети Gnutella2) и поискать по хешу какой-либо известный системный файл.
Результаты вселяют опасения о судьбе человечества.
И лучший вариант ответа: «Теперь — Да, и сменил все пароли и явки».
Кстати, .gitignore это ещё что — достаточно поставить какой-нибудь P2P клиент с поиском (например для сети Gnutella2) и поискать по хешу какой-либо известный системный файл.
Результаты вселяют опасения о судьбе человечества.
А где опция «Настроен и не использую GitHub»?
Э… давайте так: «если вы за каким-то хреном решили выложить код своей рабочей системы в открытый доступ, то, наверное, пароли выкладывать не надо».
Не только пароли, но и всякие ключи к криптоалгоритмам типа SECRET_KEY для Django. Использовать их, конечно, сложнее, но всё-таки можно.
Было дело, как-то заливал базу на чужой сервер с поддержкой со стороны админа, чем-то версия БД не срослась и вылилось это все в огромный лог ошибок… все бы ничего, если бы в этом логе не были засвечены пароли администратора БД…
Вот та часть про robots.txt и теги — это для случая с google'ом.
Поэтому я и добавил в конце «и ставить заглушки».
robots.txt не для корня. Не все логи, найденные через гугл были в корне, поэтому для того, чтоб директория не индексировалась мы прописываем ее в роботс и ставим заглушку.
nofollow в том случае, если есть ссылки с «морды» (бывали найдены и такие, которые с «морды» сайта отсылали в каталог с логами).
robots.txt не для корня. Не все логи, найденные через гугл были в корне, поэтому для того, чтоб директория не индексировалась мы прописываем ее в роботс и ставим заглушку.
nofollow в том случае, если есть ссылки с «морды» (бывали найдены и такие, которые с «морды» сайта отсылали в каталог с логами).
или лени некоторых пользователей, которые предпочитают SVN'у GitHub.
А вы лучше почитайте, что бывает с теми, кто предпочитает SVN — habrahabr.ru/post/70330/ — вторая по популярности статья на хабре за все время.
Для простой генерации .gitignore существует отличный сайт www.gitignore.io, вводишь технологии — получаешь .gitignore!
Ещё у этого проекта есть утилита с CLI. Сам сайт лежит целиком на Github, пользуйся-не хочу: github.com/joeblau/gitignore.io
Берем, например, маску автоматически сгенерированного MYSQL хоста одного популярного хостинга и получаем, снова же таки, ожидаемый результат:
Посмотреть скриншот
Довольно странно что вы замазали пароли но не замазали URL где эти пароли все так же видны.
От статьи осталось легкое ощущение рекламы bitbucket. Как будто github виноват, что люди хранят пароли/конфиги в репозиториях с открытым исходным кодом.
Если человек хочет открыть код — он и на битбакете его откроет и хранящийся в репозитории конфиг так же будет доступен всем желающим.
Если не хочет открывать — не будет выкладывать ни на битбакет, ни на гитхаб.
Ну и вообще, есть еще и gitlab, например, стоило его упомянуть, мне кажется, если вообще упоминаете альтернативы гитхабу.
Если человек хочет открыть код — он и на битбакете его откроет и хранящийся в репозитории конфиг так же будет доступен всем желающим.
Если не хочет открывать — не будет выкладывать ни на битбакет, ни на гитхаб.
Ну и вообще, есть еще и gitlab, например, стоило его упомянуть, мне кажется, если вообще упоминаете альтернативы гитхабу.
Есть даже книжка на эту тему «Google Hacking for Penetration Testers» by Johnny Long
Там куча примеров того, что бывает видно поисковикам.
Там куча примеров того, что бывает видно поисковикам.
Поздравляю! Автор узнал, что такое гугл-дорки.
Я, например, всегда все конфиги и дампы БД автоматически шифрую gnupg перед залитием в git.
А вообще ситуация печальная :( Не иметь бы совести — можно было бы всем этим эффективно пользоваться.
А вообще ситуация печальная :( Не иметь бы совести — можно было бы всем этим эффективно пользоваться.
вопрос первый. допустим, я получил логин-пароль к некой БД какого-либо проекта. что дальше? если все хорошо, то доступ под эти пользователем доступен либо с localhost, либо с определенного набора IP и, скорее всего, этот пароль сгенерирован и не подойдет никуда больше (ssh, ftp, mail etc)
вопрос второй. я давно задавался вопросом — нужно ли добавлять .gitignore в репозиторий или нет? лично я считаю, что нужно. кто что думает на эту тему и что подсказывает опыт бывалым?
вопрос второй. я давно задавался вопросом — нужно ли добавлять .gitignore в репозиторий или нет? лично я считаю, что нужно. кто что думает на эту тему и что подсказывает опыт бывалым?
Разумеется, его надо включать в репозиторий, для того его и создавали. Если не хочется делиться своими исключениями с остальными разработчиками — всегда есть
.git/info/excludeЕщё есть глобальный .gitignore, куда рекомендуют заносить файлы, создаваемые вашей любимой IDE (и не рекомендуют их заносить в .gitignore проекта)
Этот совет имеет смысл, только если проект не прибит гвоздями к конкретной IDE.
Совет всегда имеет смысл. Ибо нефиг выкладывать в репозиторий временные файлы(и резервные копии рабочих, как любят делать многие IDE для защиты от порчи файлов в момент их сохранения) которые могут создаваться любым IDE или отладчиком. Туда могут быть внесены и отладочные файлы, которые существуют на конкретном рабочем месте и т.д.
Почему такие файлы нельзя занести в
.gitignore проекта?Потому что им там не место. Там должны быть файлы именно проекта (связанные с используемым фреймворком и доп. библиотеками и просто созданные в процессе развития проекта), но никак не IDE (у нас на проекте, например, среди разработчиков распространены 2 разных IDE и 3 разных текстовых редактора).
Приведите мне, пожалуйста, альтернативные IDE, которые можно использовать параллельно с Visual Studio. Не забудьте, что файл, созданный в этой самой другой IDE, должен потом быть виден в студии.
Не приведу — с Visual Studio и программированием на плюсах не сталкивался со студенческой скамьи.
У нас из IDE используется в основном RubyMine и кто-то использует Aptana (несмотря на бурную агитацию поклонников jetBrains). Никакие файлы никаких IDE в репозиториях не хранятся (папка .idea у меня в глобальном .gitignore).
ИМХО, это задача IDE — самостоятельно обнаруживать новые файлы. IDE на базе IntelliJ Idea справляются с этим нормально.
У нас из IDE используется в основном RubyMine и кто-то использует Aptana (несмотря на бурную агитацию поклонников jetBrains). Никакие файлы никаких IDE в репозиториях не хранятся (папка .idea у меня в глобальном .gitignore).
ИМХО, это задача IDE — самостоятельно обнаруживать новые файлы. IDE на базе IntelliJ Idea справляются с этим нормально.
К сожалению, ваше мнение так вашим мнением и остается. Visual Studio файлы, не включенные в проект, файлами не считает.
В связи с этим повторяю вопрос: какой смысл разделять локальный и глобальный
В связи с этим повторяю вопрос: какой смысл разделять локальный и глобальный
.gitignore, если все разработчики пользуются одной и той же IDE?Если все пользуются одной и той же IDE (к тому же такой) — никакого смысла нет. Если IDE приколочена к проекту гвоздями (как кто-то говорил выше) — то даже наоборот, следует добавлять файлы проекта в репозиторий (тут нужно смотреть для каждой IDE отдельно).
Если все пользуются разными инструментами — смысл есть и более того, нужно нещадно наказывать как за включение файлов IDE в репо, так и за включение масок, специфичных для IDE или ОС, в проектный .gitignore. Например, в проектном .gitignore не должно быть маски .DS_Store, она должна быть в глобальном .gitignore у разработчиков, сидящих на OS X.
Если все пользуются разными инструментами — смысл есть и более того, нужно нещадно наказывать как за включение файлов IDE в репо, так и за включение масок, специфичных для IDE или ОС, в проектный .gitignore. Например, в проектном .gitignore не должно быть маски .DS_Store, она должна быть в глобальном .gitignore у разработчиков, сидящих на OS X.
«стиллер» это от слова still?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взлом с помощью поиска, невнимательность и мой подельник GitHub