Как удалить файл из репозитория github

Изменение файлов в Git (как удалить и переименовать файлы в git)

Мы уже знаем, как добавить файлы в промежуточную область git через Git bash, как записать содержимое в файл в этих файлах, как зафиксировать файл.

Этих операций достаточно для основы, но по мере того, как мы прогрессируем, наши ненужные файлы увеличиваются в хранилище. Кроме того, до сих пор не было возможности переименовать файл. После того как вы создали файл в Git, его имя оставалось неизменным на протяжении всего проекта. Сосредоточившись на том же вопросе, мы изучим некоторые операции в Git, которые охватывают изменения файлов в Git и научимся:

Как удалить файл с помощью Git в репозитории Git

Прежде чем начать что-то новое в Git, мы должны проверить состояние нашего репозитория. Это должен быть чистый репозиторий (никаких изменений, ожидающих фиксации в промежуточной области).

Начав работу, проверьте состояние репозитория, набрав git status:

Теперь, чтобы удалить файл, нужно создать файл. Создайте новый файл toolsqa.txt

touch toolsqa.txt

Добавьте это в промежуточную область и зафиксируйте изменения.

1 — Добавление изменений в промежуточную область.

2 — Проверка состояния репозитория Git.

3 — Фиксация изменений в репозитории Git.

Итак, теперь мы добавили этот файл в репозиторий Git. Давайте теперь удалим этот файл, набрав следующую команду и нажав клавишу enter:

git rm

Теперь давайте проверим состояние git и сообщение, которое он выдаст.

Переименование файлов в репозитории Git

Переименование файлов также является одной из наиболее часто используемых операций над файлом. Переименование может быть сделано из-за многих факторов. Как разработчик, возможно, вы хотите переименовать файл, созданный вашим коллегой-разработчиком. Какова бы ни была причина, вы будете часто сталкиваться с переименованием. Будучи важной частью Git, мы должны научиться переименовывать файл в репозитории Git.

Как переименовать файл с помощью Git

Поскольку у нас нет никакого файла в репозитории Git, создайте новый файл, например toolsqa.txt. После этого вы должны проверить состояние git. Подтвердите, что это чистый каталог, как мы уже делали выше. Как только все будет сделано, введите следующую команду и нажмите клавишу enter:

git mv

Проверьте состояние репозитория через git status.

Git обнаружил, что файл был переименован. Запомните этот шаг, так как он будет играть важную роль, когда мы будем переименовывать файл вне git. Зафиксируйте эти изменения.

Как переименовать файл вне Git

В этом разделе мы рассмотрим, как Git реагирует, когда файл переименовывается, не сообщая об этом Git. Используйте ту же команду без “git”.

Введите следующую команду в Git Bash и нажмите клавишу enter:

Теперь, в идеале, Git должен был знать, что файл был переименован, как если бы мы переименовали его через Git. Но давайте посмотрим на реакцию Git, когда он сталкивается с переименованием файла вне Git.

Здесь очень важно заметить реакцию Git. Git удалил файл под названием renaming.txt и добавил новый файл toolsqa.txt. Оба они в настоящее время не присутствуют в плацдарме. Это совсем не то, что мы видели выше. Там Git упомянул, что файл был переименован. Теперь нам нужно добавить эти изменения в промежуточную зону.

Теперь Git распознал переименование и, следовательно, показывает вам то же самое. Зафиксируйте эти изменения в репозитории Git. Вы заметите что-то, когда будете фиксировать изменения.

Означает, что предыдущий файл и новый файл абсолютно одинаковы и нет никакой разницы. Это называется уровнем доверия. Если бы вы внесли какие-либо изменения в новый файл, а затем зафиксировали эти изменения, он показал бы менее 100%.

В последнем уроке мы познакомились с командой Git fetch и Read more

В одной из последних статей мы узнали о команде Git Read more

Мы уже знаем, как вносить изменения в локальное хранилище и Read more

Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more

«Клонирование» означает создание идентичных особей естественным или искусственным путем. Клонирование Read more

Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more

Git Commit

Эта статья — шпаргалка по команде commit и сопутствующим ей командам: add, rm, reset. Здесь рассказывается, как отправить файлы в локальный репозиторий (commit), как подготовить их к отправке (add), как отменить последний снимок (с помощью команды reset) и как удалить отдельные файлы из индекса или даже из снимка.

Команда git add

Команда commit отправляет файлы в локальный репозиторий.

Однако перед выполнением команды commit надо подготовить файлы — составить список тех из них, которые будут отправлены в репозиторий. Команда git add позволяет это сделать — добавляет файлы и папки в индекс (область staging area). В GIT есть понятие staged files — это файлы, которые попадут в следующий снимок при выполнении команды commit.

Дело в том, что в параметрах commit не указывается, какие файлы включать в снимок. Это делается заранее в команде add, а в команде commit пишется просто комментарий и в репозиторий отправляются все подготовленные файлы из индекса (staging area).

Можно добавлять в индекс как файлы, так и папки. Например, эта команда подготовит для будущего снимка папку и файл :

При этом все остальные файлы, даже если они отслеживаются в репозитории (tracked files) и были отредактированы (edited files), в следующий снимок не попадут.

Есть удобные вариации команды add:

Нетрудно заметить, что команда:

эквивалентна двум поочередно выполненным командам:

Удаление файлов из репозитория и с диска

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

Если речь идет об отдельном файле, то команда:

добавляет файл в индекс как удаленный. При этом файл удаляется и с диска, если еще не был удален оттуда.

позволяет выполнить git rm для всех удаленных с диска файлов одновременно, то есть отправить их в индекс.

Удаление файлов только из репозитория

Бывает надо удалить файлы из репозитория, но не удалять с диска. Например, мы отправили в репозиторий логи, которым там не место.

А на диске они должны оставаться. Чтобы добавить этот лог в индекс как удаленный, но оставить его при этом на диске, выполним команду:

То же самое для папки делается так:

Что войдет в следующий снимок

Чтобы посмотреть, что же вы итоге подготовили для снимка, выполните команду:

Благодаря параметру —name-only выведутся только названия файлов.

Команда git commit

А дальше просто — отправьте в локальный репозиторий все находящиеся в индексе файлы, комментарий обязателен:

Эта команда создает новый snapshot — снимок репозитория. К этому снимку можно будет вернуться в будущем. Ваши данные и комментарий будут также доступны при просмотре истории.

add и commit одной строкой

Бывает удобным отправлять файлы в репозиторий побыстрее, не выполняя по очереди add и commit. Можно выполнить эти команды и вместе:

Вышеприведенная команда — это то же самое, что выполненные по очереди команды:

Кратко это звучит как «добавь в индекс все измененные файлы и сделай снимок с указанным комментарием».

Обратите внимание, что удаленные файлы затронуты не будут.

Но можно создать в конфигурации любую команду из комбинации add и commit (правда, это редко используется):

Мы создали команду add-commit. И с помощью нее можем выполнять действия:

Как отменить последний commit

Чтобы отменить последний локальный commit, выполните команду:

1 указывает на предыдущую ревизию, так что команда вернет репозиторий к предыдущему состоянию.

Как отменить git add

Чтобы удалить все файлы из staging area, выполните команду:

Чтобы удалить конкретный файл, выполните команду:

Как удалить некоторые файлы из снимка

Специальной команды тут нет. Для этого надо отменить последнюю команду commit. Эта команда сдвигает указатель на предыдущее состояние:

В индексе останутся файлы. Надо удалить из индекса нежелательный файл:

Подробнее о команде reset читайте здесь.

И затем снова отправить файлы в репозиторий. Следующая команда позволит задействовать при отправке метаданные предыдущего коммита, в том числе предыдущий комментарий:

ORIG_HEAD — ссылка на предыдущий снимок.

Как исправить комментарий снимка

Допустим, мы уже отправили изменения в локальный репозиторий, но надо исправить комментарий, так как в него закралась ошибка. Делаем так:

Добавить комментарий Отменить ответ

Прошу прощения: на комментарии временно не отвечаю.

Как убрать из Git-репозитория файлы с конфиденциальной информацией

Файлы проиндексированы, написано сообщение коммита, данные отправлены на сервер… И вдруг хочется повернуть время вспять. В коммит попал файл, которого там быть не должно. Когда такое случается, приходит время обращаться к поисковику.

Каждый разработчик когда-то по ошибке коммитил в общедоступный репозиторий файлы с конфиденциальной информацией. Как справиться с такой проблемой? Как сделать так, чтобы ничего подобного больше не случилось бы?

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

Минимизация ущерба

▍Коммит пока не отправлен в удалённый репозиторий

Если вы пока не отправили коммит в репозиторий, то, в общем-то, возникшая ситуация никакой угрозы не несёт. Для того чтобы всё исправить, достаточно просто вернуться к предыдущему коммиту:

Файлы останутся в рабочей копии репозитория, вы сможете внести в проект необходимые изменения.

Если же вы хотите сохранить коммит и вам нужно просто удалить из него определённые файлы, тогда поступите так:

Это позволит исправить неправильный коммит и поможет не потерять изменения, внесённые в проект остальными коммитами.

▍Коммит отправлен в удалённый репозиторий

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

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

Если вы отправили в репозиторий, после проблемного коммита, и другие коммиты, это не помешает вам убрать файлы с конфиденциальными данными из истории Git, воспользовавшись командой git filter-branch или инструментом BFG Repo-Cleaner.

Вот пример использования git filter-branch :

Но, делая это, учитывайте два важных аспекта подобных изменений, вносимых в репозиторий:

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

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

Даже если вы удалили эти данные из репозитория, вы ничего не сможете сделать с ботами и с форками репозитория. Как же поступить?

Рекомендации по хранению конфиденциальных файлов в проектах, в которых для контроля версий применяется Git

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

▍Используйте, если это возможно, ключи API

Скомпрометированные ключи API легко деактивировать, такие ключи легко создать заново. Если это возможно — используйте именно их, а не нечто вроде логинов и паролей.

▍Храните ключи API, пользуясь средствами вашего инструмента для сборки проектов

Управление переменными окружения

Сделайте так, чтобы Git не отслеживал бы файлы, содержащие конфиденциальную информацию.

Наличие подобного шаблонного файла помогает тем, кто работает над проектом, добавлять в проект ключи API, избавляя их от необходимости чтения документации.

▍Не меняйте историю Git в удалённых репозиториях

Постарайтесь строго придерживаться этого правила. Если вы следовали вышеприведённым рекомендациям, то историю Git вам менять и не потребуется.

Итоги

Надеюсь, мой материал поможет вам в безопасной работе с конфиденциальными данными.

А вам случалось отправлять в общедоступный репозиторий что-то такое, что туда попадать не должно?

Как удалить файл из Git repo?

17 ответов

но если вы хотите удалить файл только из репозитория Git и не удалять его из файловой системы, используйте:

и нажать изменения в удаленное РЕПО

git rm file.txt удаляет файл из РЕПО, но также удаляет его из локальной файловой системы.

обновление: этот ответ получает некоторый трафик, поэтому я подумал, что упомяну мой другой Git ответ разделяет пару больших ресурсов: на этой странице имеет графику, которая помогает прояснение Git для меня. The » Pro Git » книга онлайн и мне очень помогает.

Если ваш файл уже находится на GitHub,вы сейчас (июль 2013) можете непосредственно удалить его из веб-GUI!

просто просмотрите любой файл в репозитории, щелкните значок корзины вверху и зафиксируйте удаление, как и любое другое веб-редактирование.

(фиксация будет отражать удаление этого файла):

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

Примечание: поскольку это система управления версиями, Git всегда имеет вашу спину, Если вам нужно восстановить файл позже.

последнее предложение означает, что удаленный файл по-прежнему является частью истории, и вы можете восстановить его достаточно легко (но еще не через веб-сайт GitHub интерфейс):

Это единственный вариант, который работал для меня.

Примечание: Замените *.sql с вашим именем файла или типом файла. Будьте очень осторожны, потому что это будет проходить через каждую фиксацию и вырвать этот тип файла.

кроме того, если это папка для удаления и последующие дочерние папки или файлы, используйте:

в целом, git help поможет, по крайней мере, с простыми вопросами, как это:

Если вы хотите удалить файл из репозитория, но оставить его в файловой системе (будет прекращено):

Если вы хотите удалить файл из репозитория и из файловой системы, то есть два варианта:

Если файл не имеет изменений в индексе:

Если файл имеет изменения, расположенные в индексе:

git rm теперь будет удалять только файл в этой ветке, но он останется в истории, и git запомнит его.

но, даже после этого, Git может это помню, потому что там могут быть ссылки на него в reflog, пультов, теги и все такое.

если вы хотите полностью уничтожить его в один шаг, я рекомендую вам использовать git forget-blob

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

удалить конкретный файл

чтобы рекурсивно очистить все неотслеженные файлы из каталога одним выстрелом

Если у вас есть приложение GitHub для Windows, вы можете удалить файл в 5 простых шагов:

в моем случае я попытался удалить файл на github после нескольких коммитов, но сохранить на компьютере

и потом этот файл был проигнорирован

Сначала удалите файлы из локального репозитория.

или удалите файлы только из локального репозитория, но из файловой системы

во-вторых, зафиксировать изменения в локальном репозитории.

наконец, обновление / push локальных изменений в удаленный репозиторий.

Я пробовал много предложенных вариантов, и ни один не работал (я не буду перечислять различные проблемы). То, что я сделал, что сработало, было простым и интуитивно понятным (для меня):

у меня есть файлы obj и bin, которые случайно попали в репо, что я не хочу загрязнять список «измененных файлов»

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

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

в командной строке:

я получил тревожное сообщение:13 файлов изменено 315222 удаления

затем, потому что я не хотел искать строку CMD, я вошел в Visual Sstudio и сделал синхронизацию, чтобы применить ее к удаленному

после удаления файла из РЕПО с помощью git rm можно использовать BFG Repo-Cleaner чтобы полностью и легко уничтожить файл из истории РЕПО.

Incase если вы не файл в локальном РЕПО, но в Git РЕПО, а затем просто открыть файл в Git РЕПО через веб-интерфейс и найти кнопку Удалить в правом углу в интерфейсе. Нажмите здесь, чтобы просмотреть опцию удаления интерфейса

Шпаргалка по Git. Решение основных проблем

Поговорим о решении проблем с Git.

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

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

Если существует более одного накопления, найти нужное можно с помощью команды:

git stash list затем можно применить его, воспользовавшись его индексом:

Необходимо учитывать, что отсчёт индексов ведётся от нуля.

Восстановление удалённого тега

В том случае, если необходимо восстановить случайно удалённый тег, начать можно с его поиска:

После того, как нужный тег найден, его следует восстановить:

Восстановление удалённого файла

Если вы случайно удалили файл, его можно быстро восстановить:

Если требуется восстановить файл из конкретной временной точки истории коммитов, следует узнать хеш нужного коммита и запустить команду:

Восстановление удалённой ветки

С помощью комманды git reflog можно узнать хеш (SHA1) последнего коммита в удалённой ветке. Скопируйте этот хеш и используйте в команде:

После этого восстановить удалённую ветку можно будет вот такой командой:

Изменение сообщения коммита перед его отправкой

Сообщение можно изменить и напрямую с помощью команды

Изменение сообщения коммита после его отправки

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

Использование алиасов команд в командной строке

Устали каждый раз печатать git status? Этой команде можно присвоить простой алиас, который проще и быстрее вбивать в git.

— теперь нужно писать только git st

Можно пойти дальше и присвоить алиасы более сложным командам:

Теперь алиас git logme будет выводить все наши коммиты.

Коммит в неправильную ветку

Нужно переключиться на новую ветку, которую вы забыли предварительно создать:

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

. и «откатиться» до последнего коммита, который нужно сохранить.

Чтобы это сделать, можно воспользоваться командой git log и сохранить хеш (SHA1) последнего коммита, который нужно оставить.. Например, это a31a45c.

Предупреждение: Убедитесь в том, что никто не отправлял коммиты в оригинальную ветку во время выполнения вышеописанных процедур, в противном случае эти изменения будут потеряны!

Обновление конкретного подмодуля

Чтобы обновить конкретный подмодуль в репозитории, нужно добавить путь к подмодулю:

Откат к конкретному коммиту в истории

Если вас не очень беспокоят изменения в локальном репозитории, то можно «откатиться» к конкретному коммиту в истории с помощью команды:

Эта команда установит HEAD на конкретный коммит. Также можно воспользоваться хешем коммита.

Отмена коммита до публикации изменений

Если вы сделали коммит, который впоследствии понадобилось отредактировать или полностью стереть, поможет команда git reset.

Будьте осторожны используя второй вариант, поскольку изменения ваших локальных файлов будут потеряны.

Чтобы сохранить сообщение коммита, наберите: :

Отмена коммита после отправки его в master-репозиторий

Рассмотрим процедуру возврата одного или нескольких коммитов, которые нужно стереть из удалённой ветки. Обозначить конкретный коммит можно с помощью его хеша:

Отмена только коммита, который является вторым после последнего:

Простая отмена последнего коммита:

Отмена локальных изменений файлов

Простейшим способом избавиться от нежелательных изменений для файлов и папок является восстановление состояния последнего коммита. Сделать это можно с помощью специальной команды:

Кроме того, можно восстановить конкретный путь к файлу:

Отображение всех коммитов одного файла

Аргумент —follow позволяет вывести все изменения над файлом, даже если в процессе работы он был переименован.

Отображения числа коммитов от каждого участника

Хотите узнать, сколько коммитов сделал каждый участник команды?

Отобразить коммиты, содержащие удалённые файлы

Узнать, в каких коммитах содержатся удалённые файлы, можно с помощью команды:

Она покажет список коммитов, в которых удалялись файлы.

Отсортировать коммиты по автору

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

Очистка всех скрытых состояний

Очистить все скрытые состояния можно следующей командой:

Переименование локальной и удалённой ветки

Предложим, у вас есть ветка «fix-bug25», которую вы захотели переименовать в «hotfix-users». Прежде всего, нужно будет изменить локальную ветку:

А затем — удалённую ветку: переименовать её напрямую нельзя, поэтому нужно будет её удалить, и затем опубликовать заново уже с новым именем. Прежде чем приступать к этим процедурам, следует убедиться, что никто из членов команды не работает с этой веткой! Удаляем ветку: git push origin :fix-bug25

А теперь заново публикуем её с новым именем: git push origin hotfix-users

Переименование тега

Чтобы переименовать существующий тег:

Перестать отслеживать существующие файлы

Если вы хотите перестать отслеживать файлы, которые уже есть в репозитории, но при этом желаете сохранить его локально, осуществите коммит изменений и запустите команду:

Она удалит изменённые файлы из зоны подготовленных файлов (staging area). Затем нужно запустить команду:

и отправить изменения.

Подготовка удалённых файлов

Чтобы подготовить к коммиту файлы и папки, которые были удалены локально, можно использовать специальную команду:

Если требуется подготовить только используемый в данный момент путь, воспользуйтесь командой

Поиск конкретного сообщения во всех коммитах

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

Пометить конфликтующий файл, как разрешённый

Чтобы пометить один или несколько конфликтующих файлов, как разрешённые, чтобы их можно было нормально изменять, воспользуйтесь командой:

Затем можно запустить git commit, чтобы разрешить конфликты и опубликовать изменения.

Просмотр всех неотправленных коммитов

Чтобы просмотреть все коммиты, которые ещё не были отправлены в соответствующие ветки, воспользуйтесь следующей командой:

Кроме того, можно использовать:

Просмотр старой ревизии файла

Существует возможность просмотреть содержимое файла в конкретный момент времени в прошлом. Для этого нужно использовать команду:

Публикация локальной ветки для удалённого редактирования

Если вы создали локальную ветку, и хотите, чтобы другие пользователи могли с ней работать, воспользуйтесь командой:

Теперь они тоже смогут вносить изменения в эту ветку.

Сброс локальной ветки до состояния удалённой

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

Прежде всего нужно получить свежие обновления из удалённой ветки:

А затем нужно сообщить git, что локальную ветку следует «откатить» до состояния удалённой:

Синхронизировать ветку с master-репозиторием

Чтобы синхронизировать последние изменения в репозитории master (или с любой другой веткой, с которой вы работали) необходимо «перебазировать» локальную ветку. Предположим, вы работаете над веткой foobar:

А затем осуществляете «перебазирование»:

После этого будут применены коммиты origin из master. После разрешения конфликтов процесс можно продолжить с помощью команды git rebase —continue. Теперь можно продолжать работу над своей веткой или осуществить её слияние (merge) с главным репозиторием.

Слияние локальных изменений с другой веткой

Это можно сделать прямо в процессе стандартного слияния (merge). Вам стоит сохранить историю слияний используя флаг —no-ff, что означает no fast forward.

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

Затем появится сообщение о коммите merge X into Y branch, после чего вы можете смело запушить ваше слияние.>

Совмещение двух и более коммитов

Если есть необходимость в совмещении двух последних коммитов, можно использовать команду

После её ввода появятся инструкции по выбору коммитов. В том случае, если необходимо совместить все коммиты с первым старейшим коммитов, то в первой строке нужно написать pick, а для всех остальных коммитов изменить букву на f. Подробнее здесь

Совмещение коммитов по конкретной функции для добавления в ветку релиза

Если вы решите совместить и опубликовать коммиты, то возникнет новый коммит в ветке релиза, поэтому история ветки конкретной функции останется неизменной.

Ниже представлен пример того, как достичь подобного эффекта:

В конечном итоге останется только один коммит в ветке релиза, а история изменений в ветке разработки конкретной функции останется нетронутой.

Создание новой ветки с изменениями текущей

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

Эта команда перенесёт файлы из текущей ветки в новую, которую потом уже можно «закоммитить».

Убрать файл из буфера

Чтобы убрать добавленный по ошибке файл из буфера, нужно воспользоваться простой командой:

Удаление внешней ветки

Если вы хотите удалить ветку, введите команду:

Удаление неотслеживаемых файлов и папок

Чтобы удалить неотслеживаемые файлы и папки из рабочей копии наберите следующую команду:

Чтобы в принципе удалить их:

Подсказка: чтобы увидеть, какие файлы являются лишними, перед их непосредственным удалением, наберите:

Удаление старых веток, стёртых из внешнего репозитория

Если ветка удалена из внешнего репозитория, её также можно стереть из локального репозитория с помощью команды

Она удалит старую ветку под названием название-удалённой-ветки, которая уже была стёрта из внешнего репозитория, но всё ещё доступна локально в remotes/название-удалённой-ветки.

Удаление файла из git с сохранением его локальной копии

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

Без Гита и жизнь не та

Получите практику в Git на курсах HTML Academy. Мы расскажем всё, что знаем сами, чтобы вы прокачали навыки в веб-разработке.

Как удалить файл из репозитория github

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

GitHub Desktop

Дистрибутивы Git для систем Linux и POSIX доступны на официальном сайте Git SCM.

Git для всех платформ

Первоначальная настройка

Настройка информации о пользователе для всех локальных репозиториев

Устанавливает имя, которое будет отображаться в поле автора у выполняемых вами коммитов

Устанавливает адрес электронной почты, который будет отображаться в информации о выполняемых вами коммитах

Создание репозитория

Создание нового репозитория или получение его по существующему URL-адресу

$ git init [название проекта]

Создаёт новый локальный репозиторий с заданным именем

$ git clone [url-адрес]

Скачивает репозиторий вместе со всей его историей изменений

Внесение изменений

Просмотр изменений и создание коммитов (фиксация изменений)

Перечисляет все новые или изменённые файлы, которые нуждаются в фиксации

Показывает различия по внесённым изменениям в ещё не проиндексированных файлах

Индексирует указанный файл для последующего коммита

Показывает различия между проиндексированной и последней зафиксированной версиями файлов

Отменяет индексацию указанного файла, при этом сохраняет его содержимое

Фиксирует проиндексированные изменения и сохраняет их в историю версий

Коллективная работа

Именованные серии коммитов и соединение результатов работы

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

$ git branch [имя ветки]

Создаёт новую ветку

Переключается на выбранную ветку и обновляет рабочую директорию до её состояния

$ git merge [имя ветки]

Вносит изменения указанной ветки в текущую ветку

Удаляет выбранную ветку

Операции с файлами

Перемещение и удаление версий файлов репозитория

Удаляет конкретный файл из рабочей директории и индексирует его удаление

Убирает конкретный файл из контроля версий, но физически оставляет его на своём месте

$ git mv [оригинальный файл] [новое имя]

Перемещает и переименовывает указанный файл, сразу индексируя его для последующего коммита

Игнорирование некоторых файлов

Исключение временных и вторичных файлов и директорий

Список всех игнорируемых файлов в текущем проекте

Сохранение фрагментов

Сохранение и восстановление незавершённых изменений

Временно сохраняет все незафиксированные изменения отслеживаемых файлов

Восстанавливает состояние ранее сохранённых версий файлов

Выводит список всех временных сохранений

Сбрасывает последние временно сохранённыe изменения

Просмотр истории

Просмотр и изучение истории изменений файлов проекта

История коммитов для текущей ветки

История изменений конкретного файла, включая его переименование

$ git diff [первая ветка]. [вторая ветка]

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

Выводит информацию и показывает изменения в выбранном коммите

Откат коммитов

Удаление ошибок и корректировка созданной истории

Отменяет все коммиты после заданного, оставляя все изменения в рабочей директории

Сбрасывает всю историю вместе с состоянием рабочей директории до указанного коммита.

Синхронизация с удалённым репозиторием

Регистрация удалённого репозитория и обмен изменениями

$ git fetch [удалённый репозиторий]

Скачивает всю историю из удалённого репозитория

$ git merge [удалённый репозиторий]/[ветка]

Вносит изменения из ветки удалённого репозитория в текущую ветку локального репозитория

$ git push [удалённый репозиторий] [ветка]

Загружает все изменения локальной ветки в удалённый репозиторий

Загружает историю из удалённого репозитория и объединяет её с локальной. pull = fetch + merge

Запись изменений в репозиторий

Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.

Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.

Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.

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

Определение состояния файлов

Отслеживание новых файлов

Индексация изменённых файлов

Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :

Сокращенный вывод статуса

Игнорирование файлов

Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (

Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.

Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.

Чтобы исключить каталог добавьте слеш (/) в конец шаблона.

Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.

Просмотр индексированных и неиндексированных изменений

Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:

Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.

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

Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:

Используйте git diff для просмотра непроиндексированных изменений

Коммит изменений

Эта команда откроет выбранный вами текстовый редактор.

В редакторе будет отображён следующий текст (это пример окна Vim):

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

Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.

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

Игнорирование индексации

Удаление файлов

Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :

В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:

Эта команда удаляет все файлы, имена которых заканчиваются на

Перемещение файлов

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

Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:

и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:

Однако, это эквивалентно выполнению следующих команд:

1234ru / git.md

Отменять коммиты можно, только если они не опубликованы в общий репозиторий (не было git push).

Поиск когда-то удаленного файла

или, если не известен путь:

Длинный текст в commit-сообщении

Первую строку нужно отделять от остального текста двойным переводом строки. Тогда в короткий формат git log войдет только она. В противном случае туда попадет сообщение полностью, что снизит удобочитаемость списка.

Другие полезные команды

Слияние веток без истории изменений (в один коммит)

Полезно, когда при разработке было сделано много промежуточных коммитов, которые по отдельности интереса не представляют, и все изменения просто нужно перенести в основную ветку в виде единственного коммита, чтобы не засорять историю изменений. При этом dev-ветка должна быть впереди master!

Получение изменений из master-ветки без переключения на неё

Это намного удобней, чем давать последовательность команд

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

Получить суммарные изменения между двумя коммитами:

Получить изменения по дате:

Вывести список файлов, в которых есть конфликты слияния:

Есть три уровня действия настроек: системный, текущего пользователя и конкретного репозитория (подробнее см. здесь).

которая соответствует команде

Работа с подмодулями

Клонирование репозитория с подмодулями

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

Подмодули также нужно инициализировать в upstream-репозитории, если туда была отправлена локальная ветка ( git push origin ветка ):

Выделение части кода проекта в подмодуль

Работа над подмодулем должна быть локализована в каком-то подкаталоге. Перед тем, как инициализировать подмодуль в проекте, его нужно опубликовать на github или каком-то другом хранилище, после чего выполнить команду

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

После того, как подмодуль таким образом зарегистрирован, нужно сделать коммит в основной проект и отправить его в вышестоящий репозиторий. После этого там появится каталог подмодуля, но он будет пуст (весьма странно, что git так работает, потому что при такой схеме можно отправить в вышестоящий репозиторий проект в нерабочем состоянии). Подмодуль нужно вручную инициализировать. Для этого в каталоге проекта в вышестоящем репозитории нужно дать команду

Команда вида git submodule init (локальный каталог) не сработает, т.к. она ожидает пути к централизованному хранилищу, откуда потом можно будет забирать изменения.
Можно, однако, сначала перейти в каталог подмодуля, а потом последовательно выполнить команды git submodule init и git submodule update без указания каталога, как это сделано в примере из документации.

Трудности с обновлением подмодулей при работе по схеме push-to-deploy

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

Немного о работе с github.com

Соединение с помощью SSH-ключа

Чтобы это сработало, нужно добавить свой публичный SSH-ключ через настройки учетной записи. Подробная инструкция здесь.

Поменять URL репозитория можно так:

При этом / с конца URL нужно обязательно убрать, иначе git push завершится ошибкой «Repository not found».

или, в общем случае

Такая процедура связана с тем, что в пустом репозитории на сервере github веток ещё нет. Подробнее см. https://stackoverflow.com/q/17096311/

Делать это можно только при наличии коммитов в локальной ветке. При пустой ветке команда не сработает.

Обслуживание репозитория и восстановление данных

Изредка вам потребуется делать «уборку» — сделать репозиторий более компактным, очистить импортированный репозиторий от лишних файлов или восстановить потерянные данные. Данный раздел охватывает некоторые из этих сценариев.

Обслуживание репозитория

Время от времени Git выполняет автоматическую сборку мусора. Чаще всего эта команда ничего не делает. Однако, если у вас накопилось слишком много «рыхлых» объектов (не в pack-файлах), или, наоборот, отдельных pack-файлов, Git запускает полноценный сборщик — git gc (здесь «gc» это сокращение от «garbage collect», что означает «сборка мусора»). Эта команда выполняет несколько действий: собирает все «рыхлые» объекты и упаковывает их в pack-файлы; объединяет несколько упакованных файлов в один большой; удаляет недостижимые объекты, хранящиеся дольше нескольких месяцев.

Сборку мусора можно запустить вручную следующим образом:

Ещё одно действие, выполняемое gc — упаковка ссылок в единый файл. Предположим, репозиторий содержит следующие ветки и теги:

Восстановление данных

Ниже приведён пример, в котором мы сбрасываем ветку master с потерей данных до более раннего состояния, а затем восстанавливаем потерянные коммиты. Для начала, давайте посмотрим, как сейчас выглядит история изменений:

Теперь сбросим ветку master на третий коммит:

Итак, теперь два последних коммита по-настоящему потеряны — они не достижимы ни из одной ветки. Необходимо найти SHA-1 хеш последнего коммита и создать ветку, указывающую на него. Сложность в том, чтобы узнать этот самый SHA-1, ведь вряд ли вы его запомнили, да?

В нашем случае потерянный коммит указан после слов «dangling commit» («висячий коммит»). Его можно восстановить аналогичным образом, создав новую ветку, указывающую на этот SHA-1.

Удаление объектов

Git — замечательный инструмент с кучей классных возможностей, но некоторые из них способны стать источником проблем; например, команда git clone загружает проект вместе со всей историей, включая все версии всех файлов. Это нормально, если в репозитории хранится только исходный код, так как Git хорошо оптимизирован под такой тип данных и может эффективно сжимать их. Однако, если когда-либо в проект был добавлен большой файл, каждый, кто потом захочет клонировать проект, будет вынужден скачивать этот файл, даже если он был удалён в следующем коммите. Он будет в базе всегда, просто потому, что он доступен в истории.

Это может стать большой проблемой при конвертации Subversion или Perforce репозиториев в Git. В этих системах вам не нужно загружать всю историю, поэтому добавление больших файлов не имеет там особых последствий. Если при импорте из другой системы или при каких-либо других обстоятельствах стало ясно, что ваш репозиторий намного больше, чем он должен быть, то как раз сейчас мы расскажем, как можно найти и удалить большие объекты.

Предупреждаем: дальнейшие действия переписывают историю изменений. Каждый коммит, начиная с самого раннего, из которого нужно удалить большой файл, будет переписан. Если сделать это непосредственно после импорта, пока никто ещё не работал с репозиторием, то всё окей, иначе придётся сообщить всем участникам о необходимости перебазирования их правок относительно ваших новых коммитов.

Для примера добавим большой файл в тестовый репозиторий, удалим его в следующем коммите, а потом найдём и удалим его полностью из базы. Сначала добавим большой файл в нашу историю:

Упс, мы нечаянно. Нам лучше избавиться от этого файла:

Шпаргалка по основам Git/GitHub

Руководство по контролю версий для начинающих

Git и GitHub

Введение

Git достаточно мудрёный и выучить каждую из его команд не так-то просто, но для начала работы Вам нужно знать всего несколько ключевых понятий. Чем больше Вы будете использовать Git, тем чаще Вы будете сталкиваться с ситуацией, когда начальных знаний окажется недостаточно, но существует большое количество ресурсов, которые придут к Вам на помощь. Так что используйте это руководство как трамплин, не забывая о дальнейшем развитии.

Первым делом мы загрузим Git. Для пользователей Windows я советую установить и Git Bash, который доступен после установки Git. Для пользователей Mac, использование Terminal будет достаточным. После завершения установки приступайте к регистрации аккаунта GitHub. Итак, у Вас есть Git, инструмент командной строки, и GitHub аккаунт, куда Вы будете загружать свои репозитории.

Шпаргалка

Используя Git Bash или Terminal перейдите в корневую директорию проекта. Если Вы используете Git Bash, то с помощью правого клика можно выбрать “Git Bash Here” и он запустится в рабочей директории.

git add имяФайла.расширение
Замените “ имяФайла.расширение” на любой файл, изменения которого Вы пытаетесь зафиксировать, например “index.html”. Эта команда добавит файл в “staging area” (участок подготовки). Воспринимайте staging area, как секцию в которой файлы проходят подготовку к перемещению в Ваш репозиторий.

git status
Покажет что уже было добавлено в staging area и какие файлы были изменены и ждут перемещения в staging area.

git reset имяФайла.расширение
Убирает выбранный файл из staging area.

git checkout “названиеВетки”
Позволит Вам переключить контроль над созданной Вами веткой и работать в её пределах. Здесь Вы можете совершать любые изменения кода. Когда Вы будете готовы можно совершить commit изменений и отправить изменения в GitHub (об этом ниже) или же можно удалить ветвь, если что-то пошло не так или Вам больше не нужны изменения сделанные в этой ветке.

git merge названиеВетки
Находясь в Master(главной) ветви, Вы можете использовать эту команду, чтобы взять коммиты из любой из ветвей и соединить их вместе.

git remote add origin https://github.com/имяПользователя/проект.git
Эта команда определит “местоположение” Вашего удалённого репозитория. Всё что было до этого происходило исключительно в локальном репозитории на Вашем компьютере. Вам нужно будет перейти в GitHub аккаунт и создать новый удалённый репозиторий, куда Вы сможете отправлять изменения из локального репозитория. After you created your remote repository you will be provided with a link and that link is the location you will want to use in the above command.

git remote
Выведет список из всех удалённых репозиториев, которые были добавлены к Вашему проекту.

git push
This is what you will use to push your code to GitHub after your initial push.

git clone https://github.com/имяПользователя/проект.git
Если у Вас отсутствует проект на личном или рабочем компьютере, то эта команда поможет клонировать/загрузить весь проект в текущую директорию.

git pull
Если Вы работаете над одним и тем же проектом с несколькими людьми, то эта команда позволит загрузить последнюю версию из удалённого репозитория и обновить вашу локальную версию.

Вывод

Надеюсь это руководство поможет Вам начать и понимать что вообще происходит. Буду рад помочь с уточнениями и ответами на вопросы в комментариях.