Git переместить файл в другую папку

Обновлено: 05.07.2024

You can move a file to a different directory on GitHub or by using the command line.

In addition to changing the file location, you can also update the contents of your file, or give it a new name in the same commit.

Moving a file to a new location on GitHub

Tips:

If you try to move a file in a repository that you don’t have access to, we'll fork the project to your user account and help you send a pull request to the original repository after you commit your change.
Some files, such as images, require that you move them from the command line. For more information, see "Moving a file to a new location using the command line".
If a repository has any protected branches, you can't edit or upload files in the protected branch using GitHub. For more information, see "About protected branches."

You can use GitHub Desktop to move your changes to a new branch and commit them. For more information, see "Committing and reviewing changes to your project."

In your repository, browse to the file you want to move.
In the upper right corner of the file view, click

To move the file into a subfolder, type the name of the folder you want, followed by / . Your new folder name becomes a new item in the navigation breadcrumbs.
To move the file into a directory above the file's current location, place your cursor at the beginning of the filename field, then either type ../ to jump up one full directory level, or type the backspace key to edit the parent folder's name.

Moving a file to a new location using the command line

You can use the command line to move files within a repository by removing the file from the old location and then adding it in the new location.

Many files can be moved directly on GitHub, but some files, such as images, require that you move them from the command line.

This procedure assumes you've already:

Help us make these docs great!

В процессе работы над любым проектом в директории с кодом создаются файлы, которые не являются частью исходного кода. Все эти файлы можно условно разделить на несколько групп:

Инструментарий

Служебные файлы, добавляемые операционной системой (.DS_Store в Mac)
Конфигурационные и временные файлы редакторов (например, .idea, .vscode)

Временные файлы

Логи. В них содержится полезная информация для отладки, которая собирается во время запуска и работы приложения
Кеши. Файлы, которые нужны для ускорения разных процессов

Артефакты

Результаты сборки проекта. Например, после компиляции или сборки фронтенда
Устанавливаемые во время разработки зависимости (например, node_modules, vendor)
Результаты выполнения тестов (например, информация о покрытии кода тестами)

Всё это в обычной ситуации не должно попадать в репозиторий. Как правило, эти файлы не несут никакой пользы с точки зрения исходного кода. Они создаются либо автоматически (кеши, логи), либо по запросу (например, скачиваются зависимости или собирается проект). Главная проблема с этими файлами в их постоянном изменении при, как правило, очень больших размерах. Если добавлять их в репозиторий, то практически в каждом коммите, кроме изменений исходного кода, будет и пачка изменений в этих файлах. Читать историю таких коммитов крайне сложно.

Git позволяет гибко настраивать игнорирование определенных файлов и директорий. Делается это с помощью файла .gitignore:

Как только в проект добавляется файл .gitignore, то он сразу начинает работать. Все новые файлы, попадающие под игнорирование, не отобразятся в выводе команды git status . Файл .gitignore также следует выгружать в удалённый репозиторий, например, на Github.

Иногда бывает такое, что программист случайно уже добавил в репозиторий файл, который нужно проигнорировать. В этой ситуации недостаточно обновить правила игнорирования. Дополнительно придется удалить файл или директорию из git с помощью git rm и закоммитить.

Одна из ключевых возможностей git — "откат" любых сделанных изменений буквально одной командой. Такое практически невозможно сделать без использования системы контроля версий. Только если помнить все изменения наизусть. В этом уроке мы поговорим про откат изменений, которые сделаны в рабочей директории, но ещё не попали в коммит.

Важно! Откат незакоммиченных изменений безвозвратен. Не существует никакой физической возможности получить эти изменения обратно, поэтому будьте крайне осторожны.

Неотслеживаемые файлы

Самая простая ситуация. Вы добавили новые файлы в репозиторий (или сгенерировали их как-то) и поняли, что они вам не нужны. В этом случае можно выполнить очистку:

Забавный факт: про эту команду знает не так много программистов. Вы можете удивить даже опытных ребят.

Изменённые файлы в рабочей директории

Для отмены изменений в таких файлах используется команда git restore . Причём git сам напоминает об этом при проверке статуса:

Файлы, добавленные для фиксации

С файлами, подготовленными к коммиту, можно поступить по-разному. Первый вариант — отменить изменения совсем, второй — переместить изменения из индекса в рабочую директорию. Второе полезно в том случае, если изменения нам нужны, но мы не хотим их коммитить сейчас.

И здесь снова помогает git. При выводе статуса он показывает нужную нам команду для перевода изменений в рабочую директорию:

Теперь, если нужно, можно выполнить git restore и окончательно отменить изменения в выбранных файлах.

Самостоятельная работа

