Bitbucket как удалить файл из репозитория
Я добавил файл с именем "file1.txt" в репозиторий Git. После этого я зафиксировал его, добавил пару каталогов с именем dir1 and dir2 и отправил их в репозиторий Git.
Теперь текущее хранилище имеет "file1.txt" , dir1 и dir2 . Как я могу удалить, "file1.txt" не влияя на других, как dir1 и dir2 ?
git rm это правильный ответ, но помните, что файл все еще будет там в истории. Если вы хотите удалить файл, потому что он содержал конфиденциальную информацию, вам нужно сделать что-то более радикальное. (Изменение истории, особенно для контента, который вы уже добавили, является радикальным действием, и его следует избегать, если это возможно.) Примечание: в GitHub вы теперь можете напрямую удалить файл из веб-интерфейса (даже не клонируя репо). Смотрите мой ответ ниже . @KeithThompson, что это может быть, если я отчаянно хочу это сделать?Если вы хотите удалить файл из репозитория Git и файловой системы , используйте:
Но если вы хотите удалить файл только из репозитория Git и не удалять его из файловой системы, используйте:
И подтолкнуть изменения к удаленному репо
Также удобно: git rm -r directory // Удалить каталог и контент Это не собирается избавляться от этого файла в других коммитах. Обратите внимание, что файл будет удален и локально. Если вы хотите удалить его только из репозитория, выполните: git rm --cached file1.txt Стоит отметить, что если этот файл содержит конфиденциальную информацию (например, учетные данные), вы должны немедленно изменить эти учетные данные . Процитируем GitHub: «После того, как вы отправили коммит в GitHub, вы должны рассматривать любые содержащиеся в нем данные как скомпрометированные. Если вы зафиксировали пароль, измените его! Если вы зафиксировали ключ, сгенерируйте новый».git rm file.txt удаляет файл из репозитория, но также удаляет его из локальной файловой системы .
Чтобы удалить файл из репозитория и не удалять его из локальной файловой системы, используйте:
git rm --cached file.txt
Ниже приведена точная ситуация, когда я использую git для поддержки контроля версий для веб-сайта моего бизнеса, но каталог «mickey» был папкой tmp для обмена частным контентом с разработчиком САПР. Когда он нуждался в ОГРОМНЫХ файлах, я создал личный, несвязанный каталог и установил там ftpd файлы для его загрузки через браузер. Забыв, что я сделал это, я позже выполнил git add -A из базовой директории сайта. Впоследствии git status показали новые файлы, требующие фиксации. Теперь мне нужно было удалить их из отслеживания git и контроля версий .
Ниже приведен пример того, что случилось со мной, когда я случайно удалил .003 файл. К счастью, мне все равно, что случилось с локальной копией .003 , но некоторые другие в настоящее время измененные файлы были обновлениями, которые я только что сделал на веб-сайте, и они были бы грандиозными, если их удалить в локальной файловой системе! «Локальная файловая система» = живой сайт (не очень хорошая практика, но реальность) .
Обновление: Этот ответ получает некоторый трафик, поэтому я подумал, что упомяну другой мой ответ Git, делится парой отличных ресурсов: На этой странице есть рисунок, который помогает демистифицировать Git для меня. Книга "Pro Git" онлайн и мне очень помогает.
Затем вам нужно будет зафиксировать это с помощью чего-то подобного, git commit -m "Just removing file1.txt" а затем, если у вас есть удаленный репозиторий, протолкнуть коммит с чем-то вроде git push origin master .Во-первых, если вы используете git rm , особенно для нескольких файлов, учтите, что любой подстановочный знак будет разрешен оболочкой, а не git командой.
Но, если ваш файл уже находится на GitHub, вы можете (с июля 2013 года) напрямую удалить его из веб-интерфейса!
Просто просмотрите любой файл в вашем хранилище, щелкните значок корзины в верхней части и подтвердите удаление, как и любое другое редактирование через Интернет.
Затем " git pull " в вашем локальном репо, и это также приведет к удалению файла локально.
Что делает этот ответ (окольным) способом удаления файла из git repo?
(Не говоря уже о том, что файл на GitHub находится в «git repo»)
(фиксация будет отражать удаление этого файла):
И просто так, это ушло.
Для получения справки об этих функциях обязательно прочитайте наши справочные статьи по созданию , перемещению , переименованию и удалению файлов.
Примечание. Так как это система контроля версий, Git всегда имеет вашу спину, если вам нужно восстановить файл позже.
Последнее предложение означает, что удаленный файл все еще является частью истории, и вы можете восстановить его достаточно легко (но пока не через веб-интерфейс GitHub):
Git очень удобная система контроля версий, которая сейчас используется практические повсеместно. Она нужна для того, чтобы команды могли кооперироваться в создании программного продукта и совмещать код написанный разными людьми в одном репозитории.
Когда я учил Git мне говорили, что в работе мне понадобятся всего 3 команды:
Правда, по сути мне немного слукавили, нужен был ещё как минимум:
Однако, на этом все мои теоретические знания по Git заканчивались и достаточно долгое время я пользовался только этими командами, покуда в один момент не начал работать над веб-приложениями, над которыми со мной работали ещё несколько человек.
Там мне объяснили какие команды также нужны в разработке, зачем они используются и как часто они используются. Сегодня я решил поделиться этими командами с вами.
Основная терминология
отслеживаемые файлы - когда файл добавляется в отслеживание Git'а создается специальный кэш, благодаря которому можно будет откатываться к предыдущим версиям файла
неотслеживаемые файлы - когда файл не добавляется в отслеживание Git'а его кэш не хранится в Git'е, а значит откат на предыдущие версии не работает для таких файлов
коммит - специальное название сохранения версии. Таким образом мы называем все изменения в файлах одним именем и сможем перемещаться между коммитами
откат - переход на предыдущий коммит и отмена изменений с текущего коммита до того, на который мы хотим вернуться
пуш - отправка изменений на удаленный репозиторий (в Github, Gitlab, BitBucket)
фетч - скачивание изменений из репозитория
ветка - ветки создают, когда нужно несколько активных вариантов разработки. В основном их используют для того, чтобы быстро разработать некоторый функционал, а потом слить ветки в одну
мердж - слитие веток в одну
Работа с Git
Прежде всего нам понадобятся команды для работы с файлами. Знать add конечно хорошо, но нужно иногда и удалять что-то из кэшируемых файлов или изменять поведение Git для определенных файлов. Сегодня я разберу некоторые команды, которые позволят вам манипулировать с файлами, ветками, коммитами в Git.
init
Данная команда инициализирует систему контроля версий. Для того чтобы создать новый репозиторий достаточно просто ввести:
clone
Данная команда нужна для того, чтобы клонировать репозиторий из облака. Можно клонировать репозитории из Github, Gitlab, BitBucket и других сервисов. Для того чтобы склонировать репозиторий нужно ввести:
add
Данная команда понадобится вам, когда вам нужно добавить файл для кэширования. Давайте разберёмся как это работает:
Вы изменяете файлы, можете изменять достаточно много файлов, задачи изменения которых вообще никак не связаны
Вы решаете "закоммитить" ваши файлы (сделать сохранение версии, для того чтобы Git запомнил все ваши изменения в файлах и как-то назвал их, для этого есть отдельная команда git commit )
Вы также можете добавить файлы, которые ранее не отслеживались, для того чтобы Git занёс их в свою систему хранения версий и вы могли откатываться на какую-то из версий файла
Обычно с самого начала все разработчики делают коммит (сохранение версии) с названием init , занося все файлы в систему отслеживания. Делается это с помощью простой последовательности команд:
Проделав данный алгоритм, состоящий из двух команд вы занесёте все файлы из вашего проекта в систему контроля версий Git.
Но, что если вам не хочется вносить все файлы? Тогда вы может использовать следующий синтаксис:
Так, хорошо, но что если нам нужно занести весь проект в систему отслеживания, однако есть пару директорий, которые мы не хотим заносить (например, node_modules или out )? Для этого мы можем создать файл .gitignore , в котором будут прописаны пути до файлов и директорий, которые Git должен игнорировать:
В данном случае Git будет игнорировать директорию node_modules , out и файл one_file.tsx
Также мы можем сделать так, чтобы Git искал некоторые названия в дочерних директориях и игнорировал их:
Данный пример говорит о том, что Git будет игнорировать директорию node_modules , которая будет находится в любой дочерней директории (включая корневую).
Больше о .gitignore можно прочитать здесь
А что если я хочу обновить уже закэшированные файлы, мне что теперь их писать по одному? Конечно же нет. Для этого существует специальный флаг -u (сокращение от --update ), который позволяет закэшировать только те файлы, которые уже отслеживаются:
rm
Данная команда поможет, когда нам нужно избавиться от файла, она подобно команде rm удаляет файл из файловой системы и кэша Git, позволяя нам быстро избавиться от файла.
Данный пример удалит файл file.txt из кэша и файловой системы.
Но, что если мы добавили файл, который нам более не нужен в кэше, но нужен в файловой системе? Тогда мы можем воспользоваться следующей командой:
Данная команда удалит файл из "кэша", но что это значит? Допустим, что мы "закоммитили" (сохранили версию, об этом поговорим вот уже совсем скоро) наш файл, а теперь хотим, чтобы Git считал что мы его удалили, а сами просто оставили его на диске. Для этого и нужна команда выше. Она просто говорит Git: "Слушай, а давай ты просто удалишь этот файл из кэша и не будешь его показывать в репозитории, а я оставлю копию у себя на ПК, ок?"
Таким образом мы можем работать с данным файлом и Git не будет знать что именно в нём мы изменяем, а затем просто можем опять добавить его. Файл будет висеть в состоянии "untracked" (не отслеживается) до тех пор, покуда мы его опять не добавим.
commit
Думаю, что стоит поговорить об этом уже сейчас, ибо позже без данной команды уже никуда. Данная команда буквально сохраняет версию, в которой указывается что именно в файлах мы изменили.
Обычно разработчики сохраняют версию программы с помощью данной команды:
В данном случае мы просто скажем, чтобы Git сохранил все изменения, которые мы сделали в файлах, которые отслеживаются. Файлы, которые не отслеживаются просто не попадают в версию, а также их изменения никак нельзя отследить.
Для того чтобы отменить последний коммит (отменить не изменения, а именно просто разкоммитить изменения) и совместить его с текущими изменениями используйте команду:
show
Данная команда нужна для того, чтобы быстро показать что было сделано за предыдущие коммит:
Выведутся изменения следующим образом:
status
Если до этого момента вы не знали как проверить какой файл кэшируется, какой не отслеживается, а какие файлы и вовсе только что были удалены из кэша, то спешу вас обрадовать, у вас теперь есть команда git status , которая даёт возможность посмотреть что именно происходит с вашими файлами:
Если вы хотите узнать более подробно о том, что же именно случилось с вашими файлами, то можете добавить ключ -v (сокращение от --verbose - внимательно):
Если же вам наоборот хочется увидеть бриф по информации, то добавьте флаг -s (сокращение от --short ):
log
До этого момента мы могли только посмотреть что творилось в предыдущем коммите, однако с помощью git log мы можем посмотреть историю наших коммитов:
Если же вы хотите красиво вывести все ваши коммиты в столбик, то используйте данную команду:
В данной команде мы описываем что хотим просматривать коммиты и их названия в одну строку, хотим чтобы коммиты сокращали свой ID, а также чтобы всё это красиво было разбито по списку
diff
С помощью данной команды мы можем посмотреть на изменения между коммитами. Эта комманда является одной из самых мощных в Git, вам стоит обратить на неё внимание:
Так называемые "ID-коммита" можно взять и вышеприведенной git log
Также, можно посмотреть что было изменено с момента последнего коммита (что изменено и попало в кэш) с помощью флага --cached :
Если вы хотите посмотреть историю изменений в файлах в определенном коммите, то используйте следующую команду:
Если вы хотите посмотреть на статистику, то вы всегда можете использовать флаг --stat :
Если вы хотите посмотреть на изменения только тех файлов, которые добавлены для отслеживания, то нужно ввести следующую команду:
branch
В Git есть ветки для разделения версий. Если коммит нужен для того, чтобы сделать snapshot (слепок изменений) файлов, то ветки нужны для того, чтобы эти snapshot'ы разделять. У вас может быть ветка
любое другое название
Для того чтобы перечислить все ветки с помощью Git нужно ввести следующую команду:
Для того чтобы создать новую ветку нужно ввести:
checkout
Checkout используют для того, чтобы переходить между ветками. Для того чтобы перейти на другую ветку достаточно просто написать:
Для того чтобы создать ветку и сразу же перейти на неё достаточно ввести:
merge
Соединение веток не являются сложной темой. Для того чтобы слить текущую ветку с другой нужно ввести:
push
Для того чтобы закинуть изменения на сервер нужна комнда push , которая позволит нам закинуть текущую ветку на удаленный репозиторий:
В завершение
Здесь мы чуть более глубже познакомились с основами Git, поняли как работать с ветками, как их мерджить, как коммитить файлы, смотреть изменения, а также как показывать последние коммиты.
Если вы хотите больше узнать о веб-разработке, а также о линуксе, то милости прошу в мой блог на телеграм.
Надеюсь данная статья помогла вам чуть лучше узнать Git. Хорошего дня и продуктивной недели!
Узнайте, как отменить изменения на локальной машине и в репозитории Bitbucket Cloud во время совместной работы с коллегами.
Краткое описание основной задачи
В этом обучающем руководстве рассматриваются команды git revert , git reset , git log и git status
В этом обучающем руководстве предполагается, что вы знакомы со следующими командами Git :
Ошибиться может каждый. Не все изменения, отправляемые с помощью команды push, идеальны, поэтому в этом учебном руководстве рассматриваются наиболее распространенные команды Git для безопасной отмены изменений.
В этом обучающем руководстве предполагается, что вы знакомы со следующими командами Git:
Если вы не знакомы с этими командами, мы поможем изучить Git с помощью Bitbucket Cloud. Далее вернитесь на эту страницу и узнайте, как отменять изменения. Эти команды Git подходят для сред Windows и Unix. При навигации по файловой системе в этом руководстве будут использоваться утилиты командной строки Unix.
Отмена изменений на локальной машине
Если изменение, которое вы хотите отменить, находится в вашей локальной системе и оно не было опубликовано в удаленном репозитории, выполнить отмену можно двумя способами:
Команда отмены, однако принцип ее действия отличается от привычной отмены изменений. Вместо удаления коммита эта команда отменяет внесенные в нем изменения и добавляет новый коммит с обращенным содержимым. В результате история в Git не теряется, что важно для обеспечения целостной истории версий и надежной совместной работы.
Универсальная команда Git для отмены изменений. У команды git reset есть ряд полезных опций, но в целях обучения мы рассмотрим следующие режимы:
- --soft : только сброс указателя HEAD до выбранного коммита. Действие команды аналогично git checkout , но в этом режиме указатель HEAD не открепляется.
- --mixed : сброс указателя HEAD до выбранного коммита в истории и отмена изменений в индексе.
- --hard : сброс указателя HEAD до выбранного коммита в истории, отмена изменений в индексе и отмена изменений в рабочем каталоге. В рамках данного обучения мы не будем демонстрировать работу команды reset в режиме hard.
По мере продвижения по учебному руководству вы узнаете несколько других команд Git для отмены изменений, поэтому давайте начнем.
Форк репозитория
Начнем с создания уникального репозитория, содержащего весь код оригинального репозитория. Этот процесс называется разветвлением (созданием форка) репозитория. Создание форка — это расширенный процесс Git , который используется, когда общий репозиторий размещается на стороннем сервисе хостинга, таком как Bitbucket.
Теперь, когда в локальной системе есть репозиторий со всем кодом и существующей историей, можно приступать к отмене некоторых изменений.
Поиск изменений в локальной системе
Вы должны уметь находить изменение, которое хотите отменить, и ссылаться на него. Найти конкретное изменение можно через пользовательский интерфейс коммитов в Bitbucket и с помощью нескольких утилит командной строки.
git status
Команда git status возвращает состояние рабочего каталога (местоположения репозитория в локальной системе), раздела проиндексированных файлов (места, где вы подготавливаете набор изменений для добавления в историю проекта), показывает все файлы, в которых есть изменения, и сообщает, были ли эти изменения добавлены в раздел проиндексированных файлов. Давайте теперь выполним команду git status и проверим текущее состояние репозитория.
Согласно выводу команды git status , все данные соответствуют данным в удаленной главной ветке main, а изменений, ожидающих коммита, нет. В следующем примере мы внесем небольшие изменения в репозиторий и рассмотрим его в состоянии отложенных изменений. То есть мы рассмотрим репозиторий, находящийся в локальной системе, в котором файлы изменены, но не подготовлены (или не проиндексированы) для добавления в историю проекта.
Для выполнения следующего примера откройте файл myquote2.html . Внесите изменения в содержимое myquote2.html , сохраните их и закройте файл. Выполним команду git status еще раз, чтобы исследовать это состояние репозитория.
Теперь давайте отменим изменения, внесенные в файл myquote2.html . Поскольку это упрощенный пример с минимумом изменений, мы можем отменить их двумя способами. Если выполнить команду git checkout myquote2.html , репозиторий восстановит файл myquote2.html до версии предыдущего коммита. Если же выполнить команду git reset --hard , весь репозиторий будет возвращен к состоянию последнего коммита.
git log
Команда git log позволяет просматривать и фильтровать историю проекта, а также искать конкретные изменения. С помощью git status можно просматривать рабочий каталог и раздел проиндексированных файлов, в то время как git log показывает только историю коммитов.
В следующем примере история состоит из нескольких изменений, но каждое изменение по сути является коммитом. Это то, что нам нужно найти и отменить.
Рассмотрим один из перечисленных коммитов внимательнее.
Вы можете заметить, что каждый комментарий к коммиту состоит из четырех элементов.
Буквенно-цифровая строка (генерируемая функцией SHA-1), по которой можно идентифицировать то или иное изменение
Лицо, сделавшее коммит изменения
Дата внесения изменения в проект с помощью коммита
Комментарий к коммиту
Текстовая строка с описанием изменения.
Рекомендация: пишите короткие содержательные комментарии к коммитам для обеспечения согласованной работы всех участников, использующих репозиторий.
Поиск местонахождения конкретного коммита
Обычно отменяемое изменение находится где-то среди ранних записей истории проекта, а история может оказаться довольно длинной. Итак, давайте изучим две основные операции, используя для поиска конкретного изменения команду git log .
- В окне терминала перейдите на самый верхний уровень локального репозитория с помощью команды cd (change directory — сменить каталог).
Введите команду git log --oneline . Параметр --oneline отобразит каждый коммит в отдельной строке, поэтому в окне терминала поместится больше записей из истории.
В любое время вы можете нажать клавишу q, чтобы закрыть журнал коммитов и вернуться к командной строке.
Вы увидите нечто подобное:
- Нажмите клавишу q, чтобы вернуться к командной строке.
- Найдите коммит с хешем c5826da и комментарием more changes в списке, образованном после выполнения команды git log . Кто-то не написал подробный комментарий к коммиту, поэтому необходимо выяснить, есть ли в нем необходимые нам изменения.
- Выделите и скопируйте хеш коммита c5826da из вывода команды git log в окне терминала.
- Введите команду git show , а затем вставьте скопированный хеш коммита или перепишите его и нажмите клавишу ввода. Вы увидите нечто подобное:
Строка внизу продолжит заполняться до тех пор, пока не отобразится изменение целиком. Нажмите клавишу q, чтобы закрыть командную строку.
Фильтрация вывода команды git log для поиска определенного коммита
Отфильтровать и скорректировать вывод команды git log можно с помощью следующих параметров:
Ограничивает количество отображаемых коммитов
10 последних коммитов в истории
Ограничивает отображаемые коммиты установленными временными рамками
Вы также можете использовать --after "гггг-мм-дд" --before "гггг-мм-дд"
Все коммиты после 4 июля 2017 года
Выводит список всех коммитов, автор которых совпадает с указанным
Все коммиты, у которых в поле имени автора содержится строка «Alana»
Возвращает все коммиты, комментарий к которым содержит указанную строку
Все коммиты, содержащие строку «HOT-» в комментарии к коммиту
Это был очень краткий обзор команды git log . Если вам понравилось работать с ней, вам может быть интересно ознакомиться с расширенным обучающим руководством по git log.
Отмена изменения с помощью git reset
Сначала давайте просто отменим последний коммит в истории. Предположим, вы только что включили конвейеры непрерывной интеграции и непрерывной поставки (CI/CD) Bitbucket, но обнаружили, что скрипт работает не совсем так, как нужно.
- Введите в окне терминала команду git log --oneline .
- Скопируйте хеш второго коммита в журнале ( 52f823c ), а затем нажмите клавишу q, чтобы закрыть журнал.
- Введите в окне терминала команду git reset --soft 52f823c . Если все нормально, команда должна запуститься в фоновом режиме. Вот и все, вы отменили ваше первое изменение. Теперь давайте посмотрим на результат этого действия.
- Введите в окне терминала команду git status . Вы увидите, что коммит был отменен, а изменения теперь остаются неподтвержденными. Это будет выглядеть примерно так:
- Введите в окне терминала команду git log --oneline . Вы должны увидеть что-то увидите нечто подобное:
- Вы увидите, что в качестве нового указателя HEAD для ветки указан требуемый коммит 52f823c .
- Нажмите клавишу q, чтобы закрыть журнал. Не закрывайте терминал, поскольку теперь, после изучения простого применения команды reset, мы рассмотрим чуть более сложный вариант.
Отмена нескольких изменений с помощью git reset
Допустим, вы обнаружили, что запрос pull № 6 ( 4801b87 ) необходимо доработать, и при этом вы хотите поддержать чистоту истории, поэтому на этот раз вы будете сбрасывать указатель HEAD до коммита 1a6a403 с помощью команды git reset .
- Введите команду git log --oneline .
- Скопируйте хеш коммита 1a6a403 (myquote edited online with Bitbucket), созданного прямо перед запросом pull № 6, в котором мы хотим отменить изменения.
- Введите в окне терминала команду git reset 1a6a403 . Вывод должен выглядеть примерно так:
Как видно, изменения теперь находятся в ожидании коммита. Это означает, что теперь мы удалили несколько изменений как из истории проекта, так и из раздела проиндексированных файлов.
Введите в окне терминала команду git status . Вывод должен выглядеть примерно так:
Теперь Git вообще не отслеживает первое отмененное изменение (файл bitbucket-pipelines.yml ). Это связано с тем, что команда git reset удалила изменение как из указателя HEAD ветки, так и из области отслеживания (или индекса) Git . Основной процесс выглядит несколько сложнее, чем описывается в этом руководстве, подробнее см. в руководстве по команде git reset .
- Введите в окне терминала команду git log --oneline .
Согласно выводу команды log, история коммитов также была изменена и начинается с коммита 1a6a403 . Для демонстрации следующего примера допустим, что мы хотим отменить сброс, который только что выполнили. В дальнейшем мы, возможно, захотим сохранить содержимое запроса pull № 6.
Отправка результатов отмены в Bitbucket
Команда git reset — один из способов отмены, которые предлагает Git . В целом сброс с помощью команды reset считается небезопасным. Он хорошо подходит для локального применения к изолированному коду, но становится опасным при работе над общим кодом с другими участниками команды.
Чтобы поделиться сброшенной веткой с удаленной командой, необходимо использовать принудительную отправку изменений. Принудительная отправка изменений выполняется с помощью команды git push -f . Она уничтожит всю историю ветки, созданную после этой точки отправки.
Ниже приведен пример небезопасного сценария.
- Разработчик A работает в ветке над новой возможностью.
- Разработчик B работает в той же ветке над другой возможностью.
- Разработчик B решает сбросить ветку к более раннему состоянию, когда разработчики A и B еще не приступили к работе.
- Разработчик B принудительно отправляет сброшенную ветку в удаленный репозиторий.
- Разработчик A делает запрос pull для этой ветки, чтобы получить обновления. Во время выполнения запроса pull разработчик A получает принудительное обновление, которое сбрасывает его локальную ветку к тому моменту времени, когда он еще не начал работать над новой возможностью. Соответственно, он теряет все коммиты.
Отмена команды git reset
До сих пор мы передавали в git reset SHA-хеши коммитов Git . Теперь вывод команды git log не показывает сброшенные коммиты. Как их вернуть? Git никогда не удаляет коммиты окончательно, хотя все указатели на них открепляются. Кроме того, Git хранит отдельный журнал со всеми перемещениями ссылок — reflog, или журнал ссылок. Проверить журнал ссылок можно с помощью команды git reflog .
Вывод команды git reflog должен быть аналогичен показанному в примере выше. Вы можете просмотреть историю действий в репозитории. Самая верхняя строчка является ссылкой на команду reset, которую мы выполнили для сброса запроса pull № 6. Теперь сбросим выполнение команды reset, чтобы восстановить запрос pull № 6. Во втором столбце вывода команды reflog находится указатель на действие по изменению репозитория. Здесь HEAD@ — это ссылка на выполненную нами ранее команду reset. Мы не хотим снова выполнять эту команду сброса, поэтому восстановим репозиторий до HEAD@.
Теперь давайте рассмотрим историю коммитов репозитория с помощью команды git log --oneline :
Здесь видно, что история коммитов репозитория была восстановлена до предыдущей версии, с которой мы экспериментировали. Коммит 4801b87 восстановлен, хотя был утерян при первой операции сброса. Команда git reflog является мощным инструментом для отмены изменений в репозитории. Подробнее о ее использовании см. на странице git reflog .
git revert
В предыдущих примерах было выполнено несколько важных операций отмены с перемещением во времени с помощью команд git reset и git reflog . Git содержит еще одну утилиту отмены, которая часто считается более безопасной, чем команда reset. Команда revert создает новые коммиты, которые содержат обратные изменения для указанных коммитов. Такие обратные коммиты можно безопасно отправлять в удаленные репозитории, чтобы делиться ими с другими разработчиками.
В этом разделе демонстрируется, как использовать команду git revert . Продолжим работу с нашим примером из предыдущего раздела. Для начала давайте посмотрим в журнал и найдем коммит для отмены.
В этом примере будем работать с самым последним коммитом — 1f08a70 . Предположим, что мы хотим отменить изменения, внесенные в этот коммит. Выполните следующую команду.
Это запустит рабочий процесс git merge . Git создаст новый коммит, содержимое которого будет сброшено до состояния коммита, указанного в команде revert. Затем Git откроет настроенный текстовый редактор, чтобы запросить комментарий к новому коммиту. Команда revert считается более безопасным способом выполнения отмены изменений, поскольку она соответствует рабочему процессу на основе коммитов. При создании обратных коммитов с помощью команды revert история коммитов наглядно показывает, когда выполнялась операция отмены.
Вы только что узнали, как отменять изменения!
Вы закончили, поздравляем! Вы можете в любое время вернуться к этому учебному руководству или ознакомиться с разделом «Отмена изменений», чтобы изучить эту тему подробнее. Продолжайте в том же духе в Bitbucket!
В рамках данного урока рассмотрим вопросы, касающиеся добавления, удаления и переименования файлов в git репозитории.
Добавление файлов в git репозиторий
Создайте в каталоге файл README.md любым удобным для вас способом, мы сделаем это с помощью команды touch .
Теперь проверим состояние отслеживаемой директории.
Как вы можете видеть: в рабочей директории есть один неотслеживаемый файл README.md . Git нам подсказывает, что нужно сделать для того, чтобы начать отслеживать изменения в файле README.md : необходимо выполнить команду git add , сделаем это.
Посмотрим ещё раз на состояние.
Видно, что информация о появлении нового файла попала в stage . Для того чтобы это изменение зафиксировалось в репозитории необходимо выполнить команду git commit .
Теперь в рабочей директории и в stage нет объектов, информацию об изменении которых необходимо внести в репозиторий.
В репозиторий был сделан один коммит.
Удаление файлов из git репозитория и из stage
Удаление файла из stage
Вначале разберемся со stage . Создадим ещё один файл.
Внесем изменения в README.md .
Информацию об этом также отправим в stage .
Посмотрим на состояние stage .
Теперь посмотрим на состояние рабочей директории и stage .
Удаление файлов из git репозитория
Удалим файл main.c из рабочей директории.
Уведомим об этом систему git .
Теперь в репозитории остался только один файл README.md .
Удалим файл из репозитория.
Файла main.c больше нет в репозитории.
Его также нет и в рабочем каталоге.
Удалите файл README.md из репозитория самостоятельно.
Переименование файлов в git репозитории
Первый способ. Создадим файл test_main_file.c и добавим его в репозиторий.
Содержимое репозитория после этого будет выглядеть так.
Переименуем его на test_main.c .
Сделаем это в рабочей директории.
Теперь отправим изменение в репозиторий.
В репозитории и в рабочей директории будет находится только файл test_main.c .
Второй способ.
В рамках второго способа рассмотрим работу с командой git mv . Переименуем файл test_main.c в main.c . Текущее содержимое репозитория и рабочего каталога.
Переименуем файл test_main.c на main.c средствами git .
Имя файла изменилось как в репозитории так и в рабочем каталоге.
В этой статье я расскажу, как удалить коммит из репозитория в Bitbucket.
А зачем вообще удалять коммит?
Может так случиться, что Вы случайно запушите конфиденциальную информацию в репозиторий Bitbucket.
Например, Вы отделили Ваш код от паролей, создав файл настроек, но забыли включить этот файл в .gitignore, в результате после того, как Вы закоммитили изменения и запушили в Bitbucket, файл с паролями виден всем, у кого есть доступ к репозиторию. Или же Вы что-то тестили и написали пароль прямо в исходном файле, Вы, конечно, хотели потом его удалить, но забыли. Вы закоммитили, запушили и Ваш пароль опять виден всем.
Хорошо, он виден всем. Нужно как-то откатить эти изменения. Но как?
Вы можете удалить репозиторий и создать новый. Но в этом случае нужно будет настроить новый репозиторий, как старый, сказать коллегам, что Вы создали новый репозиторий. Это как-то слишком сложно.
Более простой способ это удалить коммит с паролем
В этой статье я покажу, как это сделать.
Создадим репозиторий в Bitbucket
Сначала создадим репозиторий в Bitbucket:
Создадим локальный репозиторий, внесем изменения и запушим в Bitbucket
Я создам новую папку для репозитория:
Теперь инициализирую репозиторий и добавлю ссылку на мой Bitbucket репозиторий:
Создам новый файл и добавлю содержимое:
Вот содержимое файла mynewfile.txt:
Я закоммичу изменения и запушу в Bitbucket:
Внесу измененияи в mynewfile.txt с паролем:
Опять закоммичу изменения и запушу в Bitbucket:
Теперь у меня в Bitbucket два коммита:
И коммит с конфиденциальной информацией содержит мой пароль:
Даже если я сейчас быстро уберу из файла mynewfile.txt мой пароль, закоммичу изменения и запушу в Bitbucket, то я все-равно буду видеть мой коммит с конфиденциальной информацией, а значит и мой пароль. Поэтому нам нужно удалить коммит.
Удалим коммит с паролем
Давайте сначала найдем идентификатор нашего коммита:
Вот вывод этой команды:
Я пометил идентификатор коммита с паролем красный прямоугольником.
Этот коммит нам и нужно удалить. Но для того, чтобы его удалить, нам понадобится идентификатор предыдущего коммита. Вот он:
Теперь удаляем наш коммит вот такой коммандой. В команде мы указываем идентификатор предыдущего коммента:
Теперь файл mytextfile.txt выглядит вот так:
Правильно! Информации о пароле нет.
История коммитов выглядит вот так:
У нас нет коммита с паролем. Опять верно!
Но если мы посмотрим в Bitbucket, то коммит все еще будет там:
Правильно. Мы не запушили изменения. Давайте запушим:
И теперь если мы посмотрим в Bitbucket, то увидим только один коммит:
Отлично! Больше никто не видит наш пароль.
If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.
Читайте также: