Переместите эти файлы или удалите их перед переключением веток
мы недавно переключились с SVN на Git и в то же время перевели наши действующие системы в систему управления версиями (вместо локальной проверки и копирования файлов в живую).
В проекте, который мне назначен, мы все имеем доступ к одному и тому же репозиторию, и чтобы внести изменения в живую жизнь, мы просто git pull туда. Это вызывает проблемы, потому что наши веб-дизайнеры вносят изменения в VCS, которые еще не должны быть активными, но должны быть в среде веб-тестирования.
Когда один из разработчиков начинает работать, он получает все (возможно, незавершенные) изменения.
Я думал о том, чтобы переключиться вживую на дополнительную ветку и просто объединить то, что изменилось, но из-за недостатка знаний о git я понятия не имею, как.
Моя идея такова:
Проблема в том, что переключение на мастер или перетаскивание всего непосредственно в работающую систему может вызвать проблемы, поэтому я бы предпочел этого избежать.
Есть ли способ сделать это или есть лучший способ управлять системой Live (кроме обучения веб-игроков, чтобы они не толкали незаконченные вещи).
4 ответа 4
Вы можете использовать git stash перед проверкой master и pull, а после проверки live снова используйте git stash pop (или, если ваш git старше, git stash apply и git stash clear при условии, что вы больше ничего не спрятали)
Я смог вытащить изменения из origin/master в master при работе в другой ветви с помощью этой команды:
Решите проблему в первую очередь. Они не должны подталкивать к филиалу, к которому они не имеют никакого бизнеса.
То, что вы спрашиваете, было бы что-то вроде
Это попытается объединить удаленный мастер и вашу живую ветку.
Я рекомендую вам создать тестовое репозиторий git, чтобы каждый мог его принять. Все репо, включая ваш живой сайт, будут клонами тестового репо. Таким образом, любой может перейти к тестированию, не касаясь живого веб-сайта. Когда кому-то нужно обновить действующий сайт, вы можете извлечь его из репозитория git testing. Этот рабочий процесс довольно похож на SVN. Для дополнительной гибкости я рекомендую использовать ветку "live", которую вы описываете.
Подводя итог, все git-репо являются клоном тестового репо. Сайт живого производства также является клоном тестового репо. В качестве альтернативы, тестирование может быть клоном живой продукции, так что "толчок мерзавца" всегда движется к производству.
Другие варианты, в том числе добавление "живой" ветки к этой договоренности или "промежуточное" репо между тестированием и производством. Для дополнительной безопасности я рекомендую ограничить доступ к живому git-репо и заставить людей использовать защищенный сценарий, который позволяет работать в прямом эфире.
Я пытаюсь сделать со своего сервера, но продолжаю получать ошибку:
Нет неотслеживаемых файлов, но похоже, что у него есть проблемы с игнорируемые файлы по какой-то причине.
Я попытался запустить , чтобы посмотреть, что будет удалено, и он перечислит целую кучу файлов, которые игнорируются в .
По-видимому, файлы были добавлены в удаленный репозиторий, независимо от того, какое содержимое было в файле в источнике.
Поскольку файлы существуют в удаленном репозитории, git также должен вытащить их в ваше локальное дерево работы и поэтому жалуется, что файлы уже существуют.
используется только для сканирования вновь добавленных файлов, он не имеет ничего общего с файлами, которые уже были добавлены.
Таким образом, решение состоит в том, чтобы удалить файлы из вашего рабочего дерева и загрузить последнюю версию. Или долгосрочное решение - удалить файлы из репозитория, если они были добавлены по ошибке.
Простой пример удаления файлов из удаленной ветки:
Затем вы можете попробовать еще раз
- Я просто добавил репо на сам сервер, поэтому я сделал дополнительный шаг и полностью удалил его . затем я сделал на новом репо, поэтому теперь он не должен добавлять какие-либо игнорируемые файлы. Затем я совершил, а затем сделал , но такая же проблема все еще существует.
- @Brett: похоже, проблема существует в удаленном репо, а не в локальном. Удалите местное, а затем потяните. После этого удалите файлы, которые вызвали проблему, зафиксируйте и нажмите. С тех пор файлы следует игнорировать.
- Что вы имеете в виду под местным? Репо на моем сервере? Репо находится в трех местах: локальном (моя машина разработчика), битбакете (удаленном) и сервере - проблема, с которой я сталкиваюсь, находится на сервере. Я не хочу физически удалять эти файлы, просто игнорирую их - они существуют на сервере, но нигде больше.
- @Brett: Я имею в виду ту, из которой вы скачиваете обновление, т.е. битбакет. Я предполагаю, что вы сделаете это в своем локальном репозитории разработчиков и внесете изменения в битбакет. Затем вы просто запустите pull на сервере, и, поскольку файлы будут удалены из репозитория bitbucket, проблемы исчезнут.
- Дело в том, что файлы, с которыми возникают проблемы, игнорируются файлами, которые существуют только на сервере - на сервере есть некоторые папки, которые не существуют локально, поэтому я добавил их в ; поэтому я не понимаю, почему Git не может просто игнорировать их - они не в репо и игнорируются.
Я столкнулся с той же проблемой и решил ее, используя следующее. Сначала очистите отслеживаемые файлы, используя:
Вы можете просмотреть другие параметры git clean, набрав
- 2 Не работает, я по-прежнему получаю: error: Следующие неотслеживаемые файлы рабочего дерева будут удалены путем слияния: logs / Recommended.log Пожалуйста, переместите или удалите их перед объединением.
- 2 это работа. Это решение следует принять как ответ.
Чтобы удалить и удалить все изменения
- 2 Спасибо. Это сработало для меня. Одна вещь, на которую следует обратить внимание: он удаляет все неотслеживаемые файлы, поэтому, если у вас есть файл .env или другая локальная конфигурация с секретами, сначала сделайте резервную копию
Если нужно удалить слишком много файлов, что на самом деле для меня случай. Вы также можете попробовать следующее решение:
1) fetch (получить)
2) слияние со стратегией. Например, это работает для меня:
- Мастер ветки -> Ошибка FETCH_HEAD: Следующие неотслеживаемые файлы рабочего дерева будут перезаписаны слиянием: src / dj / abc.html. Пожалуйста, переместите или удалите их перед объединением. Прерывание
Попробуйте удалить указанный выше файл вручную (осторожно). Git объединит этот файл из основной ветки.
гит не не кажет их как новые, но и не отдает по ним историю (git log — ./strange_directory отдает пустой лист со словом END в начале). Это нормально?
репозиторий клонировал заново - сразу после свежего чекаута вроде все в порядке, но потом неизменно снова ломается. git reset --hard HEAD, интерактивный рибейз, итп - ничего не помогает
клонировал на другой жесткий диск - та же проблема.
платформа - OSX постоянно, один раз видел под линуксом, под виндой не видел никогда (с другой стороны, у меня и нет винды своей..)
ничего не понимаю :(
И ещё: я не уверен, но скорее всего git clean умеет чистить и директории в том числе.
это нормальное поведение. если я правильно понимаю, то он и не должен обновлять файлы, которых нет в том бранче, на который ты переключился. первое, что пришло в голову, это
тс вряд ли говорит про пустые директории
Директории используются в самом репозитории, или создаются при сборке? Они есть в .gitignore? Что говорят git status, git status --ignored?
это нормальное поведение. если я правильно понимаю, то он и не должен обновлять файлы, которых нет в том бранче, на который ты переключился. первое, что пришло в голову, это
Если файлы/директории есть в том бранче ИЗ которого ты переключаешься, но нет в том НА который ты переключаешься, git обязан их удалить, разумеется.
у меня используются руки и git в zsh консольке
если конкретней, то вначале была версия git version 2.5.4 (Apple Git-61), сейчас git version 2.6.1. Обновление не помогло. Как такое может быть - не знаю, поэтому и пришел ныть сюда..
ой, чет затупил. просто настолько часто с этим встречался, что уже принимаю за нормальное поведение. правда, всё же не могу понять, как сие воспроизвести
А в багтрекер соходить поныть не?
Заодно бы и английский прокачал ;-)
P.S. Если дойдешь до них - скидываю сюда ссылку, почитаем.
глазами через ls видна куча директорий, которых в этом бранче быть не должно - это слишком древний бранч
для того чтобы убрать предположение f1u77y я сделал git reset --hard HEAD и теперь весь мусор точно должен исчезнуть
Помогло вот что: git clean -fd
Это ПОЧТИ решение за исключением вопроса.
Какого черта гит притащил директории из соседнего бранча, сделал их untracked и теперь не показывает их даже в статусе?!
да, ты правильно понял проблему. Вот именно этого не происходит. Вместо удаления он делает их untracked (что бы это ни значило в данном случае).
Да, у меня такое тоже иногда повторяется. А файлы эти, в папках, это же не сорцы? Что за файлы?
Это сорцы. Файлы проекта. В том-то и проблема, что я меняю бранч, там другой набор сырцов и другие настройки IDE Intellij Idea - и у Idea от этого срывает башню, она пытается все это попарсить (несовместимый набор исходников), ей случается плохо, и результаты приходится разбирать вручную
ну блин. ну ладно, придется каждую команду в гите теперь предварять git clean -fd и mvn clean install (чтобы перегенерить исходники, которые git clean сотрет)
А почему ты сделал вывод, что виновата Idea в этом? А ты чекауты между бранчами делаешь с помощью Idea или прямо в консоли?Ты писал вроде, что из консоли. А если вот взять и выключить idea, оставить только консоль и сделать чекаут из одной в другую бранч - будет же тоже самое?Тогда idea не при чем будет. Можешь проверить?
А если выполнять команды гита в (ba)sh ?
Ещё один неосилятор не осилил 800 страниц стандарта.
Может в этих директориях лежат файлы, которые не трекаются гитом?
Могу ошибаться, но GIT все подчищает за собой как правило при переключении веток. Тут явно какой-то косяк, возможно с .gitignore
Которые могут быть почти во всех проектах. А потом вы выкачиваете проект, и, внезапно, у вас оказываются лишние неотслеживаемые файлы. И это только одна из возможных причин. Git достаточно стабилен, чтобы не нести охинею при отработке переходов. Чудес не бывает. Показывайте глобальные/локальные эксклюды + структуру проекта (никто ж не заставляет вас светить код)
Кстати, вот еще что (если у вас большая история, и тем более n->infinity разработчиков, эта ситуация вполне вероятна) Вот вы вчера отслеживали файл X - а сегодня решили, что больше не хотите. И тупо пытаетесь игнорить его через .gitignore. (Да да, такое вполне бывает) Так вот git и не собирается игнорировать такой файл и в этом нет ничего удивительного. После вашего базового коммита, git уже начал отслеживать файл (если вы конечно изначально не сказали ему обратного) и пусть бы вы даже с базовым коммитом послали туда .gitignore, git'у все равно было бы на это пофиг. Он ничего не хочет знать пока вы не удалите файл из буфера слежения
И уже после этого не заигнорите (если выбросили из буфа, конечно)Я понимаю, что это дет. сад git'а, но иногда вот такие вот казусы и находишь в проектах :) Так что это вполне себе куллстори :)
ошибка: ваши локальные изменения в следующих файлах будут перезаписаны слиянием:
WP-содержание / W3TC-конфигурации / master.php
Пожалуйста, передайте свои изменения или спрячьте их, прежде чем сможете объединить.
Вы не можете объединиться с локальными изменениями. Git защищает вас от потери потенциально важных изменений.
У вас есть три варианта:
Зафиксируйте изменения, используя
Спрятать это.
Шкатулка действует как стек, где вы можете помещать изменения и извлекать их в обратном порядке.
Чтобы спрятать, введите
Сделайте слияние, а затем вытяните тайник:
Откажитесь от локальных изменений
используя git reset --hard
или git checkout -t -f remote/branch
Или: отменить локальные изменения для определенного файла
с помощью git checkout filename
Вы также можете отменить локальные изменения для определенного файла, выполнив: git checkout filename Спасибо. Я хотел бы добавить к этому, если вы делаете, git reset --hard вы также можете удалить неотслеживаемые файлы с git clean -dfx По умолчанию git stash не будут храниться файлы, для которых нет истории. Так что если у вас есть файлы, которые вы еще не добавили, но которые были бы перезаписаны или «созданы» слиянием, то слияние все равно будет заблокировано. В этой ситуации вы также можете git stash -u хранить незафиксированные файлы. Или вы можете просто удалить их! бегать git clean -dfx было ужасной идеей. Удалены некоторые файлы .gitignored, которые мне действительно нужны. Я столкнулся с ситуацией, когда у пользователя после git reset --hard внесения изменений все еще были изменения!Первая команда временно сохраняет ваши изменения в тайнике и удаляет их из рабочего каталога.
Вторая команда переключает ветви.
Третья команда восстанавливает изменения, которые вы сохранили в тайнике (эта --index опция полезна, чтобы убедиться, что промежуточные файлы все еще находятся в стадии подготовки ).
чтобы объяснить точку зрения @ vikramvi: мы также можем использовать git stash pop вместо git stash apply . Первый удаляет его из тайника, в то время как последний все еще держит его тамВы можете попробовать один из следующих методов:
перебазироваться
Для простых изменений попробуйте перебазировать поверх него, потянув за изменения, например:
Таким образом, он будет применять вашу текущую ветку к верхней ветке после загрузки.
Это эквивалентно: checkout master , fetch и rebase origin/master команда Git.
Это потенциально опасный режим работы. Он переписывает историю, которая не сулит ничего хорошего, когда вы уже опубликовали эту историю. Не используйте эту опцию, если вы не прочитали git-rebase(1) внимательно.
проверять, выписываться
Если вас не волнуют ваши локальные изменения, вы можете переключиться на другую ветку временно (с применением силы) и переключить ее обратно, например,
сброс
Если вас не волнуют ваши локальные изменения, попробуйте сбросить его в HEAD (исходное состояние), например
Если вышеупомянутое не поможет, это могут быть правила в вашем файле нормализации git ( .gitattributes ), поэтому лучше зафиксировать то, что он говорит. Или ваша файловая система не поддерживает разрешения, поэтому вы должны отключить ее filemode в своем git config.
@ trinity420 Может ли это быть вашими правами доступа к файлам, проверьте, git status какие у вас изменения после сохранения. Если ни один ответ не помогает, рассмотрите возможность добавления нового вопроса. спасибо, но моя проблема решена, все перепробовал здесь, ничего не получалось, затем нажал «зафиксировать изменения», «объединить» в PHPStorm, а затем я развернул изменения, и это сработало ..и попробуйте снова потянуть
Итак, ситуация, с которой я столкнулся, была следующей:
ошибка: Ваши локальные изменения в следующих файлах будут перезаписаны слиянием: wp-content / w3tc-config / master.php Пожалуйста, передайте свои изменения или сохраните их перед тем, как объединить.
кроме, прямо перед этим, был удаленным: так на самом деле это:
remote: error: Ваши локальные изменения в следующих файлах будут перезаписаны слиянием: some / file.ext Пожалуйста, передайте свои изменения или сохраните их перед тем, как объединить.
То, что происходило, было (я думаю, не на 100% положительным), крюк получения git post начал работать и облажаться из-за изменений движения в репозитории удаленного сервера, которые теоретически не должны были быть затронуты.
Читайте также: