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).
Можно добавлять в индекс как файлы, так и папки. Например, эта команда подготовит для будущего снимка папку и файл :
git add
При этом все остальные файлы, даже если они отслеживаются в репозитории (tracked files) и были отредактированы (edited files), в следующий снимок не попадут.
Есть удобные вариации команды add:
git add -A добавляет все файлы (вновь созданные, измененные и удаленные) git add . добавляет вновь созданные и измененные файлы, но не удаленные git add -u добавляет измененные и удаленные, но не вновь созданные
Нетрудно заметить, что команда:
git add -A
эквивалентна двум поочередно выполненным командам:
git add . git add -u
Удаление файлов из репозитория и с диска
Возможно, вам покажется странной фраза «добавляет удаленные файлы». На самом деле это нормально: чтобы удалить файл из локального репозитория, недостаточно просто удалить его с диска. Надо после этого еще выполнить определенную команду git.
Если речь идет об отдельном файле, то команда:
git rm
добавляет файл в индекс как удаленный. При этом файл удаляется и с диска, если еще не был удален оттуда.
git add -u
позволяет выполнить git rm для всех удаленных с диска файлов одновременно, то есть отправить их в индекс.
Удаление файлов только из репозитория
Бывает надо удалить файлы из репозитория, но не удалять с диска. Например, мы отправили в репозиторий логи, которым там не место.
А на диске они должны оставаться. Чтобы добавить этот лог в индекс как удаленный, но оставить его при этом на диске, выполним команду:
git rm --cached mylogfile.log
То же самое для папки делается так:
git rm --cached -r mydirectory
Что войдет в следующий снимок
Чтобы посмотреть, что же вы итоге подготовили для снимка, выполните команду:
$ git diff --name-only --cached
Благодаря параметру —name-only выведутся только названия файлов.
Команда git commit
А дальше просто — отправьте в локальный репозиторий все находящиеся в индексе файлы, комментарий обязателен:
$ git commit -m "комментарий"
Эта команда создает новый snapshot — снимок репозитория. К этому снимку можно будет вернуться в будущем. Ваши данные и комментарий будут также доступны при просмотре истории.
add и commit одной строкой
Бывает удобным отправлять файлы в репозиторий побыстрее, не выполняя по очереди add и commit. Можно выполнить эти команды и вместе:
git commit -a -m "комментарий"
Вышеприведенная команда — это то же самое, что выполненные по очереди команды:
git add . git commit -m "комментарий"
Кратко это звучит как «добавь в индекс все измененные файлы и сделай снимок с указанным комментарием».
Обратите внимание, что удаленные файлы затронуты не будут.
Но можно создать в конфигурации любую команду из комбинации add и commit (правда, это редко используется):
git config --global alias.add-commit '!git add -A && git commit'
Мы создали команду add-commit. И с помощью нее можем выполнять действия:
git add-commit -m 'комментарий'
Как отменить последний commit
Чтобы отменить последний локальный commit, выполните команду:
git reset HEAD~1
HEAD~1 указывает на предыдущую ревизию, так что команда вернет репозиторий к предыдущему состоянию.
Как отменить git add
Чтобы удалить все файлы из staging area, выполните команду:
git reset
Чтобы удалить конкретный файл, выполните команду:
git reset
Как удалить некоторые файлы из снимка
Специальной команды тут нет. Для этого надо отменить последнюю команду commit. Эта команда сдвигает указатель на предыдущее состояние:
git reset HEAD~1
В индексе останутся файлы. Надо удалить из индекса нежелательный файл:
git reset path/to/unwanted_file
Подробнее о команде reset читайте здесь.
И затем снова отправить файлы в репозиторий. Следующая команда позволит задействовать при отправке метаданные предыдущего коммита, в том числе предыдущий комментарий:
git commit -c ORIG_HEAD
ORIG_HEAD — ссылка на предыдущий снимок.
Как исправить комментарий снимка
Допустим, мы уже отправили изменения в локальный репозиторий, но надо исправить комментарий, так как в него закралась ошибка. Делаем так:
git commit --amend -m 'новый комментарий'
Автор sysout Опубликовано 12.07.2018 25.12.2019 Рубрики Git
Добавить комментарий Отменить ответ
Прошу прощения: на комментарии временно не отвечаю.
Введение в Git: настройка и основные команды
Как установить и настроить Git в различных ОС, создать новые и клонировать существующие репозитории, а также базовые концепции ведения веток.
Эта инструкция — часть курса «Введение в Git».
Смотреть весь курс
Введение
Git — один из видов систем контроля версий (или СКВ). Такие системы записывают изменения в набор файлов, а позже позволяют вернуться к определенной версии.
Вам может пригодиться СКВ, если вы, например, программист, системный администратор, дизайнер (или в целом работаете с массивом изменяющихся файлов) и хотите сохранить каждую версию проекта. Вы сможете вернуться к любому из сохраненных состояний, просмотреть изменения и увидеть их авторов. Так гораздо проще исправлять возникающие проблемы.
В целом СКВ можно разделить таким образом:
- Локальные — все файлы хранятся только в вашей операционной системе, например, разложены по папкам с версиями.
- Централизованные — проект хранится на сервере, а ваша рабочая версия включает только текущий набор файлов.
- Распределенные — копии проекта (и вся информация о версиях) располагаются не только на сервере, но и на нескольких клиентских машинах, чтобы обеспечить устойчивость к отказу сервера.
Очевидно, что Git — не единственная система контроля версий, однако по многим параметрам самая удобная и популярная на сегодняшний день. Благодаря распределенной структуре репозитории Git хранятся на всех клиентских компьютерах, что защищает от потерь данных и позволяет полноценно управлять версиями проекта оффлайн.
Главная отличительная черта Git состоит в подходе к обработке данных. Каждый раз при сохранении данных проекта (коммите) система фиксирует состояние файла (делает снимок) и создает ссылку на этот снимок. Последующие изменения отражаются через ссылки на более ранние версии файла. Нет необходимости снова сохранять файл целиком. К тому же, основываясь на контрольных hash-суммах, система снимков обеспечивает целостность всей истории изменений. На практике это означает, что невозможно (либо крайне трудно) полностью удалить данные из рабочего каталога и утратить к ним любой доступ. В большинстве случаев данные можно восстановить из ранней версии проекта.
Таким образом, систему контроля версий в Git проще всего представлять как поток снимков (сохраненных состояний проекта).
Принципы работы с Git
У проектных файлов в Git есть 3 базовых состояния
- Измененные (modified) — файлы в процессе рабочего редактирования.
- Индексированные (staged) — та часть измененных файлов, которая уже подготовлена к фиксации после редактирования.
- Зафиксированные (committed) — файлы, уже сохраненные в локальном репозитории.
У Git есть рабочий каталог, где хранятся метаданные и локальная база рабочего проекта. Именно эта часть копируется, когда вы клонируете проект (репозиторий) с сервера.
Чаще всего работа с Git устроена примерно так:
- Вы вносите правки в файлы рабочей копии проекта.
- Индексируете их, подготавливая к коммиту (здесь Git создает снимки новых правок).
- Делаете коммит, и индексированные правки наконец сохраняются в вашем каталоге Git.
Установка Git
Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).
Однако командная строка все равно удобна для тонкой настройки и «нестандартных» действий, поэтому полезно представлять себе, как управлять проектом через нее.
Сначала потребуется установить Git на свой компьютер.
Установка в Linux
Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:
> sudo dnf install git-all На Ubuntu и других Debian-подобных систем введите apt:
> sudo apt install git Более подробные сведения можно получить по ссылке: https://git-scm.com/download/linux.
Установка на Mac
Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:
> git --version И следовать дальнейшим инструкциям.
Если вы пользуетесь Homebrew, запустите команду:
$ brew install git Установка в Windows
Новейшая сборка доступна на официальном сайте Git по ссылке: https://git-scm.com/download/win (загрузка запустится автоматически).
Настройка Git
Настроить рабочую среду нужно только один раз — после обновлений параметры не сбросятся. Если понадобится, в любое время можно изменить ваши настройки.
Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:
- Параметры из файла [path]/etc/gitconfig (системные) могут работать для всех пользователей системы и репозиториев. Они редактируются командой git config —system.
- Параметры из файла ~/.gitconfig или ~/.config/git/config (глобальные) применяются к одному пользователю, если запустить команду git config —global.
- Локальные параметры из файла config в рабочем каталоге .git/config сохраняют только для выбранного репозитория. Ему соответствует команда git config —local.
Если запускать git config без параметров, будет использоваться локальный уровень, никакие из более глобальных настроек не изменятся.
Всю используемую конфигурацию можно просмотреть так:
> git config --list --show-origin Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:
> git config --global user.name "Danil Z" > git config --global user.email danilz@danilz.com Также можно выбрать и текстовый редактор, введя команду git config —global core.editor. Например, чтобы выбрать Emacs, выполните:
> git config --global core.editor emacs В Windows нужно указывать полный путь к файлу. К примеру, для установки Notepad++ нужно запустить подобную команду:
> git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" Стоит отметить, что на практике текстовый редактор в Git может и не пригодиться, особенно если вы активно используете стороннее ПО — например, в Visual Studio все текстовые заметки для Git можно писать в отдельном окне. Текстовые редакторы в командной строке отличаются своеобразным управлением, которое потребует от вас отдельного изучения.
Общий список текущих настроек просматривается с помощью команды git config —list. Проверить, что записано в любой из доступных настроек, можно командой с ключом git config :
> git config user.email Выбор ветки по умолчанию
Итак, наконец можно создать репозиторий в выбранном каталоге командой git init. Основная ветка автоматически будет названа master. Изменить это (в нашем случае задав ветку main) можно так:
> git config --global init.defaultBranch main Работа в репозитории
Как правило, есть два варианта начать работу с репозиторием Git:
- Можно выбрать локальный каталог и создать новый репозиторий в нем.
- Можно клонировать существующий репозиторий с локального компьютера или сервера. Обычно проекты клонируются именно с сервера.
Если у вас на компьютере уже есть рабочий проект, но еще не назначен контроль версий, то нужно сначала перейти в каталог проекта.
> cd /home/user/SomeConsoleApp > cd /Users/user/SomeConsoleApp > cd C:/Users/user/SomeConsoleApp > git init Команда создаст каталог с именем .git, в котором будут храниться структурные файлы репозитория.
И, наконец, нужно добавить под контроль версий все существующие файлы командой git add . (точка в конце важна!). Можно добавлять и по одному файлу, с помощью git add .
Заодно создадим начальный коммит командой git commit:
> git add readme.md > git commit -m 'Initial project version' Команду git add можно гибко настраивать с помощью дополнительных параметров (флагов), которые подробно описаны в официальной документации: https://git-scm.com/docs/git-add. К примеру, команда git add —force добавит даже игнорируемые файлы, а git add —update позволит обновить отслеживаемые файлы.
В этом репозитории вы можете продолжать работать и дальше, со временем обновляя его и отправляя рабочие версии на сервер.
Клонирование существующего репозитория
Когда вы работаете в команде, разрабатываемые проекты часто размещают на сервере. Это один из самых распространенных сценариев. Вам нужно получить копию проекта последней версии на свой компьютер, чтобы далее вносить в него свой вклад.
В качестве примера мы будем рассматривать проект, который создадим на ресурсе https://github.com/ . После регистрации на сайте и подтверждения по e-mail нужно создать новый репозиторий, как показано на скриншотах.
Видно, что можно выбрать тип репозитория:
- публичный (public) – доступ открыт для любого пользователя, однако права на редактирование выдает владелец проекта;
- приватный/скрытый (private) — проект виден только владельцу, другие участники добавляются вручную.
Для нашего примера создадим приватный репозиторий под названием SomeConsoleApp и будем работать с ним далее.
Самые удобные способы клонирования проекта — через протоколы HTTP и SSH, прочесть обо всех более развёрнуто можно по ссылке: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols.
Для наших целей воспользуемся протоколом https и следующей командой:
> git clone https://github.com/DanZDev2/SomeConsoleApp SomeConsoleApp На вашем компьютере в каталоге, куда вы перешли в командной строке, должен появиться каталог SomeConsoleApp, внутри него — каталог .git и все скачанные файлы репозитория последней версии.
После получения проекта обычно начинается более рутинный рабочий процесс — правки, добавление функционала и т. д. Далее в какой-то момент вы захотите сохранить прогресс в новой версии проекта.
Правила и периодичность обновления могут быть почти любыми, но хорошим тоном обычно считается сохранять рабочую (или промежуточно завершенную) версию. Важное требование для команд разработчиков — возможность сборки проекта, иначе другие участники команды будут вынуждены тратить время на борьбу с ошибками компиляции.
Сохранение снимков и просмотр статуса проекта
Как упоминалось ранее, часть файлов в рабочем каталоге может и не находиться под контролем версий. За отслеживаемыми файлами «наблюдает» Git, они были как минимум в прошлом снимке состояния проекта. Неотслеживаемыми могут быть, например, вспомогательные файлы в рабочем проекте, если они не зафиксированы в прошлой версии проекта и не готовы к коммиту. Их можно выделить в отдельную категорию для Git, о чем будет рассказано далее.
Сразу после клонирования все файлы проекта будут отслеживаемыми. Отредактировав их и привнеся что-то новое, вы индексируете (stage) и фиксируете (commit) правки, и так для каждой версии проекта.
При этом нужно внимательно следить, чтобы вспомогательные файлы, особенно объемные, оставались вне контроля версий. Если по недосмотру добавить их в коммит и отправить на сервер — вероятнее всего, ваши правки придется частично откатывать.
Проверить состояние файлов в рабочем каталоге можно командой git status. После клонирования консоль выведет примерно такую информацию:
On branch master Your branch is up to date with ‘origin/master’. nothing to commit, working tree clean Теперь отредактируем файлы (в этом примере было консольное демо-приложение, созданное с помощью Visual Studio) и сравним статус:
>git status On branch master Your branch is up to date with ‘origin/master’. Untracked files: (use “git add . ” to include in what will be committed) Program.cs SomeConsoleApp.csproj SomeConsoleApp.sln nothing added to commit but untracked files present (use “git add” to track) Теперь зафиксируем изменения. В коммит войдут только те файлы, которые вы изменили и добавили командой git add. Остальные будут лишь дополнительными файлами в каталоге проекта.
Стандартный способ — команда git commit, которую мы уже видели раньше. Без дополнительных аргументов она откроет встроенный текстовый редактор, поэтому для простоты рекомендуется добавить аргумент -m и вписать комментарий в кавычках:
> git commit -m "Task 2: basic project template added" Для удаления ненужных файлов из репозитория можно использовать команду git rm . Файл также пропадет из рабочего каталога. Выполнить коммит необходимо и в этом случае; до тех пор структура проекта не изменится.
Файл .gitignore
Как упоминалось ранее, в рабочий каталог могут попадать файлы, которые вам бы не хотелось отправлять на сервер. Это и документы с вашими экспериментами или образцами, и автоматически генерируемые части проекта, актуальные только на вашем компьютере. Git может полностью игнорировать их, если создать в рабочем каталоге файл с названием .gitignore и внести в него все имена ненужных файлов и папок.
Открывать файл можно в любом текстовом редакторе. Обычно удобнее не перечислять абсолютно все имена (которые к тому же всегда известны), а воспользоваться подобными инструкциями:
/bin /obj *.pdb *.exe Если прописать такое содержимое файла .gitignore, то репозиторий git будет полностью игнорировать папки /bin и /obj, а также любые файлы с расширениями .pdb и .exe, хранящиеся в вашем рабочем каталоге.
Рекомендуется создавать .gitignore до первой отправки вашего проекта в удаленный репозиторий, чтобы на сервер не попало никаких лишних файлов и каталогов. Разумеется, важно проверить, чтобы в .gitignore не были упомянуты критичные для проекта файлы, иначе у других участников команды возникнут проблемы после следующего обновления.
Управление удаленными репозиториями
Просмотреть список текущих онлайн-репозиториев можно командой git remote. Добавить другие — с помощью команды git remote add , например:
>git remote add myDemo https://github.com/DanZDev2/DemoApp >git remote myDemo origin Отправка изменений в удаленный репозиторий (Push)
На вашем компьютере есть проект со внесенными изменениями, но вы хотите поделиться новой версией со всей командой.
Команда для отправки изменений на сервер такова: git push . Если ваша ветка называется master, то команда для отправки коммитов станет такой:
> git push origin master Она сработает, если у вас есть права на запись на том сервере, откуда вы клонировали проект. Также предполагается, что другие участники команды за это время не обновляли репозиторий.
Следует к тому же помнить, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, Dev). Работая в команде, этому обязательно нужно уделять пристальное внимание.
Получение изменений из репозитория (Pull)
Самый простой и быстрый способ получить изменения с сервера — выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.
На этом этапе могут возникать конфликты версий, когда несколько человек поработали над одними и теми же файлами в проекте и сохранили свои изменения. Избежать этого можно, если изолировать части проекта, поручив работу над одной частью только одному человеку. Разумеется, на практике это не всегда выполнимо, поэтому в Git есть инструменты для разрешения конфликтов версий. Они будут рассмотрены далее.
Создание веток и переключение между ними
Создадим две дополнительные ветки Dev и Test (например, одна может пригодиться для процесса разработки, а другая — для запуска в тестирование). Введем команду git branch дважды с разными аргументами:
>git branch Dev >git branch Test Ветки созданы, но мы по-прежнему работаем в master. Для переключения на другую нужно выполнить git checkout :
>git checkout Dev Switched to branch ‘Dev’ Your branch is up to date with ‘origin/Dev’. Внесем некоторые изменения в файл README.md и зафиксируем их, чтобы они отразились в ветке Dev:
>git add . >git commit -m “dev readme changed” [Dev #####] dev readme changed 1 file changed, 2 insertions(+) Если теперь отправить их на сервер, то можно убедиться в появившемся отличии веток:
Для переключения обратно на ветку master нужно снова ввести команду git checkout master. Она не изменялась, а значит, после редактирования проекта ветки разойдутся. Это нормальная ситуация для проектов в Git. Важно только понимать, для каких целей используется каждая из веток, и не забывать вовремя переключаться между ними.
Слияние веток (merge)
Работа над проектами часто ведется в несколько этапов, им могут соответствовать ветки (в нашем примере Dev → Test → master). Отдельные ветки могут создаваться для срочного исправления багов, быстрого добавления временных функций, для делегирования части работы другому отделу и т. д. Предположим, что нужно применить изменения из ветки Dev, внеся их в master. Перейдем в master и выполним команду git merge :
>git merge Dev Updating #####..##### Fast-forward README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Изменения успешно перенесены. В наших упрощенных условиях команда завершилась без ошибок, не найдя конфликтов в файлах. Если же над общими участками какого-либо файла успели поработать несколько человек, с этим нужно разбираться вручную. При возникновении ошибок Git помечает общие части файлов из разных веток и сообщает о конфликте.
Для разрешения конфликтов есть консольная утилита git mergetool. Однако если файл проекта объемный, а общих частей много, пользоваться ей не слишком удобно. Общая рекомендация для таких случаев — пользоваться сторонними инструментами, как и в случае с текстовым редактором для Git.
Когда спорные участки всех файлов приведены к итоговому состоянию, нужно повторить стандартную процедуру: создать коммит и отправить их командой push в нужную ветку в репозитории.
Дальнейшая работа с проектом из репозитория Git, как правило, повторяется по алгоритму:
- pull (забрать изменения с сервера);
- внести правки, добавить что-то важное в проекте;
add (добавить изменённые файлы к коммиту); - commit (сохранить состояние проекта с комментариями);
- push (отправить изменения на сервер).
- merge (при необходимости внедрить изменения из другой ветки проекта).
Заключение
Мы рассмотрели, как устанавливать и настраивать Git в различных ОС, создавать новые и клонировать существующие репозитории, получать и отправлять новые версии проекта, а также ознакомились с базовыми концепциями ведения веток.
Этой информации обычно хватает для повседневных задач, связанных с хранением рабочих проектов.
Гайд по Git : Часть 1 : Как сделать коммит в Git
Отвечаю на вопросы: как сделать коммит, создать новую ветку, вмержить одну ветку в другую.
29 мая 2021 · 10 минуты на чтение
Git — это консольная утилита, для отслеживания и ведения истории изменения файлов в проекте. Чаще всего его используют для кода, но можно и для других файлов.
Я пользовался git еще в универе, было удобно писать диплом и не плодить 100 копий файлов с названиями: “диплом (новый)”, “диплом (новее нового)”, “диплом (новые правки)”.
Мои статьи основаны на отличном интерактивном курсе LearnGitBranching. Но у него есть существенный недостаток, они не используют настоящий Git в процессе обучения. Из-за этого ряд важных нюансов упускается.
В моей статье будет обучение на настоящем Git. Просто повторяйте команды за мной, чтобы попрактиковаться.
Спонсор поста
Что такое VCS?
Системы контроля версий (СКВ, VCS, Version Control Systems) позволяют откатить проект до старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске. Также есть хостинги репозиториев, такие как GitHub и GitLab, которые позволяют хранить проект в интернете.
VCS позволяют нескольким разработчикам работать над одним проектом и сохранять внесённые изменения независимо друг от друга. При этом каждый участник команды видит над чем работают коллеги.
Теперь, когда мы в общих чертах понимаем зачем нам Git, создадим свой первый репозиторий. Но сначала нужно установить git.
Установка git
Основой интерфейс для работы с Git-ом является консоль. Это не удобно использовать в работе, но некоторые проблемы решаются только через консоль.
Для установки на Windows нажимаем на кнопку ниже, скачиваем и устанавливаем.
Для Mac OS открываем терминал и пишем, если установлен Brew:
brew install gitЕсли Brew не установлен, то вводим эту команду.
git --versionПосле этого появится окно, где предложит установить Command Line Tools (CLT). Соглашаемся и ждем установки. Вместе с CLT установиться и git
Для Linux открываем терминал и вводим следующую команду.
# Debian или Ubuntu sudo apt install git # CentOS sudo yum install gitНастройка
Вы установили себе Git. Давайте теперь его настроим, чтобы когда вы создавали снимок проекта, указывался автор.
Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.
git config --global user.name "ваше_имя" git config --global user.email "адрес_почты@email.com"
Инициализация репозитория
Теперь вы готовы к работе с Git локально на компьютере. Для начала создадим папку, которая будет нашим обучающим проектом.
$ mkdir git-project $ cd git-projectЧтобы создать локальный репозиторий, необходимо выполнить команду:
$ git init Инициализирован пустой репозиторий Git в /home/upagge/Documents/git-project/.git/Посмотрим, какие файлы находятся сейчас в папке git-project :
$ ls -al итого 20 drwxrwxr-x 3 upagge upagge 4096 мая 25 13:04 . drwxr-xr-x 12 upagge upagge 12288 мая 25 13:02 .. drwxrwxr-x 7 upagge upagge 4096 мая 25 13:04 .gitПоявилась новая папка .git , которая содержит множество файлов и других папок. Предназначение этих файлов и папок мы разберем в другой статье.
$ ls -l .git/ итого 56 drwxrwxr-x 2 upagge upagge 4096 мая 25 13:04 branches -rw-rw-r-- 1 upagge upagge 92 мая 25 13:04 config -rw-rw-r-- 1 upagge upagge 73 мая 25 13:04 description -rw-rw-r-- 1 upagge upagge 23 мая 25 13:04 HEAD drwxrwxr-x 2 upagge upagge 4096 мая 25 13:04 hooks drwxrwxr-x 2 upagge upagge 4096 мая 25 13:04 info drwxrwxr-x 4 upagge upagge 4096 мая 25 13:04 objects drwxrwxr-x 4 upagge upagge 4096 мая 25 13:04 refsКоммиты
Коммит это одно из базовых понятий в Git. Если объяснять простым языком, то коммит это огромная копия вашего проекта в момент времени, когда этот коммит был сделан.
Но на самом деле git пытается быть лёгким и быстрым, так что он не просто слепо копирует весь проект каждый раз, а ужимает коммит в набор изменений или «дельту» между текущей версией и предыдущей. Это позволяет занимать меньше места.
Также Git хранит всю историю о том, когда какой коммит был сделан и кем. Это очень важно, можно посмотреть из-за кого упало приложение и навалять ему ��
Файлы в репозитории могут находиться в 3 различных “областях”.
Наш проект сейчас пуст. Давайте создадим наш первый файл:
echo "12345" > file.txt
На данном этапе только область “Рабочий каталог” содержит данные.
Рабочий Каталог это ваша папка с файлами, в данном случае это git-project . Две другие области сохраняют свое содержимое внутри папки .git в понятном и удобном для git формате, но не понятном для человека.
Считайте Рабочий Каталог песочницей, где вы можете опробовать изменения перед тем, как сделаете коммит. На данном этапе вы можете в любой момент стереть все изменения и вернуться к последнему коммиту. Они не будут сохранены в истории git.
Чтобы сохранить изменения – сделать коммит. Необходимо сначала добавить содержимое Рабочего Каталога в так называемый Индекс – это черновик коммита. Только файлы из Индекс попадут в коммит.
Без добавления файла в Индекс у нас не получится создать коммит, проверьте это сами с помощью комманды:
$ git commit -m "Первый коммит" На ветке main Начальный коммит Неотслеживаемые файлы: file.txt ничего не добавлено в коммит, но есть неотслеживаемые файлыДля добавления файлов в Индекс используется следующая команда:
git add file.txtКогда у вас много файлов, вы можете добавить их все разом git add —all .
Теперь сделаем наш первый коммит, выполнив команду git commit . Тем самым мы сохраним содержимое области Индекс как неизменяемый снимок в области HEAD . Обязательно нужно описать суть внесенных вами изменений, для этого используется флаг -m :
$ git commit -m "Первый коммит" [main (корневой коммит) 06f7fc0] Первый коммит 1 file changed, 1 insertion(+) create mode 100644 file.txtВсе, коммит готов. И файл попал в область HEAD . HEAD будет родителем следующего созданного коммита. Как правило, самое простое считать HEAD снимком вашего последнего коммита. Возможно пока не совсем понятно что такое HEAD , но о нем мы еще поговорим.
Если сейчас выполнить git status , то мы не увидим никаких изменений, так как все три области одинаковые.
Теперь мы хотим внести изменения в файл и сделать новый коммит. Мы пройдём через ту же процедуру: сначала отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать зеленым цветом. Допишем в файл цифры 67890.
echo "67890" >> file.txt
Теперь посмотрим, какие изменения произошли в git:
$ git status На ветке main Изменения, которые не в индексе для коммита: (используйте «git add …», чтобы добавить файл в индекс) (используйте «git checkout -- …», чтобы отменить изменения в рабочем каталоге) изменено: file.txt нет изменений добавленных для коммита (используйте «git add» и/или «git commit -a»)Нам подсказывают, что изменения не попадут в коммит, пока мы не сделаем git add . Выполним эту комманду чуть позже, пока добавим новый файл:
echo "qwerty" > new-file.txtЕще раз проверяем статус репозитория:
git status На ветке main Изменения, которые не в индексе для коммита: (используйте «git add …», чтобы добавить файл в индекс) (используйте «git checkout -- …», чтобы отменить изменения в рабочем каталоге) изменено: file.txt Неотслеживаемые файлы: (используйте «git add …», чтобы добавить в то, что будет включено в коммит) new-file.txt нет изменений добавленных для коммита (используйте «git add» и/или «git commit -a»)Новый файл появился в списке не отслеживаемых, то есть в Рабочем Каталоге . Давайте добавим в отслеживание этот файл, а так же измененный ранее.
$ git add file.txt new-file.txt $ git status На ветке main Изменения, которые будут включены в коммит: (используйте «git reset HEAD …», чтобы убрать из индекса) изменено: file.txt новый файл: new-file.txt
Теперь у нас есть изменения, которые будут включены в коммит. Значит пора сделать второй коммит:
$ git commit -m "Второй коммит" [main b66f9c7] Второй коммит 2 files changed, 2 insertions(+) create mode 100644 new-file.txt
Я уже упоминал, что у коммитов есть родитель, который указывает на предыдущий коммит. Из таких цепочек складывается “ветка”. О ветках мы поговорим в следующей статье. Пока достаточно знать, что по умолчанию у нас уже есть ветка main . Эта цепочка также является нашей историей проекта, вы можете вернуться к предыдущим коммитам в любой момент.
Для удобства восприятия, визуализируем наши коммиты. Кружочки это коммиты, а стрелочки между ними указывают на родителей.
Просмотр истории коммитов
Не все коммиты будете делать вы, какие-то будут делать ваши коллеги по команде, поэтому вам может понадобиться изучить историю коммитов. Одним из основных и наиболее мощных инструментов для этого является команда git log .
$ git log commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 (HEAD -> main) Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит commit 06f7fc0a337bb6105f6a792fcc93eb2dda2a4dda Author: uPagge Date: Tue Jun 15 21:48:54 2021 +0300 Первый коммитПомимо автора и даты, у каждого комита есть идентификатор, который называется hash. Пример: 2934ee19f4d4ca37ff9bea9dc8208ef5362d789e. Необязательно использовать такую длинную запись, git поймет и по первым 5 символам, какой hash вам нужен.
Команда git log имеет очень большое количество опций для поиска коммитов по разным критериям.
Одним из самых полезных аргументов является -p или —patch , который показывает разницу, внесенную в каждый коммит. Можно ограничить количество записей в выводе команды, используя параметр -2 :
$ git log -p -2 commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 (HEAD -> main) Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит diff --git a/file.txt b/file.txt index e56e15b..cbb384f 100644 --- a/file.txt +++ b/file.txt @@ -1 +1,2 @@ 12345 +67890 diff --git a/new-file.txt b/new-file.txt new file mode 100644 index 0000000..19f0805 --- /dev/null +++ b/new-file.txt @@ -0,0 +1 @@ +qwerty commit 06f7fc0a337bb6105f6a792fcc93eb2dda2a4dda Author: uPagge Date: Tue Jun 15 21:48:54 2021 +0300 Первый коммит diff --git a/file.txt b/file.txt new file mode 100644 index 0000000..e56e15b --- /dev/null +++ b/file.txt @@ -0,0 +1 @@ +12345 Навигация
Прежде чем перейти к более продвинутым фичам Git, важно понять различные способы перемещения по коммитам вашего проекта.
Detaching HEAD
Давайте разберемся, как нам откатиться к более старой версии нашего репозитория.
У git есть указатели на коммиты, своеобразный ярлыки, которые перемещаются от коммита к коммиту. Одним из таких ярлыков-указателей является HEAD .
HEAD — это символическое имя текущего выбранного коммита. По сути это, тот коммит, над которым мы в данным момент работаем.
Указатели могут ссылаться на другие указатели, обычно HEAD указывает на имя ветки. Но это можно изменить, например указать hash нужного коммита, чтобы откатиться к нему.
Создадим еще один файл и сделаем третий коммит:
$ echo "new new file" > three-file.txt $ git add three-file.txt $ git commit -m "Третий коммит" [main b64191a] Третий коммит 1 file changed, 1 insertion(+) create mode 100644 three-file.txt git log -2 commit b64191a1a53c7f28429042c1fe00702c15354fab (HEAD -> main) Author: uPagge Date: Tue Jun 15 21:52:20 2021 +0300 Третий коммит commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит Мы видим, что HEAD сейчас указывает на main , main это тоже указатель, обозначающий ветку. То есть HEAD указывает на main , который в свою очередь указывает на коммит dac5bb87a . Отделение (detaching) HEAD означает лишь присвоение его не ветке, а конкретному коммиту.
Представим, что нам надо посмотреть, как выглядел наш репозиторий после второго коммита. Для этого используем команду checkout и хэш второго коммита. Кстати, можно не указывать его целиком, достаточно первых 5 символов.
$ git checkout b66f9 Примечание: переход на «b66f9». Вы сейчас в состоянии «отделённого HEAD». Вы можете осмотреться, сделать экспериментальные изменения и закоммитить их, также вы можете отменить изменения любых коммитов в этом состоянии не затрагивая любые ветки и не переходя на них. Если вы хотите создать новую ветку и сохранить свои коммиты, то вы можете сделать это (сейчас или позже) вызвав команду checkout снова, но с параметром -b. Например: git checkout -b HEAD сейчас на b66f9c7 Второй коммит
Таким образом мы переключились на состояние второго коммита, в котором у нас еще не было файла three-file.txt , проверим это:
$ ls file.txt new-file.txtВызвав git log видим, что HEAD теперь указывает на второй коммит:
$ git log commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 (HEAD) Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит commit 06f7fc0a337bb6105f6a792fcc93eb2dda2a4dda Author: uPagge Date: Tue Jun 15 21:48:54 2021 +0300 Первый коммитПри этом мы не потеряли третий коммит и все изменения в нем, можем убедиться в этом с помощью следующей команды:
$ git log --all commit b64191a1a53c7f28429042c1fe00702c15354fab (master) Author: uPagge Date: Tue Jun 15 21:52:20 2021 +0300 Третий коммит commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 (HEAD) Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит commit 06f7fc0a337bb6105f6a792fcc93eb2dda2a4dda Author: uPagge Date: Tue Jun 15 21:48:54 2021 +0300 Первый коммитВернем указатель HEAD на main :
$ git checkout main Предыдущая позиция HEAD была b66f9c7 Второй коммит Переключено на ветку «main» $ ls file.txt new-file.txt three-file.txtОтносительные ссылки
Передвигаться по коммитам при помощи указания хешей неудобно. Поэтому Git поддерживает относительные ссылки. С относительными ссылками можно начать с какого-либо удобного места и двигаться от него.
Относительные ссылки — мощный инструмент, но мы разберем два простых способа использования:
- Перемещение на один коммит назад ^
- Перемещение на n коммитов назад ~
Для начала рассмотрим оператор каретки ^ . Когда мы добавляем его к имени указателя, Git воспринимает это как команду найти родителя выбранного коммита. Так что main^ означает “первый родитель ветки main”. main^^ означает прародитель (родитель родителя) main .
Давайте переключимся на коммит выше main :
$ git checkout main^ Примечание: переход на «main^». . HEAD сейчас на b66f9c7 Второй коммитДа, мы снова попали на второй коммит, то есть HEAD сейчас вновь указывает на второй коммит.
Может показаться, нужно еще раз вызвать команду git checkout main^ , чтобы попасть на первый коммит. Но это не так, указатель main остался на третьем коммите, мы сдвинули HEAD . Поэтому git checkout main^ запросит снова родителя третьего коммита.
Чтобы попасть на первый коммит, можно использовать указатель HEAD . Попробуем перейти к первому коммиту:
$ git checkout HEAD^ Предыдущая позиция HEAD была b66f9c7 Второй коммит HEAD сейчас на 06f7fc0 Первый коммитВернемся на третий коммит:
$ git checkout main Предыдущая позиция HEAD была 06f7fc0 Первый коммит Переключено на ветку «main»Оператор ~
Предположим, нужно переместиться на много шагов назад. Было бы неудобно печатать ^ несколько раз, так что Git поддерживает также оператор тильда ~ .
Опционально к тильде можно добавить количество родительских коммитов, через которые нужно пройти. Посмотрим, как это работает.
$ git checkout HEAD~2 Примечание: переход на «HEAD~2». . HEAD сейчас на 06f7fc0 Первый коммитМы переместились на первый коммит. Вернемся:
$ git checkout mainЗаключение
Это была первая статья по обучению git. Мы установили git и научились работать с некоторыми командами для создания коммитов и навигации по ним.
Этого уже достаточно, чтобы работать с Git локально и не потерять изменения, об остальных командах читайте в остальных статьях.
Если все получилось, переходите к следующему уроку ��
23 команды Git, которые должен знать каждый разработчик
Перед вами небольшая статья-шпаргалка, которая включает в себя команды удобные, но не всем знакомые команды Git, которые могут стать вашими постоянными спутниками в разработке.
Вести разработку, кстати, удобно в нашем кластере Kubernetes.
1. git init
Эта команда используется для инициализации проекта как репозитория git.
2. git clone
Эта команда клонирует репозиторий в новую директорию.
git config — это удобная функция, которая используется для настройки значений конфигурации Git на глобальном и локальном уровнях проекта. Примеры команд:
git config —local user.name «Name»
git config —global user.name «Name»
Если надо скопировать только файлы:
git clone —depth=1 git://someserver/somerepo dirformynewrepo
3. git remote add
Эта команда используется для добавления или подключения к удаленному репозиторию.
4. git remote -v
Эта команда используется для просмотра подключенных удаленных репозиториев.
5. git status
Эта команда используется для просмотра статуса файлов в вашем локальном репозитории. Отслеживаются ли файлы? Не отслеживается? Изменены ли они?
Пример: git add index.html
git add index.html style.css style.scss
Эта команда переносит все новые и измененные файлы в раздел проиндексированных файлов
Эта команда используется для индексирования ВСЕХ неустановленных файлов.
для конкретного файла
7. git reset
Эта команда используется для мягкой или жёсткой отмены изменений, позволяет сбросить состояние проекта до нужного коммита. Например.
отмена неотправленного коммита: git reset —hard HEAD^
отмена отправленного коммита ( возврат к состояние коммита 7880ae2 )
git reset —hard f7880ae2
git push origin -f
8. git commit
Эта команда совершает коммит — «закрепляет» промежуточные результаты.
git commit -m “Text message”
Пример: git commit -m «added navigation bar»
Команда -m позволяет указать commit message без обращения к редактору
git commit —amend
Команда —amend вносит в предыдущий коммит изменения, которые подготовлены к коммиту. Используется и для редактирования предыдущего commit message, если в нём допущены ошибки.
9. git push -u origin
Ключ -u (полный вариант —set-upstream ) создаёт в удалённом репозитории ветку, соответствующую локальной и связывает их.
Пример: git push -u origin master
Эта команда используется для отправки закоммиченных файлов в удаленный репозиторий (также известный как GitHub) в указанной ветке. Используйте эту команду, когда вы впервые отправляете файлы в удаленный репозиторий. Он зафиксирует место, куда вы отправляете эти файлы. И в следующий раз можно будет использовать команду git push.
10. git fetch
Эта команда используется для получения самой последней версии вашего локального репозитория. Загружает коммиты, файлы и ссылки из удаленного репозитория в ваш локальный репозиторий.
Бесплатный тестовый доступ к облаку на 30 днейПолучить
11. git pull
Эта команда используется для извлечения только что полученной информации и ее загрузки в локальный репозиторий. git pull запускает немедленное обновление локального репозитория.
12. git branch Эта команда используется для создания, просмотра переименования и удаления ветки, на которой вы сейчас находитесь.
Эта команда используется для предварительного просмотра всех веток в удаленном репозитории.
Эта команда используется для предварительного просмотра всех веток на сервере.
13. git checkout
Пример: git checkout master или git checkout develop
Эта команда используется для переключения на ветки, которые вы уже посещали ранее.
git checkout — ещё один вариант использования
14. git merge
Эта команда используется для объединения двух веток. Для этого укажите ветку, которую вы хотите унаследовать изменения. И имя ветки, которое вы будете использовать вместе с этой командой, — это ветка, которая предоставит изменения.
Пример: git merge develop
Здесь основная ветка наследует код из ветки разработки.
15. git merge — abort
Эта команда используется для отмены слияния.
Если нет ошибок, слияния будут успешными. Следовательно, это прерывание можно использовать только в ситуациях, когда слияние не удалось. Как понять, что нужно использовать эту команду? Ваш терминал скажет, что слияние не удалось. Он также может предложить вам исправить конфликты слияния.
Вот ещё один признак: ~/NextCloud/Documents/Web Projects/Cloud4Y (master)
Посмотрите в самый конец строки. В скобках написано (master). Это потому, что мы находимся в основной ветке. Если вы находитесь в ветке разработки, это будет означать (develop). Если смерджить не получилось, появится надпись (master|merging) или что-то в этом роде.
git merge -X theirs
Пример: git merge -X theirs develop
Эта команда используется для объединения двух веток. И если есть конфликты слияния, эта команда просто предположит, что вы предпочитаете изменения, сделанные в указанной ветке (а не в текущей).
16. git reset — hard HEAD
Эта команда удалит все изменения, внесенные вами в ваш локальный репозиторий, и обновит его до последней версии, которая была закоммичена на GitHub.
17. git reset HEAD^
Эта команда перемещает текущую ветку назад на два коммита, эффективно удаляя два снапшота, которые мы только что создали, из истории проекта. Он отменяет случайное закоммичивание и сохраняет изменения.
18. git clean -f
Эта команда используется для удаления неотслеживаемых файлов из вашего локального репозитория.
Эта команда используется для удаления неотслеживаемых директорий в вашем локальном репозитории. Вы также можете объединить его с git clean -fd, чтобы сделать и то, и другое.
19. git rm -r — cached
Пример: git rm -r —cached config.js
Эта команда используется для удаления файла из удаленного репозитория (GitHub), не удаляя его в локальном репозитории.
20. git bisect
Эта команда используется для обнаружения коммита, вызвавшего ошибку в коде. Так проще отследить коммит, где код работает и выявить проблемный коммит.
21. git diff
git diff — частое использование
Эта команда используется сравнения изменений.
22. git rebase
Полезно, если вы работали с веткой, но затем вам нужно объединить изменения, сделанные в этой ветке, с другой. С помощью git rebase вы можете «переместить» свою ветку поверх последней версии. Это также полезно, если команда следует общепринятым соглашениям о коммитах, таким как объединение коммитов вместе или разделение «больших» коммитов на «меньшие». Это используется в основном для «реорганизации» ваших коммитов.
git rebase -i HEAD~N
Склеить коммиты, переписав историю с момента HEAD~N, т.е. с того, что было N коммитов назад. -i — означает в интерактивном режиме.
23. git stash
Эта команда используется для сохранения неподтверждённых изменений в отдельном хранилище, чтобы можно было вернуться к ним позже. Сами файлы возвращаются к исходному состоянию. Команда полезна, когда вы работаете над одной веткой, хотите переключиться на другую, но вы ещё не готовы сделать коммит в текущей ветке. Таким образом, вы прячете изменения в коде, переключаетесь на другую ветку, возвращаетесь к исходной ветке, а затем разархивируете свои изменения.
git stash pop позволяет применить ранее отложенные изменения.