Статьи Утилиты Telegram YouTube RuTube Отзывы

Работа с системой контроля версий git из консоли

Видеогайд

12 апреля 2022

Тэги: Linux, руководство, файлы.

Содержание

  1. Установка
  2. Настройка
  3. Создание локального хранилища
  4. Клонирование репозитория
  5. Состояние хранилища
  6. Добавление файла к git
  7. Фиксация изменений (commit)
  8. Просмотр истории изменений
  9. Удаление файла из git
  10. Постраничный просмотр истории изменений
  11. Работа с ветками (branches)
  12. Работа с удалённым репозиторием
  13. Итоги

Git – это распределённая система контроля версий, которую создал Линус Торвальдс в процессе разработки ядра Linux.

Ключевой особенностью системы является её децентрализованность. Благодаря git вы можете вносить изменения в ветку (branch), которая хранится в репозитории (хранилище) на удалённом сервере и видна другим разработчикам. С другой стороны, вы можете создать свою локальную ветку, которая будет видна только на вашей рабочей станции. Однако в любой момент вы можете сделать её общедоступной, разместив в репозитории на удалённом сервере. А можете произвести слияние (merge) вашей локальной ветки с репозиторием так, что на сервере она будет выглядеть частью «ствола» дерева изменений.

В настоящий момент git как система контроля версий является стандартом среди разработчиков, поэтому давайте рассмотрим эту систему более подробно. Начнём с установки и настройки.

Установка

Установка под Ubuntu выполняется одной командой:

sudo apt install git

Настройка

Откроем консоль и сразу укажем имя пользователя и его почтовый ящик. Эта информация будет отображаться в истории изменений каждого нашего проекта. Не забудьте про кавычки.

git config --global user.name "Ivan Petrov"
git config --global user.email "ivan.petroff@test.com"

Все эти глобальные параметры вы также можете посмотреть и отредактировать в файле .gitconfig в вашей домашней директории. Под Ubuntu это /home/имя_пользователя/.gitconfig.

Глобальные параметры можно переопределить на уровне отдельного проекта. Для этого находясь в папке проекта, выполните указанные выше команды, убрав флаг --global.

Создание локального хранилища

В самом простом случае при помощи git можно организовать локальный репозиторий, в котором вы можете фиксировать изменения «для себя». Перейдём в любую директорию и создадим там пустой репозиторий:

git init

Клонирование репозитория

Если вы хотите скопировать уже существующий репозиторий, который размещён в централизованном хранилище (например, github), то вместо инициализации локального репозитория вам нужно его склонировать, используя url репозитория.

Где найти url репозитория в github

Этот url вы можете найти на главной странице репозитория в github, как показано на картинке выше.

git clone git@github.com:devmarkru/spring-jpa-rest-kotlin.git

После выполнения этой команды в текущей папке у вас появится папка проекта spring-jpa-rest-kotlin.

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

Состояние хранилища

Теперь давайте создадим в папке нашего проекта какой-нибудь текстовый файл, например, test.txt. В нём сохраним произвольный текст. А затем посмотрим в консоли текущее состояние хранилища:

# выводим строку текста и сразу сохраняем её в файл
echo "Some text string" > test.txt
# смотрим статус репозитория
git status

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

Добавление файла к git

В данном случае статус нам покажет, что появился «untracked» файл, который ещё не добавлен в систему контроля версий. Давайте добавим его, чтобы для него учитывалась история изменений.

git add test.txt

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

git add .

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

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

Фиксация изменений (commit)

Зафиксируем изменение файла test.txt в репозитории. Обязательно используйте опцию -m для указания пояснительного текста к изменению

# создание коммита
git commit -m "file test.txt added"

Если же вы хотите добавить многострочный комментарий при помощи текстового редактора, то можете выполнить просто git commit без параметров. В этом случае откроется текстовый редактор (например, nano или vim) и вы сможете ввести многострочный комментарий. После этого сохраните получившийся файл.

Просмотр истории изменений

Теперь это сообщение можно увидеть в истории изменений нашего проекта:

git log

Для каждого коммита отображается его автор, время коммита, описание и хеш. Этот хеш позволяет легко ссылаться на конкретный коммит, если история изменений слишком большая. Просто укажите первые несколько символов хеша после git log и вы сразу увидите этот коммит.

Изменим содержимое нашего файла test.txt. Его статус изменится на modified. Выполним второй коммит, чтобы зафиксировать это изменение. Обратите внимание, что второй раз команду git add выполнять не нужно.

echo "Some other text" > test.txt
git add .
git commit -m "second commit"

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

Удаление файла из git

Теперь удалим наш файл test.txt и сделаем третий коммит.

git rm test.txt
git commit -m "file removed"

Обратите внимание, что, если файл уже был добавлен к git, его нельзя удалять стандартной командой rm, а надо делать это средствами git.

Постраничный просмотр истории изменений

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

Также можно использовать более компактный вариант лога:

git log --pretty=oneline

В общем-то, этих операций достаточно, чтобы обеспечить базовое версионирование на отдельно взятой рабочей станции.

Работа с ветками (branches)

Git позволяет вести разработку независимых компонентов системы в отдельных ветках. Ветки могут быть как удалённые (remote), которые хранятся на сервере и доступны всем, так и локальные (local), которые хранятся на вашей рабочей машине и доступны только вам. Просмотреть доступные ветки можно при помощи следующих команд:

git branch -a # все ветки
git branch -r # только remote-ветки
git branch -l # только локальные ветки

Активная ветка, т.е. та, в которой вы находитесь сейчас, будет отмечена звёздочкой.

Чтобы переключиться на другую существующую ветку, выполните:

git checkout имя_ветки

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

Создать новую ветку и сразу перейти в неё:

git checkout -b имя_новой_ветки

Имя локальной ветки бывает удобно указывать по номеру задачи в вашей системе управления задач (например, Jira).

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

git checkout -b локальное_имя_ветки origin/имя_ветки_на_сервере

Работа с удалённым репозиторием

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

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

Общий вид команды для получения изменений с сервера:

git pull origin имя_локальной_ветки:имя_ветки_на_сервере

Можно также использовать сокращённый вариант:

git pull

После того как вы убедитесь, что новых изменений не было (или что они были успешно синхронизированы с вашей версией), отправьте ваши изменения на сервер.

Общий вид команды для отправки изменений на сервер:

git push origin имя_локальной_ветки:имя_ветки_на_сервере

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

Можно также использовать сокращённый вариант:

git push HEAD:имя_ветки_на_сервере

HEAD – это алиас, который всегда указывает на вашу текущую ветку.

Итоги

В данном руководстве мы узнали, что из себя представляет система контроля версий git. Научились создавать новый репозиторий локально, а также копировать уже существующий репозиторий. Также мы рассмотрели основные команды для добавления новых файлов, фиксации изменений и просмотра истории изменений. Наконец, мы научились синхронизировать локальный репозиторий с удалённым.


Облако тэгов

Kotlin, Java, Spring, Spring Boot, Spring Data, SQL, PostgreSQL, Oracle, Linux, Hibernate, Collections, Stream API, многопоточность, файлы, Nginx, Apache, maven, gradle, JUnit, YouTube, новости, руководство, ООП, алгоритмы, головоломки, rest, GraphQL, Excel, XML, json, yaml.

Последние статьи


Комментарии

Добавить комментарий

×

devmark.ru