Не коммитится файл git
Обновлено: 07.07.2024
Я прошу прощения, если это вопрос новичка, но я искал вокруг, и я ошеломлен, почему это так.
У меня есть несколько файлов, которые я хотел бы добавить и зафиксировать.
git add . Я также пытался git add -A , git add -f -A
git commit -m 'message'
git log --graph --decorate --pretty=oneline --abbrev-commit master origin/master temp (чтобы убедиться, что моя основная ветвь находится на последнем коммите)
git push origin master
Пока нет никаких изменений. Толчок был успешным. Но файлы не добавляются в мой репозиторий. Что может быть причиной?
Я попытался заново создать папку с помощью rm -rf .git , а затем повторил все шаги. Но когда я делаю git add -A снова, новые файлы все еще не добавляются! Моя папка кажется проклятой или что-то в этом роде.
Результаты ls -la
Результаты git ls-tree HEAD
Я нашел проблему. Я использую Ubuntu, и новые файлы не имеют прав доступа. Мне пришлось дать текущему пользователю права доступа к этим новым файлам с chmod 755 , и после этого он работает.
Извините, я не упомянул об этом в первоначальном вопросе. Спасибо всем, кто предоставил ответы.
3 ответа
Давайте проясним несколько понятий git:
Ваш локальный каталог - это git-репозиторий. Все команды git так или иначе взаимодействуют с локальным хранилищем. Некоторые команды также взаимодействуют с удаленным хранилищем
git add . переместит все файлы в текущем каталоге в промежуточную область вашего локального репозитория. Всякий раз, когда вы делаете это, git всегда добавляет файлы , потому что именно так работает git. Обратите внимание, что «добавление» файлов только ставит их в очередь для следующего git commit .
git commit создает коммит в вашем локальном git-репозитории с файлами, которые вы ранее добавили в промежуточную область. Опять же, эта команда всегда будет делать это. Фактически, вывод git ls-files в вашем посте доказывает, что все ваши файлы были добавлены и переданы в ваш локальный репозиторий.
Ваше локальное хранилище может быть подключено к удаленному хранилищу на GitHub или любом другом сервере, на котором запущен git. Если вы сделаете git clone , у вашего локального репо будет удаленный сервер с именем origin , который указывает на репо, который вы клонировали. Если вы делаете git init вместо этого, вы можете использовать git remote add для добавления пульта с любым именем, которое вы пожелаете.
После настройки удаленного репо в локальном репо вы можете использовать git push для передачи коммитов из локального репо в удаленный. Кроме того, git pull будет передавать коммиты с удаленного в локальное хранилище.
Если он не обнаруживает изменения, то вы можете начать все сначала. Просто удалите файл .git из каталога и повторите инициализацию. Это не может быть хорошей практикой, но если вы новичок в git, то иногда такое исправление помогает.
Также убедитесь, что ваши учетные данные для доступа установлены правильно.
Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!
Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!
2. Упс… Я забыл добавить файл к последнему коммиту
Другая популярная ошибка в Git — слишком поспешный коммит. Вы забыли добавить файл, забыли его сохранить или должны внести небольшое изменение, чтобы коммит стал осмысленным? Вашим другом снова будет --amend .
Добавьте недостающий файл и выполните эту верную команду:
3. Упс… Я добавил файл, который не должен быть в этом репозитории
Но что, если у вас обратная ситуация? Что, если вы добавили файл, который не хотите коммитить? Обманчивый ENV-файл, директорию сборки или фото с котом, что было случайно сохранено в неправильном каталоге… Всё решаемо.
Если вы сделали только stage для файла и ещё не коммитнули его, всё делается через простой reset нужного файла (находящегося в stage):
Если же вы всё-таки коммитнули изменение, потребуется дополнительный предварительный шаг:
Коммит будет откачен, картинка удалена, а затем сделан новый коммит.
Прим. перев.: Как замечено в комментариях к оригинальной статье, эту проблему тоже можно решить с помощью уже упомянутого --amend . По всей видимости, данным пунктом автор хотел показать, какие ещё есть способы изменения истории коммитов для исправления ошибки.
4. Упс… Я коммитнул изменения в master
Итак, вы работаете над новой фичей и поспешили, забыв создать новую ветку для неё. Вы уже коммитнули кучу файлов и все эти коммиты оказались в master'е. К счастью, GitLab может предотвращать push'ы прямо в master. Поэтому мы можем откатить все нужные изменения в новую ветку следующими тремя командами:
Примечание: Убедитесь, что сначала коммитнули или stash'нули свои изменения — иначе все они будут утеряны!
Будет создана новая ветка, в master'е — произведён откат до состояния, в котором он был до ваших изменений, а затем сделан checkout новой ветки со всеми вашими изменениями.
5. Упс… Я сделал ошибку в названии ветки
Самые внимательные могли заметить в предыдущем примере ошибку в названии ветки. Уже почти 15:00, а я всё ещё не обедал, поэтому мой голод назвал новую ветку (branch) как future-brunch. Вкуснотища!
Переименуем эту ветку аналогичным способом, что используется при переименовании файла с помощью команды mv, то есть поместив её в новое место с правильным названием:
Если вы уже push'нули эту ветку, понадобится пара дополнительных шагов. Мы удалим старую ветку из remote и push'нем новую:
Прим. перев.: Удалить ветку из remote ещё можно с помощью:
6. Oops… I did it again!
Последняя команда на тот случай, когда всё пошло не так. Когда вы накопировали и навставляли кучу решений со Stack Overflow, после чего в репозитории всё стало ещё хуже, чем было в начале. Все мы однажды сталкивались с подобным…
git reflog показывает список всех выполненных вами операций. Затем он позволяет использовать магические возможности Git'а по путешествию во времени, т.е. вернуться к любому моменту из прошлого. Должен отметить, что это ваша последняя надежда — не стоит прибегать к ней в простых случаях. Итак, чтобы получить список, выполните:
Каждый наш шаг находится под чутким наблюдением Git'а. Запуск команды на проекте выше выдал следующее:
Обратите внимание на самый левый столбец — это индекс. Если вы хотите вернуться к любому моменту в истории, выполните следующую команду, заменив на соответствующее значение (например, dfa27a2 ):
Итак, теперь у вас есть шесть способов выбраться из самых частых Gitfalls (игра слов: pitfall переводится как «ловушка, ошибка» — прим. перев.).
Бонус от переводчика
Во-первых, ценное замечание ко всему написанному выше (кроме пункта 5). Нужно учитывать, что эти действия меняют историю коммитов, поэтому их следует проводить, только если изменения не были отправлены в remote (push'нуты). В противном случае старый плохой коммит уже будет на remote-ветке и придётся либо выполнять git pull (который сделает merge, и тогда попытка «почистить» историю приведёт к худшим последствиям), либо git push --force , что чревато потерей данных при работе с веткой нескольких человек…
GitHub: Ссылка на другой JavaScript тоже в Github
Здравствуйте. Есть у меня на ГитХабе код. HTML, одна простенькая страничка. В работе этой.
Мамка и множитель процессора
Доброго времени суток. У меня сложный выбор - стандартный игровой процессор fx 6350, 3.9 ггц без.
Конфликт мамка с винтом
мать NF4ST-A9 винт Maxtor Sata 80Gb, модель: 6V080E0 Проблема: После переустановки виндовса.
Ситуация была такая. У меня репозиторий /home/myRepo. Я клонирую в него чей-то репозиторий /home/myRepo/folder/someRepoFromWeb. Удаляю /home/myRepo/folder/someRepoFromWeb/.git . Получаю, что в моем home/myRepo есть всего лишь папка /home/myRepo/folder/someRepoFromWeb. Свой репозиторий я не порушил. /home/myRepo/.git я не трогал.
Все решилась после того как еще раз склонировал репозиторий, снова удалил .git.
Rius, чтобы склонированный репозиторий представлял из себя дерикторию. parkito, а если в исходном репозитории склонированного появятся новые коммиты? Надо будет заново копировать и удалять папку .git? Rius, В данном случае нужно было лишь единичное скачивание.название темы меня очень насторожило :D
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Программатор. Биос. Мертвая мамка
Всем привет, купил новый проц, биос начал возникать: "Мол обновляй меня!" Обновил, все было хорошо.
Подскажите с БИОСом (мамка не заводится)
Всем привет, посоветуйте "чайнику". После нескольких попыток разгона ЧП и Ram ddr3, не запускается.
Недорогая мамка на fx 8320 c разгоном
нужна мамка на fx 8320 с разгоом около 4500 5000 mg
Не врубается мамка Asrock z97 pro4
Мать: Asrock z97 pro4 Проц: i5 4440 Видео: gtx 950 Вобщем дебильная история приключилась.
Предполагается, что читатель этой статьи уже знаком с основами Git. Если это не так — сначала рекомендуется освоить базу, например, воспользовавшись этим материалом.
Здесь мы рассмотрим несколько сценариев появления ошибок в коммитах и их исправления.
Сценарий №1
Сценарий №2
Такой подход вполне имеет право на жизнь. Но для того, чтобы поддерживать историю коммитов в хорошем состоянии, вероятно, было бы куда лучше иметь возможность добавить случайно пропущенный файл в тот же коммит. Сделать это можно, опять же, командой git commit --amend . Выглядит её использование так:
Сценарий №3
К коммитам, которые делают в Git, привязаны имя автора и адрес его электронной почты. Обычно эти данные указывают, выполняя первоначальную настройку Git. В результате тот, кто использует Git, может, выполняя каждый коммит, не заботиться о сведениях об его авторе.
При этом вполне возможна ситуация, когда, при работе с некоторыми проектами, будет нужно пользоваться сведениями об авторе, например — адресом электронной почты, отличающимися от основных. Для подобного проекта нужно указать адрес электронной почты, воспользовавшись такой командой:
Примечание
Используйте команду amend только в своём локальном репозитории. Её применение в удалённых репозиториях может привести к огромной путанице.
Предположим, вы работаете над неким фрагментом кода какого-то проекта. Вам известно, что это займёт примерно десять дней. В течение этих десяти дней другие разработчики делают коммиты в исходный репозиторий.
Рекомендуется поддерживать синхронизацию между локальным и удалённым репозиториями. Это позволяет избежать множества конфликтов, связанных со слиянием, возникающих при слишком редкой синхронизации репозиториев. Следуя этой практике, вы решаете загружать изменения из удалённого репозитория каждые два дня.
Каждый раз, когда вы загружаете код из удалённого в локальный репозиторий, в локальном репозитории создаётся новый коммит-слияние (Merge Commit). Это означает, что в вашей локальной истории коммитов будет много таких коммитов, которые могут запутать того, кто будет просматривать ваш код.
Как привести в порядок историю коммитов? Для решения этой задачи можно воспользоваться командой git rebase .
Рассмотрим команду git rebase на примере.
В ветке Release есть три коммита: Rcommit1 , Rcommit2 , и Rcommit3 . Вы создали свою ветку Feature из ветки Release , когда в ней был всего один коммит — Rcommit1 . После этого вы добавили два коммита в ветку Feature . Это — Fcommit1 и Fcommit2 . Ваша цель заключается в том, чтобы загрузить коммиты из ветки Release в свою ветку Feature . Для того чтобы это сделать, вы собираетесь воспользоваться командой rebase .
Будем использовать для двух рассматриваемых веток имена release и feature .
В результате применение команды rebase будет выглядеть так:
Команда rebase используется для того, чтобы обеспечить наличие в ветке Feature свежего кода из ветки Release .
При применении этой команды система пытается добавить в ветку Feature каждый коммит, по одному, и осуществить проверку на наличие конфликтов. Если звучит это сложно — давайте рассмотрим следующий рисунок. Тут показаны внутренние механизмы команды rebase .
Шаг 1
В момент вызова команды ветка Feature указывает на голову ветки Release . После этого в ветке Feature оказывается три коммита: Rcommit1 , Rcommit2 , и Rcommit3 . Возможно, тут у вас появится вопрос о том, что случилось с коммитами Fcommit1 и Fcommit2 . Эти коммиты никуда не делись, они будут использованы на следующих шагах.
Шаг 2
Теперь Git пытается добавить коммит Fcommit1 в ветку Feature . При отсутствии конфликта Fcommit1 добавляется после Rcommit3 . При обнаружении конфликта Git сообщит об этом и вам придётся разрешить этот конфликт вручную.
Шаг 3
После того, как в ветку Feature добавлен коммит Fcommit1 , Git пытается добавить туда же Fcommit2 . Тут, опять же, если конфликтов нет, то Fcommit2 добавляется после Fcommit1 и операция оказывается успешно завершённой. Если обнаружен конфликт, то Git, как и прежде, сообщит об этом и предложит с ним разобраться.
После завершения работы команды rebase можно будет увидеть, что в ветке Feature имеются коммиты Rcommit1 , Rcommit2 , Rcommit3 , Fcommit1 , и Fcommit2 .
При работе с Git находят применение и команда merge , и команда rebase . Нельзя сказать, что одна из них предпочтительнее другой.
В случае использования команды merge вы получите коммит-слияние. В случае использования rebase никаких дополнительных коммитов у вас не будет.
Рекомендуется использовать эти команды в различных ситуациях. Так, rebase подходит для обновления кода локального репозитория на основе свежего кода из удалённого репозитория. Используйте команду merge , выполняя пулл-запросы, направленные на слияние ветки Feature с веткой Release или Master .
Изучив представленные в этом материале концепции, вы улучшили свои навыки владения Git и приблизились к уровню Git-эксперта. Надеемся, то, что вы тут узнали, вам пригодится. Но мир Git огромен, поэтому, освоив что-то новое, не останавливайтесь на достигнутом и двигайтесь дальше.
Читайте также: