Git clean up что делает
Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
Administration
Plumbing Commands
Check your version of git by running
SYNOPSIS
DESCRIPTION
Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.
. arguments are given, only those paths are affected.
OPTIONS
Show what would be done and clean files interactively. See “Interactive mode” for details.
Don’t actually remove anything, just show what would be done.
Be quiet, only report errors, but not the files that are successfully removed.
Use the given exclude pattern in addition to the standard ignore rules (see gitignore[5]).
Remove only files ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files.
Interactive mode
When the command enters the interactive mode, it shows the files and directories to be cleaned, and goes into its interactive command loop.
The command loop shows the list of subcommands available, and gives a prompt «What now> «. In general, when the prompt ends with a single >, you can pick only one of the choices given and type return, like this:
You also could say c or clean above as long as the choice is unique.
The main command loop has 6 subcommands.
Start cleaning files and directories, and then quit.
This shows the files and directories to be deleted and issues an «Input ignore patterns>>» prompt. You can input space-separated patterns to exclude files and directories from deletion. E.g. «*.c *.h» will excludes files end with «.c» and «.h» from deletion. When you are satisfied with the filtered result, press ENTER (empty) back to the main menu.
This shows the files and directories to be deleted and issues an «Select items to delete>>» prompt. When the prompt ends with double >> like this, you can make more than one selection, concatenated with whitespace or comma. Also you can say ranges. E.g. «2-5 7,9» to choose 2,3,4,5,7,9 from the list. If the second number in a range is omitted, all remaining items are selected. E.g. «7-» to choose 7,8,9 from the list. You can say * to choose everything. Also when you are satisfied with the filtered result, press ENTER (empty) back to the main menu.
This will start to clean, and you must confirm one by one in order to delete items. Please note that this action is not as efficient as the above two actions.
10 Git-команд, которые стоит знать разработчику
В этой статье мы обсудим разные Git-команды, которые могут оказаться полезными для разработчика или специалиста по Big Data. Вы узнаете, как проверять, удалять и приводить код в порядок. А еще рассмотрим способы выхода из Vim и экономию времени с помощью псевдонимов Bash и конфигурации редактора Git.
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Проверяем все и вся
Вернуть, как было
Если вы работаете в коллективе и коммиты общие, тогда ваш выбор — git revert.
Не забывайте убедиться в том, что вы не отменяете коммит из опубликованной ветки, от которой зависят другие члены команды.
HEAD часто используется для my_commit, чтобы отменить изменения в вашем локальном рабочем каталоге с момента последней фиксации.
checkout лучше всего использовать для локальных отмен. В этом случае коммиты из удаленной ветки, от которой зависят ваши коллеги, не будут затронуты!
Если вы используете checkout с веткой вместо коммита, HEAD переключается на указанную ветвь, а рабочий каталог обновляется для соответствия изменениям. Это самое распространенное использование этой команды.
git revert my_commit — отмена последствий изменений в my_commit. revert выполняет новый коммит после отмены изменений.
revert безопасен для общих проектов, поскольку команда не перезаписывает изменения, от которых могут зависеть другие ветки.
Иногда вы просто хотите удалить неотслеживаемые файлы в вашем локальном каталоге. К примеру, запустив какой-то код, который создал много разных типов файлов, которые вам не нужны. К сожалению. Clean поможет мгновенно удалить их!
-n — флаг для пробного запуска, ничего не удаляется.
-f — флаг для удаления файлов.
-d — флаг для удаления неотслеживаемых директорий.
Наводим порядки
Если ничего не проиндексировано, команда позволяет вам редактировать последнее сообщение коммита. Используйте команду только в том случае, если коммит не был объединен с удаленной master-веткой.
Помогите, я застрял в Vim и не могу выбраться!
Git в некоторых случаях открывает сессию редактора Vim. И если вы не слишком хорошо знакомы с ним, то можете оказаться в затруднительной ситуации. Да и не только вы — к примеру, на Stack Overflow более 4 тысяч пользователей хотят знать, как выбраться из Vim.
Вот четырехэтапный план, который поможет закрыть Vim и сохранить изменения:
Изменяем редактор по умолчанию.
Вы можете избавиться от Vim совсем, если смените редактор по умолчанию. Вот команды для работы с популярными редакторами. Пример выбора другого редактора, в нашем случае Atom:
Ярлыки для команд Git
Что касается способа, приведенного выше, то теперь вы можете использовать gs вместо git status.
Собственно, это все на сегодня. Если есть возможность, укажите в комментариях, какие Git-команды используете вы и почему.
Git clean up что делает
Сегодня разберем основные и самые часто повторяющиеся команды Git. Этого минимума вам вполне хватит для того, чтобы чувствовать себя с Git уверенно и непринужденно
Файлы, перечисленные здесь, находятся в области промежуточного хранения, и они еще не находятся в нашем репозитории. Мы могли добавлять или удалять файлы со сцены, прежде чем их хранить в репозитории.
Чтобы сохранить наши поэтапные изменения, мы запускаем команду commit с сообщением о том, что мы изменили.
Я поместил некоторые в каталог с именем «octofamily», а некоторые другие оказались в корне нашего каталога «octobox». К счастью, мы можем добавить все новые файлы, используя шаблон с добавлением git. Не забывайте цитаты!
Итак, мы совершили несколько коммитов. Теперь давайте просмотрим их, чтобы узнать, что мы изменили.
К счастью для нас, есть git log. Подумайте о журнале Git как о журнале, который помнит все изменения, которые мы совершили до сих пор, в том порядке, в котором мы их совершили.
Мы пошли вперед и создали новый пустой репозиторий GitHub для использования с Try Git по адресу https://github.com/try-git/try_git.git. Чтобы подтолкнуть наш локальный репо к серверу GitHub, нам нужно будет добавить удаленный репозиторий.
Идем дальше и запускаем git remote add с опциями ниже:
Команда push сообщает Git, куда положить наши коммиты, когда мы готовы, и теперь мы готовы. Итак, давайте переместим наши локальные изменения в наш исходный репо (на GitHub).
Давайте притворимся, что прошло какое-то время. Мы пригласили других людей в наш проект GitHub, которые потянули ваши изменения, сделали свои собственные коммиты и подтолкнули их.
Мы можем проверить изменения в нашем репозитории GitHub и удалить все новые изменения, запустив:
О, похоже, были некоторые дополнения и изменения в семействе octocat. Давайте взглянем на то, что отличается от нашего последнего коммита, используя команду git diff.
В этом случае нам нужен diff нашего последнего коммита, который мы можем использовать для указания указателя HEAD.
Давайте применим git add к stage octofamily / octodog.txt, который я только что добавил в семейство для вас.
Хорошо, теперь идем дальше и запускаем git diff с опцией —staged, чтобы увидеть изменения, которые вы только что организовали. Вы должны увидеть, что octodog.txt был создан.
Вы можете разгрузить файлы, используя команду git reset. Идем дальше и удаляем octofamily / octodog.txt.
Команда git reset отлично справилась с проблемой остановки файла octodog.txt, но вы заметите, что он все еще там. Он просто больше не устраивает. Было бы здорово, если бы мы могли вернуться к тому, как все было до того, как появился октодог и разрушил вечеринку.
Когда разработчики работают над функцией или ошибкой, они часто создают копию (ака. branch) своего кода, с которой могут делать отдельные коммиты. Затем, когда все будет готово, они могут объединить эту ветку с основной master ветвью.
Мы хотим удалить все эти надоедливые октокаты, поэтому давайте создадим ветвь под названием clean_up, где мы сделаем всю работу:
Теперь, если вы наберете git-ветвь, вы увидите две локальные ветки: основную ветвь с именем master и новую ветвь с именем clean_up.
Вы можете переключаться между ветвями, используя команду git checkout
. Попробуйте теперь переключиться на ветку clean_up:
Итак, вы в ветке clean_up. Вы можете, наконец, удалить все эти надоедливые октокаты, используя команду git rm, которая не только удалит фактические файлы с диска, но и подготовит удаление файлов для нас.
Вы снова захотите использовать подстановочный знак, чтобы получить все осциллографы за один раз, запустить и запустить:
Теперь, когда вы удалили всех «кошек», вам нужно будет зафиксировать изменения.
Не стесняйтесь запускать git-status, чтобы проверить изменения, которые вы собираетесь совершить.
Идем дальше и проверяем основную master ветку:
Уже, наступил момент, когда вам нужно объединить ваши изменения из ветки clean_up в ветвь master. Сделайте глубокий вдох, это не так страшно.
Мы уже на главной master ветке, поэтому нам просто нужно сказать Git объединить ветку clean_up в нее:
Вы только что выполнили первое успешное исправление ошибок и слияние. Остается только убирать за собой. Поскольку вы закончили с веткой clean_up, она вам больше не нужна.
Вот и мы, на последнем шагу. Я горжусь, что вы сделали это так далеко, и было здорово узнать Git с вами. Теперь вам остается только нажать на все, над чем вы работали в удаленном репозитории, и все готово!
Потренироваться можно здесь! Этот Git Tutorial и был для вас опубликован на русском языке. Почти на русском 🙂
Отмена коммитов и изменений
В этом разделе мы обсудим доступные стратегии и команды Git для выполнения отмены изменений. Прежде всего необходимо отметить, что в Git не существует традиционной системы отмены, как в текстовых редакторах. Лучше воздержаться от сопоставления операций Git с какой бы то ни было традиционной концепцией отмены изменений. Кроме того, Git имеет собственную систему терминов для операций отмены, и в обсуждении лучше всего использовать их. В числе таких терминов — сброс (reset), возврат (revert), переключение (checkout), очистка (clean) и другие.
Git можно рассматривать как инструмент для управления временной шкалой. Коммиты — это снимки моментов времени или точек интереса на временной шкале истории проекта. Кроме того, с помощью веток можно управлять несколькими временными шкалами. Когда вы выполняете операцию отмены в Git, вы, как правило, перемещаетесь назад во времени или на другую временную шкалу, где ошибок не было.
Это руководство предоставляет все необходимые навыки для работы с предыдущими версиями проекта по разработке программного обеспечения. Сначала мы рассмотрим, как исследовать старые коммиты, а затем изучим разницу между отменой публичных коммитов в истории проекта и сбросом неопубликованных изменений на локальном компьютере.
Поиск утерянного: просмотр старых коммитов
Просмотр старых версий
В этом примере предполагается, что вы начали разработку безумного эксперимента, но не уверены, хотите его сохранить или нет. Чтобы принять решение, вы хотите взглянуть на состояние проекта до начала эксперимента. Прежде всего, нужно найти идентификатор редакции, которую вы хотите просмотреть.
Допустим, история вашего проекта выглядит примерно так:
Для просмотра коммита «Make some important changes to hello.txt» можно использовать команду git checkout в следующем виде:
Предположим, вы ведете разработку в главной ветке main по умолчанию. При каждом возвращении в ветку main можно использовать команду git revert или git reset для отмены нежелательных изменений.
Отмена коммита снимка
Технически существует несколько стратегий отмены коммитов. В дальнейших примерах предполагается, что история коммитов выглядит следующим образом:
Отмена коммита с помощью git checkout
Отмена публичного коммита с помощью git revert
Отмена коммита с помощью git reset
Отмена последнего коммита
Отмена неотправленных изменений
Рабочий каталог
Раздел проиндексированных файлов
Отмена публичных изменений
Резюме
Помимо основных команд отмены, мы рассмотрели другие команды Git: git log для поиска потерянных коммитов, git clean для отмены изменений, не подтвержденных коммитами, и git add для изменения индексирования.
Каждая из этих команд имеет собственную подробную документацию. Чтобы узнать больше о той или иной команде, пройдите по соответствующим ссылкам.
Подробное руководство по Git
Основные сообщения в консоли:
Снимки состояний как основа
Большинство систем хранят информацию как список изменений, связанных с файлами (Subversion).
GIT же делает снимок файлов в конкретный момент времени и сохраняется ссылка на этот снимок. Для увелечения эффективности на неизмененные файлы делается ссылка на их раннее сохраненные версии.
Контрольная сумма
3 состояния для файлов
Файлы в GIT могут находиться в 3 состояниях:
Как строится процесс работы в Git
Настройки
Данную информацию следует указать обязательно, так как она будет включаться во все ваши коммиты:
Узнаем подробности о том, как работает команда, например, log :
Пример файла .git/config
Псевдонимы (алиасы) в GIT
Команда git config позволяет создавать псевдонимы:
.gitignore
Игнорируем имена файлов:
Звезда означает фрагмент в имени:
Указываем диапозон (для игнорирования файлов):
Игнорируем от корня проекта:
При этом данные конструкции работают одинаково:
** используются, чтобы обозначить произвольное количество фрагментов пути:
! используется, когда требуется игнорировать все кроме чего-либо конкретного:
Жизненный цикл состояния файлов
Основные команды в Git
git init
Чтобы проинициализировать (создать) пустой Git репозиторий введите команду:
git clone
Получаем копию существующего репозитория, клонировав удаленный, например, с gitHub.
Эта команда аналогично предыдущей, но все файлы перемещаются в папку [name_folder]
git status
Команда, показывающая статус репозитория, чтобы увидеть в каком состоянии находится наш проект:
git add (Отслеживание новых файлов)
Данная команда может работать как «Добавление файлов к проекту» (добавляем в индекс).
Чтобы сообщить git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью команды:
git add (Индексация изменённых файлов)
Также данная команда может работать как «Добавление содержимого к следующему коммиту».
Давайте модифицируем файл, уже находящийся под версионным контролем. Чтобы проиндексировать его, необходимо выполнить команду:
git reset (Отмена индексирования)
Примечательно, что команда git status покажет, как отменить индексирование:
git commit
При каждой фиксации мы сохраняем снимок проекта, к которому можно вернуться в любой момент, или чтобы сравнить с текущим состоянием.
git rm
Чтобы удалить директорию:
git amend (Изменение последнего коммита)
Если вы что-то не сделали в последнем коммите, то отредактировать его не сложно. Все, что нужно это добавить изменения в индекс обычным образом:
Эта команда берет индексированный файлы и включает в коммит всю обнаруженную там информацию.
Чтобы изменить название коммита выполните:
git checkout (Отмена изменение в файле)
С подсказкой опять поможет команда git status :
Итак, файлы могут быть возвращены в состояние последнего коммита с помощью команды:
git checkout (Получаем предыдущие версии файлов, не трогая остальные)
Допустим нам нужно вернуть версию файла, которая была два коммита назад. При этом нам требуется откатить лишь один файл.
Восстановим файл index.html на момент конкретного коммита ( 0b335 ):
Или откатим версию файла до состояния из текущего коммита (откатим изменения, которые нас не устраивают):
git clone
Очистка проекта от всех изменений (git clean)
Команда git clean предназначена для удаления только неотслеживаемых файлов и директорий
Просмотр (diff)
Команда git diff используется для сравнения коммитов или файлов.
Сравниваем с текущим состоянием
Покажем изменения в рабочей директории с момента последнего коммита:
Но при этом обе приведенные выше команды игнорируют неотслеживаемые файлы.
Ограничим сравнение по пути:
Сравним состояние 2-х коммитов
Сравним состояние 2-х веток
сравним, что сделано в feature по сравнению с веткой master :
Сравниваем файлы из разных коммитов
Сравнение по словам
Чтобы включить отличия по словам:
Удаленный репозиторий
git remote (прсматриваем уд. реп.)
Команда git remote позволяет просмотреть удаленные репозитории
git remote add (добавляем уд. реп., для работы локально)
Добавление удаленных репозиториев под коротким именем:
— теперь вместо полного URL-адреса в командную строку можно вводить имя alias_repo
В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master :
git fetch (Извлечение данных из уд. реп.)
Извлечение данных из удаленного репозитория выполняется командой:
После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта.
git push (проталкиваем изменения на уд. сервер)
Отправляем изменения в удаленный репозиторий:
Отправим ветку master на удаленный репозиторий master :
Или, что тоже самое:
Отправим ветку master на удаленный репозиторий masterB :
git push (удаляем удаленные ветки)
Удаляем ветку в удаленном репозитории:
git pull (скачиваем изменения)
git remote show (получаем инфо. об уд. реп.)
Удаленные ветки
Если вам потребуется своя локальная ветка ( name_branch ), аналогичная удаленной ветки, то можно воспользоваться командой:
Или создадим локальную ветку, чье имя будет отличаться от имени удаленной ветки:
Текущая ветка начнет следить за удаленной origin/test-git
Чтобы увидеть актуальные ветки наблюдения:
Ветвление
Ветки в Git всего лишь указатели на предыдущие коммиты, перед каждым коммитом указатель автоматически сдвигается вперед.
git branch (создаем ветку)
При создании новой ветки создается новый указатель, который, как отмечалось выше, автоматически сдвигается вперед (при каждом коммите).
Указатель HEAD указывает на текущую локальную ветку.
Узнаем указатели веток:
Обратите внимание. Узнаем указатели веток, историю коммитов, точки расхождения:
git branch (управление ветками)
Отобразим все ветки:
* указывает на ветку с указатедем HEAD(текущая).
Отобразим ветку с информацией о коммите:
Ветки слитые с текущей:
Ветки не слитые с текущей:
git checkout (смена веток)
Перейдем в существующую ветку:
Создадим и сразу перейдем в нее:
Переносим коммиты в другую ветку или Передвигаем (Откатываем) коммиты
Создадим ветку ( feature ) от текущей:
Теперь нам нужно передвинуть master на то количество коммитов, которое нам необходимо.
Или, пусть master указывает туда же куда и new_f :
Создадим ветку master на указанном коммите и переключимся на нее:
git merge
Объединяем текущую локальную ветку с удаленной:
Создаем новую ветку на основе изменений в другой ветке
Бывают ситуации, когда вы начинаете работать на какой-либо ветке, но изменения становится настолько большими, что вам хотелось бы перенести их в новую ветку. Это сделать довольно просто:
—ours к файлу
Допустим, после merge ветки feature в master в файле index.html появились конфликты, при этом мы уверены, что код на ветке master правильный. Чтобы разрешить конфликты в этом случае нам поможет команда:
—theirs к файлу
Если нам нужно взять версию из сливаемой ( feature ) ветки:
—merge к файлу
Вернуться к версии с маркерами конфликта:
Отменяем слияние и сбрасываем конфликты
reflog
Для адекватного вывода reflog используют команду, например, для ветки master :
Или без аргументов выведет reflog для HEAD :
Зачем нужен reflog:
Восстановим ветку по коммиту (под windows потребуются »):
Выводим reflog с датой:
2. Переходим на предыдущую ветку, с которой был checkout на текущую ветку:
Как работает: по reflog ищет ближайший checkout на текущую ветку.
git stash (сохраняем изменения)
Иногда возникает ситуация, когда вы работаете на одной ветке и вам срочно нужно переключиться на другую ветку, при этом регистрировать изменения нежелательно.
Для таких случае существует команда stash. Команда stash собирает незакоммиченные изменения, удаляет их из файлов и в специальном виде архивирует в Git.
git stash pop
Восстановить(вернуть) изменения поможет следующая команда:
Ошибки при git stash
Иногда мы можем сделать git stash pop не на той ветке, где сохранили изменения, это может привести к ошибке.
Просмотр истории и старых версий
git log
Для просмотра изменений (истории коммитов) используется команда
, которая покажет список последних коммитов и их хеши SHA1. Первыми показываются последние коммиты.
Или можно использовать
Или для конкретной ветки
У git log множество возможностей, например, мы можем выводить историю в более удобном формате:
Ограничивать коммиты по времени:
Показывать разницу, внесенную каждым коммитом:
Выведем коммиты достижимые из всех ссылок:
Просмотр коммитов (кроме)
Просмотр коммитов (И различий) по файлу
Выведем коммиты, в которых менялся файл index.html :
Выведем конкретные различия, в которых менялся файл index.html :
Флаги-фильтры для log (поиск изменений в файлах)
Поиск всех коммитов в описании которых есть слово word :
Найдем вызов функции:
Найдем объявление функции:
Не забывайте, что function doAny\( это регулярное выражение.
Выводи все коммиты с n-й по n-ю строку, например, выведем с 3-й по 7-ю строку:
Или найдем фрагмент кода по регулярному выражению:
Возможность очень полезная, так как позволяет отследить изменения любого блока кода в файле.
git show
git show используется для того чтобы проанализировать коммит, по хэшу:
git show (Смотрим на коммит родителя/предыдущий)
смотрит на 2 коммита вниз (
Тоже самое можно указать через число:
Как посмотреть на файл в предыдущем коммите
Флаг HEAD можно заменить @ :
Посмотрим на файл index.html в ветке master :
Смотрим на текущую (проиндексированную) версию файла
Ищем коммит по описанию (слову)
Кто написал эту строку? git blame
Вывести информацию о том, кто написал каждую строку в package.json:
Сократим дату и выведем только те строки, которые нас интересуют (например, с 5-й по 8-ю):
git reset
Как вернуть коммит, убранный reset
Подведем итог: мягкий reset отменяет коммит, но оставляет все подготовленные для коммита данные.
Передвигает ветку, сбрасывает индекс, но не трогает рабочую директорию. То есть изменения останутся в рабочей директории, но не будут проиндексированы. Пример использования:
reset переносит ветку, но так как HEAD указывает на текущий коммит, то ветка переносится туда же, где и сейчас, то есть ничего не происходит. Однако есть второй полезный момент: сброс индекса на состояние соответствующего коммита ( HEAD ), сами изменени останутся в рабочей директории, то есть очистка от всех изменений.
Для замены коммита запускаем:
Конфликты в Git
Команда git status позволяет увидеть файлы с конфликтами.
cherry-pick
Команда cherry-pick используется, чтобы переместить какой-либо коммит (по хешу) из одной ветки в другую.
Например, поместим коммит 268510c2f в ветку master (текущая).
rebase
Перенос веток
Отказ от переноса
Чтобы отказаться от переноса (например, ваш rebase остановился на конфликте) выполните команду:
Чтобы пропустить коммит при переносе, например, rebase остановился на конфликте, вы можете выполнить команду:
Отмена rebase
Отмена rebase после того как rebase завершился.
Или (что более надежно).
Работаем с bitbucket.org
1. кликаем по this repository Fork
3. создадим ветку (на основе удаленной ветки test-git )
4. и внесем в нее какие-либо изменения
5. Фиксация изменений
6. Отправка новой ветки в ветку на bitbucket
Далее переходи на bitbucket
7. Находим нужную ветку и делаем Create pull request (запрос на включение): где вы можете выбрать как проекты, так и ветки куда пойдет запрос на слияние.
Владелец проекта может выделить часть кода и написать к нему комментарий. Как только это произойдет пользователь, открывший запрос на включение получит уведомление. Пользователь вносит правки и отправляет его.
8. Принимаем pull request
Полезные приемы
Как в git заменить ветку master полностью другой веткой?
Я имею две ветки в моем репо:
2. seotweaks (создана от master )
