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

Git - один из видов систем контроля версий, набор консольных утилит. Такие системы отслеживают и фиксируют изменения в файлах, а позже позволяют вернуться к их определенной версии. Вам может пригодиться система контроля версий,если вы, например, программист, системный администратор, дизайнер (или в целом работаете с массивом изменяющихся файлов) и хотите сохранить каждую версию проекта. Вы сможете вернуться к любому из сохраненных состояний, просмотреть изменения и увидеть их авторов. Так гораздо проще исправлять возникающие проблемы.

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

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

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

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

$ sudo apt install git

Новейшая сборка доступна на официальном сайте Git по ссылке.

Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:

$ git --version

И следовать дальнейшим инструкциям.

Настроить рабочую среду нужно только один раз - после обновлений параметры не сбросятся. Если понадобится, в любое время можно изменить ваши настройки.

Самый удобный способ изменения конфигурации - встроенная утилита 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

Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:

$ git config --global user.name "Nickname"
$ git config --global user.email email@email.com

Если вы не до конца настроили систему для работы, в начале своего пути - не беда. Git всегда подскажет разработчику, если тот запутался, например:

• git –help - выводит общую документацию по git
• git [команда] –help - предоставит нам документацию по какой-то определенной команде
• Если вы вдруг сделали опечатку - система подскажет вам нужную команду
• После выполнения любой команды - отчитается о том, что вы натворили

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

Ветка в Git - это последовательность коммитов. С технической точки зрения ветка - это указатель или ссылка на последний коммит в этой ветке. По умолчанию, имя основной ветки в Git - master. Каждый раз, когда создается новый коммит, указатель ветки master автоматически передвигается на него.

Удобная поддержка ветвления - важное свойство Git. Использование ветвления позволяет решать отдельные задачи, не вмешиваясь в основную линию разработки.

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

Для создания нового репозитория используется команда git init. Эта команда выполняют только один раз для первоначальной настройки нового репозитория. Выполнение команды приведет к созданию нового подкаталога .git в вашем рабочем каталоге. Кроме того, будет создана новая главная ветка.

Команду git clone [URL] выполняют для создания копии (клонирования) удаленного репозитория. В качестве параметра в команду git clone передается URL-адрес (SSH или HTTP).

После клонирования удаленного репозитория его URL-адрес нужно добавить в локальный файл config, а также создать вышестоящую ветку для локальных веток. Такую возможность предоставляет команда git remote.

$ git remote add [имя] [URL удаленного репозитория]

Проект может иметь несколько удаленных репозиториев одновременно. Чтобы их различать существует возможность давать им разные имена. Обычно главный репозиторий называется origin.

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

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

В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой git add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой git commit.

$ git add hello.txt # Отметим hello.txt как подготовленный к коммиту файл

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

$ git add -A

Конечно добавлять всё сразу удобнее, чем прописывать каждую позицию отдельно. Однако, тут надо быть внимательным, чтобы не добавить по ошибке ненужные элементы. Если же такое произошло изъять оттуда ошибочный файл можно при помощи команды:

$ git reset hello.txt

$ git commit -m 'Описание коммита'

Ключ -m в примере означает commit message - комментарий разработчика. Он необходим для описания закоммиченных изменений сразу после ключа. Если его не будет - запустится выбранный по умолчанию редактор коммитов (какой-либо текстовый редактор). Этот редактор можно изменить через git config.

Для просмотра все выполненных фиксаций можно воспользоваться историей коммитов. Она содержит сведения о каждом проведенном коммите проекта:

$ git log

В ней содержиться вся информация о каждом отдельном коммите, с указанием его хэша, автора, списка изменений и даты, когда они были сделаны. Отследить интересующие вас операции в списке изменений, можно по хэшу коммита, при помощи команды git show:

$ git show [хеш коммита]

Если вдруг нам нужно переделать описание последнего коммита, можно написать следующую команду:

$ git commit --amend -m 'Новый комментарий'

Самый простой и быстрый способ получить изменения с сервера - выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.

$ git pull origin master

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

Для того, чтобы создать новую ветку:

git branch [название_ветки]
# или 
git checkout -b [название_ветки]

Переключаться между ветками можно такой командой:

git checkout [название_ветки]

Если на вашем компьютере есть проект со внесенными изменениями, и вы хотите поделиться новой версией - git push [имя удаленного репозитория] [ветка удаленного репозитория]. Если ваша ветка называется master, то команда для отправки коммитов станет такой:

$ git push origin master

Она сработает, если у вас есть права на запись на том сервере, откуда вы клонировали проект. Очень важно, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, unstable). Работая в команде, этому нужно уделять особое внимание.

Для установки ветки по умолчанию нужно добавить ключ '-u' - git push -u [имя удаленного репозитория] [ветка удаленного репозитория]. Команда для отправки коммитов:

$ git push -u origin <ветка>

После отправки на защищённой ветке будет создан запрос на слияние для валидного владельца.

Это необходимо, если мы сделали изменения на одной ветке (например unstable), а теперь хотим перенести их на основную ветку (например master):

$ git checkout master # переключаемся на ветку master
$ git merge unstable # cливаем unstable в master
# теперь в master у нас те же изменения, что и в unstable

Запрос на слияние (pull request) - это запрос от разработчика к владельцу репозитория на внесение изменений из одной ветки в другую. Разработчик предлагает владельцу репозитория включить свои изменения в основную ветку проекта. Владелец репозитория может просмотреть изменения, провести необходимые проверки и, при необходимости, принять или отклонить запрос на слияние.

1. Заходим на сайт https://git.sharix-app.org под своим аккаунтом;
2. Переключаемся на нужную ветку;
3. Затем нажимаем на кнопку «Новый запрос на слияние»;
4. Делаем запрос на слияние с веткой;
5. Готово!

В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore.

1. Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
2. Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
3. Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.

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

# .gitignore
*.log
build/
node_modules/
.idea/
my_notes.txt

Некоторые из настроек могут быть применены к каталогу, поэтому Git применяет их только к подкаталогам или набору файлов. Настройки, зависящие от пути, называются атрибутами и могут быть установлены либо в файле .gitattributes в любом из каталогов проекта (обычно, в корневом каталоге), либо в файле .git/info/attributes, если вы не хотите хранить их в репозитории вместе с вашим проектом.

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

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

1. pull (забрать изменения с сервера);
2. внести правки, добавить что-то важное в проекте;
3. add (добавить изменённые файлы к коммиту);
4. commit (сохранить состояние проекта с комментариями);
5. push (отправить изменения на сервер).
6. merge (при необходимости внедрить изменения из другой ветки проекта).

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

• Про Git кратко и простыми словами от skillfactory
• Официальная документация по Git
• Официальное исчерпывающее пособие по Git
• Удобная шпаргалка по Git от GitLab
• Удобная шпаргалка по Git от GitHub
• Учебные материалы по Git от Atlassian: Bitbucket
• Подробный курс по Git на YouTube с канала JavaScript.ru
• Онлайн утилита для генерации .gitignore файлов
• Классная статья про Git для новичков.Часть 1
• Классная статья про Git для новичков.Часть 2
• Небольшое руководство по основам Git. Git за полчаса
• Статья по основам Git от Selectel