Комментарии 68
А потом кто-нибудь, у кого эти .gitconfig не настроены — возьмет и закоммитит все, что под руку попадется.
Ну и дурак, что с того?
Для этого и сделаны пулл-реквесты — чтобы какой-нибудь чудак не коммитил ерунду.
У вас гит только гитхубом ограничивается?
А пулл-реквесты только на гитхабе?
Нет, у меня всякие чудаки не имеют доступа в основной репозиторий безотносительно.
А вам понятие пулл-реквеста только по гитхабу знакомо?
Вот неплохой мануал про это, там и про
А вам понятие пулл-реквеста только по гитхабу знакомо?
Вот неплохой мануал про это, там и про
git request-pull можно прочитать.По принципу Мерфи, такой чудик в вашей команде рано или поздно появится. Пусть это будет новичек и это будет его первый коммит, но потом разгребать.
Я лучше буду уверенным, что сделав пул, коммит и пуш — ничего в репозитории не изменится.
Я лучше буду уверенным, что сделав пул, коммит и пуш — ничего в репозитории не изменится.
Ну так первый коммит и превратится в первый пулл-реквест, я же об этом выше написал.
сделав пул, коммит и пуш — ничего в репозитории не изменитсяА зачем вносить пустой коммит? Вы что-то другое хотели сказать, наверное.
> Вы что-то другое хотели сказать, наверное.
Нет, я хотел сказать именно то, что сказал. У команды, в которой игноры раскиданы вот по таким волшебным местам, у новичка, который работает первый день такой коммит будет не пустой. А вот у команды, в которой используется нормальный .gitignore коммит будет пустой, ну или содержать именно те и только те изменения, который были сделаны умышленно.
Нет, я хотел сказать именно то, что сказал. У команды, в которой игноры раскиданы вот по таким волшебным местам, у новичка, который работает первый день такой коммит будет не пустой. А вот у команды, в которой используется нормальный .gitignore коммит будет пустой, ну или содержать именно те и только те изменения, который были сделаны умышленно.
Эдак вам придется делать файлы .gitignore с содержимым вида
*
!.gitignore
!foo/bar
# И так еще тысячи строк?
or run the git request-pull command and e-mail the output to the project maintainer manually.Представил, как в команде разработчиков кто-то сидит и апплаит патчи.
Закоммитит со своей машины то чего нет в репозитории?
Спасибо. Не знал.
На самом деле, настройка гита на рабочей машине девелопера в команде тоже должна происходить централизованно.
Проблема в том, что, во-первых, каждый будет тратить свое время на настройку одного и тогоже. В команде зачастую 80% настроек одинково (почти все пользуются одним ide и т.п.)
Во-вторых, если централизованно этого не делать, то обязательно что-нибудь забудется и протечет в репозиторий. Человеческий фактор он есть.
Вы не думали как можно настройку гита положить тоже под vcs или сделать командный дистрибутив?
Проблема в том, что, во-первых, каждый будет тратить свое время на настройку одного и тогоже. В команде зачастую 80% настроек одинково (почти все пользуются одним ide и т.п.)
Во-вторых, если централизованно этого не делать, то обязательно что-нибудь забудется и протечет в репозиторий. Человеческий фактор он есть.
Вы не думали как можно настройку гита положить тоже под vcs или сделать командный дистрибутив?
не нужно парится — пошел на гитхаб и скачал .gitignore для своего языка / IDE / фреймворка
Не юзабельно
качается оно один раз а потом собирается из нескольких свой
потому как например юзаешь симфони2, для нее есть файл, но еще юзаешь идею, для которой есть еще один файл
а потом еще юзаешь на разработческой машине складывание логов в папочку проекта, которые тоже заигнорить надо.
в результате собираешь свой из двух-трех, а потом он качует из проекта в проект.
качается оно один раз а потом собирается из нескольких свой
потому как например юзаешь симфони2, для нее есть файл, но еще юзаешь идею, для которой есть еще один файл
а потом еще юзаешь на разработческой машине складывание логов в папочку проекта, которые тоже заигнорить надо.
в результате собираешь свой из двух-трех, а потом он качует из проекта в проект.
gitignore.io/ удобнее будет, имхо…
И даже цвета редактора тим лида должны спускаться в консоли нижестоящих. Аминь.
Лучше загадить gitignore, чем репу.
.idea это не конфиги, а кэш. а я ведь даже их продуктами не пользуюсь, что бы знать.
Вы не правы.
The .idea directory contains a set of configuration files (.xml). Each file contains only a portion of configuration data pertaining to a certain functional area which is reflected in the name of a file, for example, compiler.xml, encodings.xml, modules.xml.proof
Если в проекте используется, к примеру, Idea, то скорее всего её используют все разработчики (ну, редко бывает иначе). Так почему бы один раз не положить в gitignore данные для Idea? Неужели лучше отвлекать N человек на настройку локальных репозиториев?
А если какой-то фанат другой IDE решит её использовать, то во-первых, не умрёт ваш gitignore от десятка лишних строк, а во-вторых, вот этого чудака и можно (и нужно!) заставить настраивать локальный репозиторий указанным в статье способом.
А если какой-то фанат другой IDE решит её использовать, то во-первых, не умрёт ваш gitignore от десятка лишних строк, а во-вторых, вот этого чудака и можно (и нужно!) заставить настраивать локальный репозиторий указанным в статье способом.
Внесу свои 3 копейки. Используем как раз Idea, но проект собираем с помощью maven из которого Idea умеет импортировать проект.
Сначала закоммитили .idea для удобства и вроде бы все шло хорошо, но потом началось веселье: Idea занимается в фоне особой магией, и иногда меняет порядок записей в файлах — регулярно вылезали конфликты на пустом месте. Кроме того, на каждую зависимость из maven в подпапке .idea на лету создается XML-файл и иногда не удаляется при чекауте другого бранча без этой зависимости (см. фоновая магия), для чекаута обратно нужно вручную чистить.
Через несколько недель эта возня всем надоела и .idea отправилась в .gitignore.
P.S. В .gitignore у нас помойка, но пока никто не жалуется.
Сначала закоммитили .idea для удобства и вроде бы все шло хорошо, но потом началось веселье: Idea занимается в фоне особой магией, и иногда меняет порядок записей в файлах — регулярно вылезали конфликты на пустом месте. Кроме того, на каждую зависимость из maven в подпапке .idea на лету создается XML-файл и иногда не удаляется при чекауте другого бранча без этой зависимости (см. фоновая магия), для чекаута обратно нужно вручную чистить.
Через несколько недель эта возня всем надоела и .idea отправилась в .gitignore.
P.S. В .gitignore у нас помойка, но пока никто не жалуется.
а просто в нужную папку положить .gitignore с * — не?
Не задумывался как-то над этим.
У нас обычно каждый в .gitignore свои исключения добавляет. Не знаю, может у нас просто проекты небольшие, но особой путаницы не происходило ни разу.
У нас обычно каждый в .gitignore свои исключения добавляет. Не знаю, может у нас просто проекты небольшие, но особой путаницы не происходило ни разу.
А что ж вы тогда оставите в .gitignore, можно поинтересоваться?
А не проще в .gitignore сначала всё запретить и разрешить только то, что нужно. Например
*
!.gitignore
!*.py
!*.html
Спасибо. В целом с мнением автора я не согласен — как и многим тут, мне кажется, что окружение лучше писать в .gitignore.
Но иногда хочется заигнорить какие-то свои тестовые/экспериментальные контроллеры, вьюхи, тесты или ещё что-нибудь, которые удалять пока рано, в общий gitignore пихать смысла нет, а видеть их болтающимися в текущих незакоммиченных изменениях не хочется.
Но иногда хочется заигнорить какие-то свои тестовые/экспериментальные контроллеры, вьюхи, тесты или ещё что-нибудь, которые удалять пока рано, в общий gitignore пихать смысла нет, а видеть их болтающимися в текущих незакоммиченных изменениях не хочется.
С мнением автора тоже категорически не согласен.
Репозиторий должен быть самодостаточным, – взял и начал работать. Не тратя время на разбирательства, кто и как готовил репозиторий и свое локальное окружение.
Аргументация в пользу таких усложнений, как я понимаю только одна – .gitignore превратиться в помойку.
Файлы проектов IDE – сколько актуальных ide или редакторов существует для вашего стека? Не думаю, что больше 5.
Дотфайлы локального окружения для запуска проекта (если такие есть).
Всякий мусор ОС (.DS_Store, thumbs_db).
Файлы специфичные для вашего стека, которых не должно быть в репозитории.
Первые два пункта – это 10-15 строчек, в худшем случае.
Разве это стоит вероятности наступления на БольшиеГрабли?
Репозиторий должен быть самодостаточным, – взял и начал работать. Не тратя время на разбирательства, кто и как готовил репозиторий и свое локальное окружение.
Аргументация в пользу таких усложнений, как я понимаю только одна – .gitignore превратиться в помойку.
Файлы проектов IDE – сколько актуальных ide или редакторов существует для вашего стека? Не думаю, что больше 5.
Дотфайлы локального окружения для запуска проекта (если такие есть).
Всякий мусор ОС (.DS_Store, thumbs_db).
Файлы специфичные для вашего стека, которых не должно быть в репозитории.
Первые два пункта – это 10-15 строчек, в худшем случае.
Разве это стоит вероятности наступления на БольшиеГрабли?
«Раз пошла такая пьянка — режь последний пирожок!»
Расскажу, как это устроено у нас в рабочем репе.
1. Dev-окружение каждого разработчика — виртуальная машина с настроеным Сhef-client через Vagrant, образ которой тянется из локальной сети и обновляется оттуда же.
2. Мы стараемся держать весь стек as new as possible, соответственно, мы решили сползти на клиент-серверный chef, все виртуальные машины настроены как клиенты, в итоге каждый разработчик получает последнюю версию самого актуального стека практически без последствий (обновление образа — среда, тестирование — среда-пятница, раскатка обновлений на все дев-машины — суббота), нет проблем с разными версиями либ, т.к. везде используется одно и то же. В общем, много плюшек.
3. Политика работы с .git'ом — все конфиги и прочее обозначены в .gitignore проекта, исходники конфигов проименованы через <name>.default.cfg, при этом есть доходчивый мануал по настройке окружения, ну и бинарные файлы/конфиги добавляются по необходимости через --force. Настройка же через Chef позволяет полностью исключить этап «запуска» на машине разработчика. Не нужно копировать конфиги, настраивать подключения, etc — это все уже реализовано в рецепте application и нужно всего лишь подождать 5-10 минут.
4. Отдельное слово про пустые каталоги — если в проекте 100% нужна какая-то точка на FS — мы форсим добавление .gitfolder в этой точке, на который уже есть запись в .gitignore.
5. Все изменения в .gitignore бьются по разделам и комментируются, дабы избежать глобальной помойки для «будущих» поколений.
Как-то так, в общем.
Путь к такой схеме работы достоин отдельной статьи, ибо набили шишек мы очень порядочно. В том числе и с перечисленными пунктами топикстартера…
Расскажу, как это устроено у нас в рабочем репе.
1. Dev-окружение каждого разработчика — виртуальная машина с настроеным Сhef-client через Vagrant, образ которой тянется из локальной сети и обновляется оттуда же.
2. Мы стараемся держать весь стек as new as possible, соответственно, мы решили сползти на клиент-серверный chef, все виртуальные машины настроены как клиенты, в итоге каждый разработчик получает последнюю версию самого актуального стека практически без последствий (обновление образа — среда, тестирование — среда-пятница, раскатка обновлений на все дев-машины — суббота), нет проблем с разными версиями либ, т.к. везде используется одно и то же. В общем, много плюшек.
3. Политика работы с .git'ом — все конфиги и прочее обозначены в .gitignore проекта, исходники конфигов проименованы через <name>.default.cfg, при этом есть доходчивый мануал по настройке окружения, ну и бинарные файлы/конфиги добавляются по необходимости через --force. Настройка же через Chef позволяет полностью исключить этап «запуска» на машине разработчика. Не нужно копировать конфиги, настраивать подключения, etc — это все уже реализовано в рецепте application и нужно всего лишь подождать 5-10 минут.
4. Отдельное слово про пустые каталоги — если в проекте 100% нужна какая-то точка на FS — мы форсим добавление .gitfolder в этой точке, на который уже есть запись в .gitignore.
5. Все изменения в .gitignore бьются по разделам и комментируются, дабы избежать глобальной помойки для «будущих» поколений.
Как-то так, в общем.
Путь к такой схеме работы достоин отдельной статьи, ибо набили шишек мы очень порядочно. В том числе и с перечисленными пунктами топикстартера…
Заставлять ленивых разработчиков настраивать окружение вместо того, чтобы написать нормальный проектно-специфичный .gitignore… С моей точки зрения это глупо.
Не нахожу особо проблеными лишние десять-двадцать строк в .*ignore для используемых IDE и редакторов, честно говоря. Никто из команд, где я работал, тоже не высказывал опасений.
Спасибо. Как раз сегодня возникла проблема с idea.
Папку .idea как раз можно было бы и положить в реп. Так можно зафиксировать стиль кода, например.
Только после этого не стоит клонировать её по другому пути, то idea начнет глючить. Не лучший вариант.
А можно подробнее? Тут об этом не пишут.
Сталкивался с абсолютными путями в .idea где-то года полтора назад. Проект на java с использованием maven. Не репортил за ненадобностью.
Сейчас посмотрел эти xml глазами, вроде всё шаблонизировано.
По ссылке:
Явно указывают, какие файлы добавлять не стоит.
Сейчас посмотрел эти xml глазами, вроде всё шаблонизировано.
По ссылке:
.ipr file based format
Share the project .ipr file and and all the .iml module files, don't share the .iws file as it stores user specific settings.
.idea directory based format
Share all the files under .idea directory in the project root except the workspace.xml and tasks.xml files which store user specific settings, also share all the .iml module files.
Явно указывают, какие файлы добавлять не стоит.
Странно добавлять в реп файлы, которые изменяются при каждом запуске IDE. Конфиги проекта в других файлах.
.idea была добавлена по ошибке. Хуков для предотвращения добавления .project, .nbproject, .idea и прочего в репозиториях я не делал, считая инструктаж достаточной мерой.В какой-то прекрасный день обнаружился такой подарок, уронивший idea. Версию не помню, возможно была EAP. Чистка репозитория и мозгов пострадавшего исправили ситуацию.
Неприятно, когда .gitignore встречается во вложенных папках. Проверяю так:
$ find . -iname .gitignore
Я статью написал о файле .gitignore со всевозможными примерами.
для Windows вместо:
надо делать:
git config --global core.excludesfile ~/.gitexcludesнадо делать:
git config --global core.excludesfile %userpath%/.gitexcludes
Вот такой вопрос. Все файлы которые на удаленном репозитории отслеживаемые? Например *.c и *.h файлы должны отслеживаться, но файлы проектов не должны отслеживаться но без них никак. Файлы настроек проекта у меня добавлены в гитигнор. Но при заливке на удаленный репо проекта заливаются только отслеживаемые файлы а хотелось что бы все.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Правильные способы исключения файлов в Git