Выполните все шаги из урока

Вам ответят команда поддержки Хекслета или другие студенты.

Нашли опечатку или неточность?

Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.

Что-то не получается или материал кажется сложным?

задайте вопрос. Вы быстрее справитесь с трудностями и прокачаете навык постановки правильных вопросов, что пригодится и в учёбе, и в работе программистом;
расскажите о своих впечатлениях. Если курс слишком сложный, подробный отзыв поможет нам сделать его лучше;
изучите вопросы других учеников и ответы на них. Это база знаний, которой можно и нужно пользоваться.

Об обучении на Хекслете

Статья «Как учиться и справляться с негативными мыслями»
Статья «Ловушки обучения»
Статья «Сложные простые задачи по программированию»
Урок «Как эффективно учиться на Хекслете»
Вебинар «Как самостоятельно учиться»

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.

Предлагаю вашему вниманию небольшую шпаргалку по основным командам bash, git, npm, yarn, package.json и semver.

Условные обозначения: [dir-name] — означает название директории, | — означает «или».

Рекомендую вводить каждую команду в терминале и внимательно изучать вывод, так вы быстро их запомните и определите, какие команды вам нужны, а какие нет.

Приношу извинения за возможные ошибки и опечатки. Буду рад любым замечаниям и предложениям.

Без дальнейших предисловий.

bash представляет собой инструмент командной строки, позволяющий выполнять некоторые распространенные действия.

Установка: в моем случае bash был установлен вместе с git.

Выход из терминала:

Путь к текущей директории:

Копирование, перемещение и удаление файла:

Вывод в терминал строки:

git представляет собой распределенную систему контроля версий, позволяющую контролировать процесс внесения изменений в проект.

Удаление файлов и директорий:

Просмотр состояния репозитория:

Просмотр разницы между коммитами:

Просмотр истории изменений:

Работа с ветками:

Разрешение конфликтов при слиянии:

Сохранение незакоммиченных изменений:

Автозавершение повторных конфликтов:

Пример алиасов (сокращений) для .gitconfig:

npm представляет собой пакетный менеджер, позволяющий устанавливать зависимости проекта.

npm устанавливается вместе с Node.js.

Также вместе с Node.js устанавливается npx, позволяющий запускать исполняемые файлы без установки: npx create-react-app my-app.

Список доступных команд:

Принудительная переустановка зависимостей:

Установка только продакшн-пакетов:

Добавление зависимости для разработки:

Глобальная установка/обновление/удаление пакета:

Определение устаревших пакетов:

Список установленных зависимостей:

Информация о пакете:

Запуск скрипта/выполнение команды:

Удаление дублирующихся пакетов:

Удаление посторонних пакетов:

Обнаружение уязвимостей (угроз безопасности):

Автоматическое исправление уязвимостей:

yarn, как и npm, представляет собой пакетный менеджер, позволяющий устанавливать зависимости проекта.

Команда «yarn dlx» позволяет запускать исполняемые файлы без установки: yarn dlx create-react-app my-app. Для этого yarn необходимо обновить до второй версии: yarn set version berry.

Список доступных команд:

Принудительная переустановка зависимостей:

Установка только продакшн-пакетов:

Добавление зависимости для разработки:

Глобальная установка/обновление/удаление пакета:

Список установленных зависимостей:

Информация о пакете:

Запуск скрипта/выполнение команды:

package.json

name — название проекта
version — версия проекта (см. версионирование)
description — описание проекта (зачем нужен пакет?)
keywords — ключевые слова (облегчает поиск в реестре npm)
private — установка значения в true предотвращает случайную публикацию пакета в реестре npm
main — основная точка входа для функционирования проекта
repository — ссылка на репозиторий (один из вариантов)
author — автор проекта (один из вариантов)
contributors — участники проекта (люди, внесшие вклад в проект)
dependencies — зависимости проекта (пакеты, без которых приложение не будет работать)
devDependencies — зависимости для разработки (пакеты, без которых приложение будет работать)
scripts — команды (выполняемые сценарии, задачи), предназначенные для автоматизации, например, команда «yarn dev» запустит скрипт «nodemon server.js»

Файлы «package-lock.json» и «yarn.lock» содержат более полную информацию об установленных пакетах, чем package.json, например, конкретные версии пакетов вместо диапазона допустимых версий.

Версионирование

Каждый пакет имеет версию, состоящую из трех цифр (например, 1.0.0), где первая цифра — мажорная версия (major), вторая — минорная версия (minor), третья — патчевая версия (патч, patch). Выпуск новой версии называется релизом.

Увеличение каждой из этих цифр согласно правилам семантического версионирования (semver) означает следующее:

Читайте также: