Основы GIT

Привет! Сегодня знание основы GIT не преимущество, а норма. В любой студии требуется навык работы с системой контроля версий. Но даже если вы фрилансер-разработчик, то к вам могут обратиться клиенты, которые хотят получить вашу работу именно через git-репозиторий.

Отмечу, что всё, что здесь описано я брал из официальной документации. Но сделал я это упрощённо, без важных объяснений, по принципу «лишь-бы получилось и понималось, что сейчас произошло». Главная цель этого поста — познакомить читателя с основами без воды, чтобы он «втянулся», у него получилось, и с базовым багажом знаний ему было легче изучать git дальше.

Зачем вообще нужен GIT

Если вы знаете о том, что такое гит и зачем он нужен, то смело переходите к следующему заголовку.

GIT — распределенная система контроля версий. Определение само по себе говорит о том, что это такое. Но для наглядности рассмотрим простой пример: допустим, вы играете в компьютерную игру (пусть это будет стратегия, для лучшего понимания), в меню у вас есть несколько ячеек, в которые вы можете сохранить игру на определенном моменте, и благодаря этому в любой момент продолжить играть именно с сохраненного момента. При чем каждый раз с этого момента вы можете продолжить играть совершая другие действия, которые приведут к другим последствиям. Потом можете сохранить игру на моменте с другим результатом и так далее.

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

Пример мы разобрали теперь рассмотрим основы работы с системой. Я постараюсь описать все доступно.

Установка GIT

Для начала установим сам репозиторий. Для Windows можно использовать классический установщик, который можно скачать на официальном сайте. Для MacOS также можно скачать установщик.

Для linux-систем, выполняем в терминале следующую команду:

sudo apt-get install git

При установке через sudo, вас попросят ввести пароль вашей ОС.

Далее, нужно ввести ваши данные. В частности, ваше имя и почту. Для этого нужно выполнить следующие команды:

git config --global user.name "Vasili Pupkin"
git config --global user.email "git@example.com"

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

Инициализация git-репозитория

Чтобы создать GIT-репозиторий, нужно перейти в корневую папку проекта. Это можно сделать через терминал или командную строку такого вида:

cd C:\projects\first-git-repo\

Либо, если вы используете windows, можно открыть нужную папку проводником и в адресной строке ввести команду cmd и нажать Enter:

Далее, выполним следующую команду:

git init

И получаем уведомление, что пустой репозиторий был инициализирован 🙂

Также в проекте вы увидите, что появилась скрытая папка «.git» — это как раз и есть ваш репозиторий. В эту папку лазить ручками не нужно 🙂

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

Статус и добавление файлов в проект

Теперь создадим какой-нибудь файл в корне проекта. Пусть это будет файл index.html. Наполним его базовым html, а затем введем команду

git status

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

Git пишет нам, мол, «нет никаких добавленных файлов для коммита, надо добавить их с помощью команды «git add». Что-ж, давайте сделаем, как говорит нам система. Выполним команду, а за ней стразу-же проверим статус репозитория

git add index.html
git status

Как мы видим, что после выполнения команды «git add», наш файл стал отслеживаемым и готовым для коммита. Вообще, если вы работаете с реальным проектом, то конечно вы не будете добавлять каждый файл отдельно. Обычно используется команда «git add .», которая добавляет все файлы. Конечно, добавлять абсолютно все файлы для отслеживания не нужно, но об этом мы поговорим немного позже. Те файлы, которые не будут добавлены, просто не будут добавлены в коммит.

Также при использовании этой команды можно использовать маски. Например, мы хотим добавить в коммит только javascript-файлы. В таком случае необходимо выполнить следующую команду:

git add "*.js"

Допустим, вы выполнили команду «git add .», а потом вспомнили, что какой-то файл не должен был быть добавлен. Допустим, что это будет файл README.txt. Для этого просто выполним команду:

git reset HEAD README.txt

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

Теперь пришло время для первого коммита.

Коммит — это сохранение состояния проекта в репозитории. То есть, вы написали какой-то код, и вам нужно зафиксировать состояние проекта в том виде, в каком он есть сейчас. Это как сохранение игры.

Чтобы закоммитить проект, выполним команду:

git commit -m "my first commit"

где «-m» (от слова «message») говорит о том, что в рамках одной команды мы вводим комментарий к этому коммиту. Обычно в нем пишут о том, что было сделано с момента последнего коммита к тому, который мы собираемся сделать. Например, добавлена какая-то функция или исправлен баг.

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

Теперь, после выполнения команды, снова выполним «git status»:

выполнение команды git commit

Сообщение «nothing to commit, working tree clean» говорит о том, что с момента последнего коммита мы ничего не меняли, и смысла коммитить никакого нет.

Давайте теперь добавим что-то в наш файл:

<!DOCTYPE html>
<html>
<head>
    <title>Заголовок</title>
</head>
<body>
    <p>Lorem ipsum dolor sit amet</p>
</body>
</html>

А теперь выполним команду «git status»:

Как видим, закоммитить мы ничего сейчас не можем, потому что репозиторий не подготовлен к этому. Чтобы выполнить коммит, мы сначала выполним команду «git add .» (с точкой в конце), и потом «git commit -m «my second commit»»:

выполнение команды git commit -m "my second commit"

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

Предположим, что мы внесли изменения в файл (пусть это будет тот-же README.txt), сделали коммит, но изменения конкретно в этом файле вам не нужны. При этом меня всё руками — долго. Для этого мы просто выполняем команду:

git checkout -- README.txt

Перемещение между версиями

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

Чтобы вернуться к нужному состоянию, необходимо ввести команду «git checkout commit», где commit — это хеш нужного нам коммита. Чтобы узнать хеш нужного коммита, нужно ввести команду «git log», после чего мы получим список наших комиков вместе с их хешами, а также узнаем, на каком коммите мы сейчас находимся (HEAD -> master). Таким образом вводим команду и наблюдаем за чудесами 🙂

выполнение команды git checkout feodoraxis

Если проект длится долго, то просто вызывать «git log» — бесполезно. У вас появится просто огромное количество записей, в которых невозможно ориентироваться. Поэтому у команды есть фильтры. Допустим, чтобы получить коммиты за последнюю неделю, можно выполнить команду:

git log --since*2.weeks

Ветки

GIT — распределенная система контроля версий. Это значит, что благодаря ей над одним проектом могут работать сразу несколько разработчиков не мешая друг другу. Чтобы это было возможно, разработчики работают в разных ветках, а потом их объединяют (мержат — от слова «merge»).

Изначально в любом git-репозитории все начинается с главной ветки «master». А от нее уже ответвляются все остальные ветки в иерархическом порядке. Рассмотрим простой пример:

Упрощенная схема-пример веток git

Это очень упрощенная схема того, как могут ответвляться ветки git-репозитория. Мы с вами работали в ветке master для академического примера.
Например: Вы работаете над проектом. В последнем коммите ветки master та версия проекта, которая работает сейчас у заказчика. Пусть это будет сайт. И в один момент заказчик может вам написать, мол, на сайте баг, и его нужно поправить. При этом то, что вы делаете сейчас ещё не протестирвоано и выкатывать это на боевой сервак нельзя. В этом случае, вы создаете от ветки master дополнительную ветку hotfix (срочная корректировка), вносите исправление и мержите её в мастером. Все здорово. После этого возвращаетесь в свою ветку, над которой работали, и продолжаете спокойно работать.

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

Более подробно о ветвлении рекомендую прочитать на официальном сайте git вот по этой ссылке.

О слиянии веток рекомендуюсь почитать также на официальном сайте по этой ссылке.

Навигация по веткам

Тут все просто. Чтобы создать ветку, нужно выполнить команду «git checkout -b name_of_the_branch», где «name_of_the_branch» — название вашей ветки.

Чтобы перейти в нужную ветку, выполняем команду «git checkout name_of_the_branch».

Важно держать в голове то, что эта ветка является дочерней для ветки master. При создании новой ветки вы автоматически попадаете в нее. Если после выполнения этой команды вы ее повторите но с другим именем, то вы попадете в ветку дочернюю по отношению к ветке, которую создали до этого. Поэтому, если вам, например, нужно создать несколько дочерних веток для ветки master, то после этого необходимо каждый раз в нее возвращаться и создавать новую дочернюю ветку. Пока вы новичок и только изучаете основы git, не знать это — нормально, но лучше как можно скорее изучить все особенности git.

Для наглядности выполним следующие команды по порядку:

  • git checkout -b feodoraxis
  • git log
  • git add .
  • git commit -m «test»
  • git log

А в итоге увидим примерно такую картину:

Выполнение git команд

Чтобы узнать именно о том, какие ветки у нас есть (а не все подряд коммиты к ним), использует команду «git branch».

Настройки проекта (.gitingnore)

Далеко не все файлы и директории необходимо отслеживать в репозитории git. Например, если вы делаете сайт на wordpress, то вам точно не нужно отслеживать директории «wp-admin» и «wp-includes». Для этого в корне проекта создаем файл «.gitignore», в котором пишем три строчки:

wp-admin/
wp-includes/
index.php

Готово. Теперь при работе с гитом, у вас не будут учитываться папки и их содержимое, а также файл index.php в корне директории. Если, например, вам не нужно учитывать версии директории plugins, то так и пишем,

wp-content/plugins

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

wp-content/*.jpg
wp-content/*.jpeg
wp-content/*.png
wp-content/*.gif
wp-content/*.svg
wp-content/*.webp
wp-content/*.mp4
wp-content/*.avi
wp-content/*.mow

Очень полезно, используйте.

Git push — как отправить проект на удаленный репозиторий

Если вы работаете в команде, то вам придется отправлять свои наработки на удаленный сервер.

Для этого используется команда git push.

Рассмотрим простой пример: я создам пустой репозиторий в моем аккаунте на github. Назову его gitlearn. Посмотрим, что нам предлагает GitHub после этого:

мануал по наполнению пустого git-репозитория

Нам предлагают один из трех вариантов:

  • Создать новый репозиторий у себя на компьютере
  • Отправить существующий репозиторий
  • Импортировать код из другого репозитория.

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

git remote add origin https://github.com/vash_nikname_on_github/slug_of_rep.git
git push -u origin master

Если у вас возникает ошибка, то попробуйте удалить ваш репозиторий на ПК. Просто удаляете в проекте папку .git

Далее, снова инициализируйте пустой репозиторий, сделайте коммит и выполните эти две команды.

Но делайте это только в том случае, если удаление истории коммитов и ваших наработок не навредит проекту, а других способов решения проблемы вы не нашли!

Таким образом, мы получаем наш репозиторий на github:

Git clone

Наверное, самая простая команда из всех. Например, вы начинаете работу над новым проектом, а в начале этого проекта — всегда идет создание типовых файлов. Чтобы не тратить время на это, вы можете использовать, например, стартер для проекта, с которым сможете начать работать. Например, вы пишете новую тему для WordPress. Можно создать новую директорию, файлы style.css, index.php, functions.php и так далее, наполнять их… Но это долго. Гораздо проще копировать стартер и продолжить работу с ним. Например можно использовать мой стартер, который я использую для создания новых проектов на wordpress, который можно установить по этой команде:

git clone https://github.com/feodoraxis/WordPress-Starter

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

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

Подитог

Мы с вами познакомились с основами GIT. Но это только основы, и поэтому я рекомендую изучить официальную документацию GIT, потому что она полноценная и даст вам корректное представление об этой технологии. Она, кстати, есть на русском языке.

А если вы увидели у меня в статье ошибку — напишите мне об этом, пожалуйста, с указанием на место этой самой ошибки вот сюда на почту — info@feodoraxis.ru