Не коммитится файл git
Если вы хотите получше узнать те части Git, про которые раньше боялись спросить, то этот список для вас. Тут собраны наиболее типичные ситуации и способы их решения как из личного опыта автора, так и собранные по всему Интернету.
Ну отлично. Я закоммитил не в ту ветку!
Многие в такой ситуации предлагают использовать cherry-pick , так что можете выбрать, что вам больше по душе.
Переименовать локальную ветку
git branch -m oldname newname
Бонус от переводчика
Во-первых, ценное замечание ко всему написанному выше (кроме пункта 5). Нужно учитывать, что эти действия меняют историю коммитов, поэтому их следует проводить, только если изменения не были отправлены в remote (push'нуты). В противном случае старый плохой коммит уже будет на remote-ветке и придётся либо выполнять git pull (который сделает merge, и тогда попытка «почистить» историю приведёт к худшим последствиям), либо git push --force , что чревато потерей данных при работе с веткой нескольких человек…
Если вы когда-нибудь работали над большим проектом, в котором, помимо вас, участвуют и многие другие программисты, тогда вы, очевидно, применяли Git в роли системы контроля версий. В ходе использования чего-то, по уровню сложности похожего Git, все совершают ошибки.
Автор материала, перевод которого мы публикуем сегодня, собирается обсудить распространённые ошибки, которые совершают программисты при работе с Git, и поговорить о том, как с этими ошибками бороться.
Как добавить пустую директорию в репозиторий?
Никак! Такая возможность просто не поддерживается, т.к. считается, что вам это не нужно. Но есть один трюк. Можно создать файл .gitignore в нужной директории со следующим содержимым:
Удалить все локальные файлы и директории, которые не отслеживает Git, из вашей текущей копии
Осторожно! Лучше сделайте перед этим бэкап.
Клонировать все ветки с сервера
Скорее всего, вы это уже сделали, а ветки просто скрыты. Вот команда, чтобы показать их:
Можно использовать git checkout origin/имя_ветки , чтобы посмотреть на нужную ветку. Или git checkout -b имя_ветки origin/имя_ветки , чтобы создать локальную ветку, соответствующую удалённой.
Как отменить последний коммит?
Можно использовать git reset , вот так:
git reset --hard HEAD~1
HEAD~1 означает один коммит до HEAD, т.е. до текущего положения. Стоит заметить, что это «ядерный» способ, который отменит все изменения. Если вам нужно сохранить всё, что вы сделали, но еще не успели закоммитить, используйте:
git reset --soft HEAD~1
Перезаписать локальные файлы во время git pull
Вам снова поможет git reset :
git fetch --all
git reset --hard origin/master
Удалить ветку на сервере
git push origin --delete имя_ветки
Ошибка в имени ветки
Предположим, что на часах почти 15:00, а вы ещё не обедали. В результате, терзаемые голодом, вы назвали новую ветку feature-brunch . Вкуснятина, ничего не скажешь.
Эту проблему тоже можно решить. Переименовать ветку можно так же, как переименовывают файлы с помощью команды mv . Речь идёт о перемещении её в новое место с правильным именем:
Мне нужно каким-то образом отменить коммит, который был сделан 5 коммитов назад
Вам не обязательно откатываться назад и копипастить старые файлы, замещая ими новые. Если вы закоммитили баг, то коммит можно отменить с помощью revert .
Помимо этого, откатить можно не целый коммит, а отдельный файл. Но следуя канону Git’а, это будут уже совсем другие команды…
Как отменить «git add» до коммита?
Вы выполнили git add имя_файла случайно и хотите отменить добавление файла. Если коммит ещё не был сделан, то поможет:
git reset имя_файла
Удалить подмодуль (submodule)
Создание подмодулей используется довольно редко, но иногда они всё-таки встречаются. Вот, что вам нужно:
git submodule deinit submodulename
git rm submodulename
git rm --cached submodulename
rm -rf .git/modules/submodulename
6. Oops… I did it again!
Последняя команда на тот случай, когда всё пошло не так. Когда вы накопировали и навставляли кучу решений со Stack Overflow, после чего в репозитории всё стало ещё хуже, чем было в начале. Все мы однажды сталкивались с подобным…
git reflog показывает список всех выполненных вами операций. Затем он позволяет использовать магические возможности Git'а по путешествию во времени, т.е. вернуться к любому моменту из прошлого. Должен отметить, что это ваша последняя надежда — не стоит прибегать к ней в простых случаях. Итак, чтобы получить список, выполните:
Каждый наш шаг находится под чутким наблюдением Git'а. Запуск команды на проекте выше выдал следующее:
Обратите внимание на самый левый столбец — это индекс. Если вы хотите вернуться к любому моменту в истории, выполните следующую команду, заменив на соответствующее значение (например, dfa27a2 ):
Итак, теперь у вас есть шесть способов выбраться из самых частых Gitfalls (игра слов: pitfall переводится как «ловушка, ошибка» — прим. перев.).
Я случайно закоммитил что-то в мастер, хотя должен был в новую ветку!
Команды не сработают, если вы уже закоммитили в публичную ветку. В таком случае может помочь git reset HEAD@ вместо HEAD~ .
Ошибка в комментарии к коммиту
git commit --amend
Случайный коммит изменений в ветку master
Предположим, вы работаете над некоей новой возможностью, и, в спешке, забыли создать для неё новую ветку. Вы закоммитили уже кучу файлов и всё это лежит в ветке master . Переместить все эти изменения в новую ветку можно с помощью следующих трёх команд. Обратите внимание на то, что если вы не воспользовались, в применении к изменениям, командами commit или stash , они будут утеряны.
В результате будет создана новая ветка, будет произведён откат изменений в ветке master , до состояния, в котором она была до внесения изменений, и будет осуществлён переход в новую ветку, которая будет содержать в себе все изменения, внесённые ранее в master .
Работа с файлами, которые забыли добавить в последний коммит
Ещё одна распространённая оплошность при работе с Git заключается в том, что коммиты делают слишком рано и в них не попадают нужные файлы. Скажем, вы пропустили некий файл, забыли его сохранить, или вам нужно внести небольшое изменение в файл для того, чтобы последний коммит имел смысл. В подобной ситуации вам снова пригодится команда --amend . Добавьте пропущенный файл в индекс репозитория и запустите эту команду:
Итоги
Мы рассмотрели некоторые способы борьбы с ошибками, возникающими при работе с Git. Надеемся, вы подобных ошибок не допустите и вам эти приёмы работы с Git не пригодятся. А если что-то пойдёт не так — вы будете знать, что делать.
- Вопрос задан более двух лет назад
- 2302 просмотра
Судя по снимку экрана изменений вообще нет (Область "Unstaged Changes" пустая, область "Staged Changes" пустая). Если изменения всё-таки есть, то можно проверить, добавлены ли файлы в .gitignore. Отредактируйте этот файл при необходимости и проверьте, есть ли отображаемые изменения.
Если файла .gitignore нет, либо он пустой, либо там не включены файлы, которые вы изменили, то откройте всё-таки командную строку и проверьте в своём клоне:
$ git status
^-- отобразит изменения файлов и файлы, которые отслеживаются/не отслеживаются.
$ git add filename
^-- добавит файл для контроля изменений
$ git status
^-- покажет, что файл добавлен
$ git commit -m "message text"
^-- зафиксирует изменения
Далее приведу пример, как это может случиться при использовании .gitignore
Из последнего листинга видно, что если добавлен файл в .gitignore, то он не будет отображён при отслеживании изменений.
чёт не понятно
вот скрин папки на компе, там есть файлы, а на гите вообще пусто
и скрин командной строки
я первый раз вообще им пользуюсь может вообще что то не так сделал
Nohaga, конечно, не факт, но можно предположить, что неправильно с путями работает. Попробуйте переименовать "https:github.com" директорию, чтобы не содержала двоеточие. После этого в этой директории выполните "git status".
Хотя сейчас проверил на виртуалке у себя, там отображается вполне.
Опишите действия, которые Вы выполняете, чтобы можно было все шаги воспроизвести у себя в системе.
Борис Дергачёв, хмм ведь программа сама такой путь создаёт, я переместил и заработало, только новая ошибка
Nohaga, на скрине из вопроса видно: "commit message" -- слона то и не заметили. В ту область пишите текст коммита.
Рассказываем о командах, которые помогут вам выбраться из проблемных ситуаций.
В чём разница между «git pull» и «git fetch»?
git pull — это, по сути, git fetch , после которого сразу же следует git merge . git fetch получает изменения с сервера и сохраняет их в refs/remotes/ . Это никак не влияет на локальные ветки и текущие изменения. А git pull вливает все эти изменения в локальную копию.
Вот блин, я сделал что-то не то… У Git ведь есть машина времени?!
Так вы можете восстановить то, что случайно удалили, и откатить слияние, после которого всё сломалось. reflog используется очень часто — давайте поблагодарим того, кто предложил добавить его в Git.
Обычно эта команда нужна если вы что-то закоммитили, а потом заметили какую-то мелочь, например отсутствующий пробел после знака = . Конечно вы можете внести изменения новым коммитом, а потом объединить коммиты с помощью rebase -i , но это гораздо дольше.
Внимание Никогда не изменяйте коммиты в публичной ветке. Используйте эту команду только для коммитов в локальной ветке, иначе вам конец.
2. Упс… Я забыл добавить файл к последнему коммиту
Другая популярная ошибка в Git — слишком поспешный коммит. Вы забыли добавить файл, забыли его сохранить или должны внести небольшое изменение, чтобы коммит стал осмысленным? Вашим другом снова будет --amend .
Добавьте недостающий файл и выполните эту верную команду:
Вернуться к любому коммиту
Можно использовать git reset , как показано ранее. Это будет означать, что вы хотите навсегда вернуться к тому состоянию, в котором вы были, а не просто посмотреть на него (для этого надо сделать checkout). Идентификатор коммита должен быть такой, какой прописан в выводе команды git log .
git reset --hard идентификатор_коммита
Ещё раз повторим: команда отменит все текущие изменения, так что убедитесь, что вам это действительно нужно. Или используйте --soft вместо --hard.
Экспортирование исходников аналогично «svn export»
Используйте git archive , например, так:
git archive --format zip --output /путь/к/файлу/файл.zip master
Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!
Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!
Добавление не того файла в репозиторий
Если вы продвинулись достаточно далеко и успели изменение закоммитить, то знайте, что и это поправимо. Придётся лишь воспользоваться ещё несколькими командами:
В результате последний коммит будет отменён, изображение будет удалено, после чего новый коммит будет помещён туда, где ему положено быть.
4. Упс… Я коммитнул изменения в master
Итак, вы работаете над новой фичей и поспешили, забыв создать новую ветку для неё. Вы уже коммитнули кучу файлов и все эти коммиты оказались в master'е. К счастью, GitLab может предотвращать push'ы прямо в master. Поэтому мы можем откатить все нужные изменения в новую ветку следующими тремя командами:
Примечание: Убедитесь, что сначала коммитнули или stash'нули свои изменения — иначе все они будут утеряны!
Будет создана новая ветка, в master'е — произведён откат до состояния, в котором он был до ваших изменений, а затем сделан checkout новой ветки со всеми вашими изменениями.
Я пытаюсь запустить diff, но ничего не происходит
Если вы знаете, что изменения были внесены, но diff пуст, то возможно вы индексировали изменения (через add ). Поэтому вам нужно использовать специальный флаг.
Конечно, «это не баг, а фича», но с первого взгляда это чертовски неоднозначно.
3. Упс… Я добавил файл, который не должен быть в этом репозитории
Но что, если у вас обратная ситуация? Что, если вы добавили файл, который не хотите коммитить? Обманчивый ENV-файл, директорию сборки или фото с котом, что было случайно сохранено в неправильном каталоге… Всё решаемо.
Если вы сделали только stage для файла и ещё не коммитнули его, всё делается через простой reset нужного файла (находящегося в stage):
Если же вы всё-таки коммитнули изменение, потребуется дополнительный предварительный шаг:
Коммит будет откачен, картинка удалена, а затем сделан новый коммит.
Прим. перев.: Как замечено в комментариях к оригинальной статье, эту проблему тоже можно решить с помощью уже упомянутого --amend . По всей видимости, данным пунктом автор хотел показать, какие ещё есть способы изменения истории коммитов для исправления ошибки.
Давай по новой, Миша, всё х**ня
Если вам нужно полностью откатиться до исходной версии (т. е. отменить все изменения), то можете попробовать сделать так.
Будьте осторожны, эти команды разрушительны и необратимы.
Эти команды Git нужны для экстренных ситуаций, но пригодиться могут не только они. Про другие команды с пояснениями писали тут:
5. Упс… Я сделал ошибку в названии ветки
Самые внимательные могли заметить в предыдущем примере ошибку в названии ветки. Уже почти 15:00, а я всё ещё не обедал, поэтому мой голод назвал новую ветку (branch) как future-brunch. Вкуснотища!
Переименуем эту ветку аналогичным способом, что используется при переименовании файла с помощью команды mv, то есть поместив её в новое место с правильным названием:
Если вы уже push'нули эту ветку, понадобится пара дополнительных шагов. Мы удалим старую ветку из remote и push'нем новую:
Прим. перев.: Удалить ветку из remote ещё можно с помощью:
Что делать, если всё пошло не так?
Методика, которую мы сейчас обсудим, помогает в ситуациях, когда всё идёт не так, как надо. Например, такое происходит, когда вы слишком увлекаетесь копированием готовых решений со StackOverflow, и, после работы, ваш репозиторий оказывается в худшем состоянии чем он был в самом начале. В такую ситуацию, пожалуй, попадали все мы.
Команда git reflog показывает список всего, что вы сделали. Затем она позволяет воспользоваться инструментами Git для отката изменений, для возврата к одному из прошлых состояний репозитория. Стоит отметить, что этот метод стоит рассматривать как последнее средство, и, прежде чем им воспользоваться, стоит как следует подумать. Итак, вывести список того, что было сделано, можно следующей командой:
Git помнит все наши действия и в результате выполнения этой команд можно увидеть примерно следующее:
Обратите внимание на самую левую колонку этого списка. Тут содержатся индексы. Если вам нужно вернуться назад, в некий момент прошлого, выполните следующую команду, заменив соответствующей ссылкой, например — dfa27a2 . Выглядит эта команда так:
Как разрешать конфликты слияния?
Используйте программу git mergetool , которая предоставляет удобный интерфейс для разрешения конфликтов.
Мне нужно отменить изменения в файле
Именно поэтому checkout — лучший инструмент для отката изменений в файлах.
Читайте также: