作者:maria fedynich 6 年以前
618
更多类似内容
В схеме представлены основные команды по работы с git.
Для более детальной информации рекомендую ресурс https://www.atlassian.com/git/tutorials
Изменение содержимого предыдущего коммита и сообщения
Пример:
1. Сделать изменение в файле
2. Сделать коммит
3. Изменить файл снова
4. Выполнить команду git commit --amend "новое сообщениеl"
Оригинальный коммит будет заменен новым коммитом . Этого же эффекта можно достичь путем сброса последнего коммита в ветке, и повторного коммита новых изменений.
Коммит, который удаляет нежелательный коммит.
После выполнения команды можно справить сообщение коммита.
Команда оставляет в истории как измененный коммит, так и коммит, что он был Revert
произвольный коммит по hash
HEAD
последний коммит
Git позволяет исправить сообщение или файлы в случае, если коммит уже сделан.
Это просто сделать с последним коммитом с помощью git commit —amend. Все от последнего коммита добавится обратно в stage area и git попытается сделать новый коммит. Это дает возможность исправить сообщение коммитта или добавить новые файлы в отслеживаемую область.
Для более сложных исправлений, которые находятся не в последнем коммите (если изменения запушены), необходимо использовать git revert.
Новейший коммит можно получить с помощью псевдонима HEAD:
$ git revert HEAD
Для других коммитов лучше использовать идентификатор:
$ git revert <id commit>
Удаление самых последних коммитов из ветки.
Параметр --hard указывает, что рабочий каталог должен быть обновлен в соответствии с новым head ветки.
Ошибочные коммиты все еще находятся в репозитории. На них можно ссылаться, если заранее они отмечнены tag либо по hash.
Коммиты, на которые нет ссылок, остаются в репозитории до тех пор, пока не будет запущен сборщик мусора.
Опасность сброса
Сброс в локальных ветках, как правило, безопасен. Последствия любой «аварии» как правило, можно восстановить простым сбросом с помощью нужного коммита.
Однако, если ветка «расшарена» на удаленных репозиториях, сброс может сбить с толку других пользователей ветки.
Показывает разницу между любыми двумя коммитами
Выводит информацию о изменениях в коммите.
Первых несколько символов для hash будет достаточно
Закоммитить все (создать снимок)
По умолчанию ветка каждого репозитория называется master.
Конечный результат rebase очень похож на результат merge. Цепь коммитов линейна и гораздо более читабельна
Не использовать rebase:
1. Если ветка является публичной и расшаренной. Переписывание общих веток будет мешать работе других членов команды.
2. Когда важна точная история коммитов ветки (так как команда rebase переписывает историю коммитов).
Предпочтительно использовать rebase для кратковременных, локальных веток, а merge для веток в публичном репозитории.
git merge объединяет две ветви, применяя изменения, сделанные в new_branch к основной ветке проекта.
После ветка new_branch может быть удалена.
Порядок действий:
1. переключиться на master
2. git merge <name branch>
3. удалить ветвь - по желанию
Просмотреть список всех веток.
Master — текущая ветвь, отмеченная звездочкой
git tag -d
$git checkout
Переключиться версию, которая идет перед текущей версией. Т о можно создать тэг перед предыдущим тэгом.
$git tag
$git tag
Просмотр содержимого файла
Переключиться на версию по хэш
Команда checkout копирует любой снимок из репозитория в рабочий каталог
Однострочная история
Также возможны варианты:
git log --pretty=oneline --max-count=2
git log --pretty=oneline --since='5 minutes ago'
git log --pretty=oneline --until='5 minutes ago'
git log --pretty=oneline --author=<your name>
git log --pretty=oneline --all
Самый удобный:
git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short
В деталях:
--pretty="..." — определяет формат вывода
%h — укороченный хэш коммита
%d — дополнения коммита («головы» веток или теги)
%ad — дата коммита
%s — комментарий
%an — имя автора
--graph — отображает дерево коммитов в виде ASCII-графика
--date=short — сохраняет формат даты коротким
Многострочная история
Возвращает список всех фиксаций и их идентификаторы
Здесь будет информация по работе с GitFlow
Обычный git-репозиторий подразумевает, что вы будете использовать его как рабочую директорию, поэтому вместе с файлами проекта в актуальной версии, git хранит все служебные, «чисто-репозиториевские» файлы в поддиректории .git.
В удаленных репозиториях нет смысла хранить рабочие файлы на диске (как это делается в рабочих копиях), а все что им действительно нужно — это дельты изменений и другие бинарные данные репозитория. Вот это и есть «чистый репозиторий».
Добавить чистый репозиторий в качестве удаленного репозитория к оригинальному репозиторию
Получение изменений с сервера
Может принимать два параметра:
имя удаленного репозитория (remote);
ветка для толчка (ветка master по умолчанию для каждого репозитория).
Объединение fetch & merge в одной команде
git fetch извлекает новые коммиты из удаленного репозитория, но не сливает их с наработками в локальных ветках.
Т е новые коммиты будут в истории, но изменений не будет.
Для этого используется команда
git merge origin/master
Загрузка файлов на сервер
Передача локальных коммитов на сервер.
Может принимать два параметра:
имя удаленного репозитория (origin);
ветка для толчка (ветка master по умолчанию для каждого репозитория).
По умолчанию команда --all не заливат тэги.
--tags заливает все локальные тэги в удаленный репозиторий
Заливает все локальные ветки в удаленный репозиторий.
На тэги это не распространяется
Заливает определенную ветку в удаленный репозиторий
Клонирование репозитория
возможность иметь полностью рабочую копию любого проекта, загрузив локально.
Для того, чтобы загрузить что-то в удаленный репозиторий, нужно сначала установить соединение с ним.
Проект может иметь множество удаленных хранилищ одновременно. Традиционно основной удаленный репозиторий в Git называется origin.
Порядок действий:
1.
создать репозиторий в github
2. $git remote add origin <url>
Копия оригинального репозитория
Если работа над проектом проиcходит в команде, то в рабочем каталоге должно быть два репозитория: оригинальный и клонированный.
Все изменения делать только в клонированном. После заливать в оригинальный
Снятие индексированных изменений
Отмена изменений, которые были внесены командой add, но не закоммичены.
Команда reset сбрасывает буферную зону к HEAD. Это очищает буферную зону от изменений, которые были проиндексированы.
Команда reset (по умолчанию) не изменяет рабочий каталог. Поэтому рабочий каталог все еще содержит нежелательный комментарий. Можно использовать команду checkout, чтобы удалить нежелательные изменения в рабочем каталоге.
Отмена локальных изменений (до индексации)
Отмена изменений, которые еще не были внесены командой add
Добавление изменений в stage area
Порядок действий:
1. изменение в репозитории
2. $git status
3. $git add ...
Индексанция изменений
Отметить текущее состояние файла.
Для новых файлов: добавляются в stage area. Cтатус: unstage -> stage
.
Cамый краткий и удобный путь для добавления всех изменений в файлы текущего каталога и его подкаталоги.
-A
Добавить все, что есть в каталоге
Добавить один файл по имени
Git хранит свои файлы и историю в папке проекта.
Будет создан скрытый каталог .git, где будет храниться история хранилища и конфигурации.
Создание хранилища вместе с репозиторием
создать хранилище прямо из папки проекта