Комментарии 16
> git push --recurse-submodules=check
мастхэв
мастхэв
Подскажите пожалуйста. Можно ли как-то отучить Git коммитить файлы, которые не содержат в содержимом никаких изменений, но имеют разную дату редактирования. Сейчас у меня постоянно возникает проблема при поиске какой-нибудь ошибки. Сделал промежуточный вывод, удалил. Файл не изменился, но Git считает своим долгом его закоммитить. Получается каша.
Гит не умеет коммитить что-либо по своему желанию. Он коммитит только то, на что вы ему укажите. Опишите, пожалуйста, подробнее, что у вас за промежуточный вывод и каким образом гит считает своим долгом его закоммитить.
Я не очень продвинутый в этом пользователь, может что-то не так делаю. У меня небольшой проект на PHP в виде модуля к CMS. У меня есть две папки. В одной у меня полностью настроенная CMS, а во второй выделенные файлы для коммита. Так вот, я делаю сейчас такую операцию:
— Сравниваю все файлы в двух папках и нахожу измененные файлы.
— Копирую только измененные файлы.
— Пишу в консоли git commit -a -m «Комментарий»
— Пишу в консоли git push
В таком виде это работает.
А если я просто скопирую все файлы (а не только измененные) из одной папки в другую, то git коммитит абсолютно все скопированные файлы.
— Сравниваю все файлы в двух папках и нахожу измененные файлы.
— Копирую только измененные файлы.
— Пишу в консоли git commit -a -m «Комментарий»
— Пишу в консоли git push
В таком виде это работает.
А если я просто скопирую все файлы (а не только измененные) из одной папки в другую, то git коммитит абсолютно все скопированные файлы.
Почитайте внимательнее о флаге -a. Если он есть, гит добавляет до стейджинга все файлы и потом комитит. Пользутейсь git add а потом commit -m. Также непонятна структура, зачем вам две отдельных папки?
Спасибо за направление, буду разбираться.
Две папки, так как модуль по сути разрабатывается для продакшена, а коммитится немного модифицированная версия (отличаются шаблоны, конфиги).
Две папки, так как модуль по сути разрабатывается для продакшена, а коммитится немного модифицированная версия (отличаются шаблоны, конфиги).
Не совсем понятен из ответа критерий по которому коммитятся файлы, но в любом случае мне кажется в Вашем случае нужно держать второй локальный репозиторий, а не просто дублирующую папку — так много проще и отбирать файлы для комита (бонус: можно коммитить только часть файлов; см. `git add -p`), и обновлять только изменившиеся файлы (обычным пушем, ведь только нужные файлы окажутся закоммиченными в дублируюший репозиторий).
Если немного дополнить схему работы, можно также обеспесить версионирование файлов, которые изменяются, но сейчас не комитятся («для продакщена»).
Если немного дополнить схему работы, можно также обеспесить версионирование файлов, которые изменяются, но сейчас не комитятся («для продакщена»).
Вам нужны две ветки уже. production и develop.
И да, убедитесь что у вас входящие файлы (те, которые вы стянули с репозитория) имеют EOL-style такой же, как и в настройках редактора. Может быть он заменяет EOL`и, соответсвенно файлы становятся измененными.
А попробуйте иметь две ветки вместо двух папок. Может стать удобнее.
Соответственно
Осмелюсь предложить мерджиться
То есть Вы разрабатываете в master, комиттите туда всё, потом переходите в production, и туда сквашитесь.
А потом там, где собственно работает сервер, просто делаете
Вот вы не продакшен-ветке. Потом обычным git pull обновляетесь по мере появления на ней изменений.
Тем самым, у вас есть возможность отслеживать изменения обеих веток в одном месте, и перекрёстно опылять их в любой момент.
Соответственно
git checkout productiongit checkout masterОсмелюсь предложить мерджиться
git merge --squash masterТо есть Вы разрабатываете в master, комиттите туда всё, потом переходите в production, и туда сквашитесь.
А потом там, где собственно работает сервер, просто делаете
git clone <…>git checkout origin/productionВот вы не продакшен-ветке. Потом обычным git pull обновляетесь по мере появления на ней изменений.
Тем самым, у вас есть возможность отслеживать изменения обеих веток в одном месте, и перекрёстно опылять их в любой момент.
Спасибо, но у меня по сути есть публичная версия (master), а версию production не очень-то хотелось бы публиковать. Поэтому максимум, вероятно, что можно использовать — сделать еще дополнительный локальный репозиторий.
Так погодите, у гита же на origin не все ветки можно заливать.
А как раз только избранные.
То есть каждый раз, когда вы делаете
Под ухищрениями я понимаю
А как раз только избранные.
То есть каждый раз, когда вы делаете
git checkout -b new_branchgit pushПод ухищрениями я понимаю
git push origin new_branch
У меня TurtiiseGIT в окне комита показывает все файлы с изменившейся датой.
Но даже если разрешить ему их коммитить, оставив у них галочки, после этого в логе я вижу только реальные изменения.
Пока мирюсь, но для себя оправдываю это его поведение тем, что при выборке в интерфейс там глюк, а в итоговый коммит GIT всё равно умеет включать только реальные исправления, а про 0 добавлений и 0 удалений он включить в коммит всё равно ничего не может.
Занятно, что у Вас такой же глюк в консоли… я думал, это интерфейсное у черепаха.
Но даже если разрешить ему их коммитить, оставив у них галочки, после этого в логе я вижу только реальные изменения.
Пока мирюсь, но для себя оправдываю это его поведение тем, что при выборке в интерфейс там глюк, а в итоговый коммит GIT всё равно умеет включать только реальные исправления, а про 0 добавлений и 0 удалений он включить в коммит всё равно ничего не может.
Занятно, что у Вас такой же глюк в консоли… я думал, это интерфейсное у черепаха.
«Застешить» — это хорошо, но лучше «заначить» %)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Git 1.7.7