Pycharm убрать файл из git

Обновлено: 05.07.2024

Все мы знаем о преимуществах использования систем контроля версий как при самостоятельной разработке, так и при работе в команде. Сегодня я хотел бы рассказать о поддержке в PyCharm самой популярной системы контроля версий Git и ее GUI.

Теперь запускаем PyCharm и открываем какой-либо свой проект. С помощью команд главного меню VCS -> Enable Version Control Integration… -> [в выпадающем списке] Git подключаем контроль версий.

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

Также, нужно добавить конкретные файлы/директории, для которых Git будет отслеживать изменения. Изначально, после подключения контроля версий к проекту, все файлы выделятся красным цветом. Выделив необходимые из них и вызвав контекстное меню, кликаем Git -> Add. Файлы выделятся зеленым цветом – значит будут отслеживаться системой контроля версий.

Затем нужно будет сделать первый commit (Git -> Commit Files…), чтобы сохранить текущее состояние, к которому можно будет впоследствии откатиться с помощью rollback, если что-то пойдет не так.

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

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

В любой момент времени, есть возможность посмотреть всю хронологию произведенных над файлом изменений с помощью (Git -> Show History). Удобно видеть кто, когда и что именно добавил в проект.

При необходимости, всегда можно посмотреть изменения более детально (Git -> Show Diff).

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

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

Давайте рассмотрим, как запушить свой проект, например, на github (Git -> GitHub -> Share Project on GitHub). При использовании этой функции впервые, IDE попросит авторизоваться на GitHub.

Теперь, в правом нижнем углу мы можем видеть и управлять локальным и удаленным репозиториями и всеми их ветками.

Пушить commit-ы в удаленный репозиторий можно с помощью Git -> Push, либо при создании commit-а выбрать не commit, как раньше, а commit and push…, тогда создастся локальный commit и запушится в удаленный репозиторий.

Обновлять проект с учетом изменений в удаленном репозитории можно с помощью Git -> Update Project.

Мы рассмотрели основные операции, связанные с контролем версий, которыми пользуются разработчики, Data Scientist-ы, аналитики, инженеры и все, кто работает над проектами несколько более сложными чем “Hello World!”. Хотелось бы обратить внимание на то, что нам ни разу не пришлось прибегать к CLI и терминалу. Все базовые задачи нам удалось решить с помощью графического интерфейса IDE. В данной статье я попытался показать преимущества использования GUI, но, несомненно, работа через терминал имеет также свои плюсы и каждый волен выбирать то, что ближе ему.



Удаление файлов с конфиденциальной информацией из Git-репозитория ( изображение большого размера )

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

Итак, вы случайно закоммитили файл с конфиденциальной информацией. Назовём этот файл .env . Сразу после того, как это случилось, надо задать себе пару вопросов:

  • Отправлен ли коммит в удалённый репозиторий?
  • Является ли удалённый репозиторий общедоступным?

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


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

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


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

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

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

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

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

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


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

  • Вы меняете историю Git. Если на текущее состояние репозитория полагаются другие люди, если от этого состояния зависят какие-то ветки того же репозитория, его форки, открытые PR, то это нарушит их работу. В подобных случаях относитесь к репозиторию как к общедоступному и постарайтесь не вносить изменения в его историю.
  • Вам нужно будет очистить кеш. Вам понадобится обратиться в службу поддержки платформы, на которой хранится ваш репозиторий, и попросить очистить его кеш. Несмотря на то, что вы исправили проблемный коммит или переписали историю репозитория, старый коммит, содержащий конфиденциальные данные, останется в кеше. Для того чтобы к нему обратиться, нужно будет знать его ID, но к нему можно будет получить доступ до тех пор, пока кеш не очистят.

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

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

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

  • Деактивируйте все ключи или пароли. Это надо сделать в первую очередь. После того, как вы деактивируете ключи, конфиденциальные сведения, ушедшие в общий доступ, оказываются бесполезными.
  • Настройте файл .gitignore . Сделайте в .gitignore записи о файлах с конфиденциальной информацией для того чтобы Git не отслеживал бы состояние этих файлов.
  • Подготовьте коммит, в котором нет файлов с конфиденциальной информацией.
  • Отправьте изменения в репозиторий, снабдите коммит пояснениями о возникшей ситуации. Не пытайтесь скрыть ошибку. Все программисты, работающие над проектом, включая вас, по достоинству оценят наличие в репозитории коммита с разъяснениями ситуации и с описанием того, что именно было исправлено с помощью данного коммита.

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

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

▍Храните секретные данные в файле .env (или в другом подобном файле)

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

Ещё одно преимущество такого подхода заключается в том, что так у вас будет доступ ко всем ключам через глобальную переменную process .

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

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

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

Ключи API обычно нужны при сборке приложений. Инструменты для сборки проектов, вроде Netlify, позволяют держать ключи в защищённых хранилищах. Такие ключи автоматически внедряются в приложение с использованием глобальной переменной process .


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

▍Добавьте запись о файле .env в файл .gitignore

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

▍Подготовьте шаблонный файл .env.template

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

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

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

Итоги

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

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

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

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

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

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

Результатом выполнения данных команд будет удаление файла из репозитория для коммита, который вы выполните на этом этапе и всех последующих коммитов. Это замечание важно тем, что для предыдущих коммитов этот файл будет находиться в репозитории. Аналогом этих двух команд является команда git rm file.txt . При этом в индекс сразу будет добавлена информация о том, что файл удален и не нужно будет выполнять команду git add .

Также вы можете не выполнять команду git add <pathspec> , а зафиксировать удаление файла непосредственно при выполнении коммита (git commit -a). Но я не советую вам использовать такой вариант (если вы действительно не хотите сделать именно это).

Если команде git rm в pathspec было указано название директории, то вам понадобится указать флаг -r для того, чтобы git рекурсивно удалил файлы, находящиеся в указанной директории.

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

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

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

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

Что касается перемещения файлов - то возможны 3 самых частых случая:

  • Файл был перемещен в другую директорию
  • Файл был переименован
  • Любое из предыдущих действий + при этом файл был отредактирован.

А теперь, давайте абстрагируемся от того, как бы git мог это обработать и опишем эти действия при помощи команд:

Перемещаем файл в новую директорию mv file.txt new_dir/ Теперь git видит, что у него один файл удален ( file.txt ) и один не отслеживается ( new_dir/file.txt ) Зафиксируем удаление файла file.txt git add file.txt Зафиксируем добавление файла new_dir/file.txt под версионный контроль git add new_dir/file.txt

То есть, мы выполнили 3 действия, для того, чтобы зафиксировать перемещение файла в другую директорию (в случае с переименованием файла будет то же самое). git предоставляет 1 команду взамен этим 3-м git mv file.txt new_dir/txt

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

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

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

Принято считать, что файл в репозитории, находящемся под версионным контролем SCV GIT, может находится в одном из 4 состояний:

  • Неотслеживаемый Untracked
  • Отслеживаемый неизмененный Tracked unmodified
  • Отслеживаемый с изменениями Tracked modified
  • Отслеживаемый подготовленный для фиксации в коммит Tracked staged

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

Делается это очень просто при помощи команды:

Рассмотрим все вышесказанное на наглядном примере. У нас есть каталог с тремя измененными файлами, если выполним команду [cci]$ git status[/cci], то узнаем состояние репозитория.


Состояние репозитория. Имеются изменения в 3 файлах.

Допустим, что в следующий коммит мы решили добавить все 3 файла с расширением php, и вначале мы добавляем файлы для фиксации в коммит, командой:

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


Файлы в состоянии staged.

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


Результат работы команды git reset HEAD.

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


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


В качестве резюме отметим, что если файл по ошибке переведен в статус staged, в системе контроля версий GIT очень удобно и быстро перевести в его в предыдущий статус при помощи команды git reset HEAD.

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