> For the complete documentation index, see [llms.txt](https://sallyit.gitbook.io/akademiait/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sallyit.gitbook.io/akademiait/hard-skills/devops-for-sa/git-vcs.md).

# Git (VCS)

**Система управления версиями (Version control system, VCS)** — программа, позволяющая сохранять состояние файлов (те самые версии), возвращаться к ранее сохраненному состоянию, сохранять последовательность изменений внесенных в файлы, отменять или заново применять эти изменения, отслеживать авторство изменений.

**Git** — это самая популярная система контроля версий. Гит позволяет смотреть историю изменений файлов, кто какие дополнения и когда вносил, как развивался проект, кто что в него добавлял и почему.

**GitHub** — это сайт-хранилище для историй версий проектов: вы подключаете Git, регистрируетесь на GitHub, создаёте онлайн-репозиторий и переносите файлы с Git на GitHub

### Репозиторий (git repository) <a href="#repozitorii-git-repository" id="repozitorii-git-repository"></a>

**Гит-репозиторий** — это облачное хранение вашего проекта на сервере. Например, на сервере GitHub, GitLab, Bitbucket. У каждого программиста может быть сколько угодно репозиториев, по одному на каждый проект.

[GitHub vs GitLab](broken://pages/0CZ0Fy13SrM8OZTxD338)

### Бранч (git branch) <a href="#branch-git-branch" id="branch-git-branch"></a>

**Бранч** — это ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект.

В гит-репозитории всегда есть как минимум один бранч, который называется master. Если не создавать других веток, то все изменения будут сразу идти в главную ветку проекта. Для очень маленьких или учебных проектов это терпимо, но в любом коммерческом коде поступают иначе: создают ветки.

Итак, чаще всего ветки используются в следующих случаях.

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

### Клонирование (git clone) <a href="#klonirovanie-git-clone" id="klonirovanie-git-clone"></a>

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

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

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

### **Смёржить** (git merge) <a href="#smyorzhit-git-merge" id="smyorzhit-git-merge"></a>

**Смёржить** (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки.

### Коммит (git commit) <a href="#kommit-git-commit" id="kommit-git-commit"></a>

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

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

Единственное требование к коммитам — указывать, что именно вы поменяли в проекте, человеческим языком. Хорошим тоном и правильным подходом считается писать, что именно вы изменили: «Добавил цвет и стили основной кнопки», «Убрали метод вызова старого API», «Сделали рефакторинг функции SetOutOfDate()». Это описание будут читать другие разработчики.

### Пуш и пулл (git push, git pull) <a href="#push-i-pull-git-push-git-pull" id="push-i-pull-git-push-git-pull"></a>

Чтобы отправить данные из своего проекта на сервер, используют gut push. Для этого программист указывает имя ветки, в которую хочет отправить свой код, а сервер их принимает, проверяет и добавляет к себе.

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

Пулл работает просто: он скачивает с сервера актуальную версию ветки и добавляет код оттуда вам на компьютер. Иногда этот код вступает в противоречие с тем, что уже успел сделать программист, и тогда возникает конфликт — нужно принять решение, какая версия одинакового кода останется в проекте, а что нужно будет убрать.

Отличия **get commit** и **push request** заключаются в следующем:

1. **Commit** сохраняет изменения в локальном репозитории, а **push** отправляет изменения из локального репозитория в удаленный репозиторий.
2. **Commit** создает контрольную точку в истории проекта, а **push** обновляет удаленный репозиторий последними изменениями.
3. Для **commit** требуется сообщение фиксации (что именно было сделано) для описания внесенных изменений, в то время как для **push** не требуется никаких сообщений.

### Последовательность действий <a href="#posledovatelnost-deistvii" id="posledovatelnost-deistvii"></a>

1. Вы подключаетесь к репозиторию и клонируете его. (git clone)
2. Делаете себе новую ветку. (git branch)
3. Перед началом работы делаете пулл, чтобы забрать актуальную версию файлов. (pull request)
4. Пилите в своей ветке то, что вам нужно.
5. Когда работа сделана, вы её коммитите. (git commit)
6. Чтобы отправить её другим ребятам, вы её пушите. (push request)
7. Когда работу одобряют и перепроверяют, вашу ветку мержат (сливают, склеивают) с мастер-веткой. (merge)
8. Пользователи счастливы, что вы добавили им новых возможностей.

Источники: