> For the complete documentation index, see [llms.txt](https://docs.system-analyst-base.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.system-analyst-base.ru/hard-skills/devops-for-sa/git-vcs.md). # Git (VCS) {% hint style="info" %} **Система управления версиями (Version control system, VCS)** — программа, позволяющая сохранять состояние файлов (те самые версии), возвращаться к ранее сохраненному состоянию, сохранять последовательность изменений внесенных в файлы, отменять или заново применять эти изменения, отслеживать авторство изменений. {% endhint %} {% hint style="info" %} **Git** — это самая популярная система контроля версий. Гит позволяет смотреть историю изменений файлов, кто какие дополнения и когда вносил, как развивался проект, кто что в него добавлял и почему. {% endhint %} {% hint style="info" %} **GitHub** — это сайт-хранилище для историй версий проектов: вы подключаете Git, регистрируетесь на GitHub, создаёте онлайн-репозиторий и переносите файлы с Git на GitHub {% endhint %} ## Репозиторий (git repository) **Гит-репозиторий** — это облачное хранение вашего проекта на сервере. Например, на сервере GitHub, GitLab, Bitbucket. У каждого программиста может быть сколько угодно репозиториев, по одному на каждый проект. {% content-ref url="/pages/PtxPKIlhu5xxgDlkXNMK" %} [GitHub vs GitLab](/hard-skills/devops-for-sa/git-vcs/github-vs-gitlab.md) {% endcontent-ref %} ## Бранч (git branch) **Бранч** — это ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект. В гит-репозитории всегда есть как минимум один бранч, который называется master. Если не создавать других веток, то все изменения будут сразу идти в главную ветку проекта. Для очень маленьких или учебных проектов это терпимо, но в любом коммерческом коде поступают иначе: создают ветки. Итак, чаще всего ветки используются в следующих случаях. 1. Ветки нужны, чтобы несколько программистов могли **вести работу** над одним и тем же проектом или даже файлом **одновременно**, при этом не мешая друг другу. 2. Кроме того, ветки используются **для тестирования экспериментальных функций**: чтобы не повредить основному проекту, создается новая ветка специально для экспериментов. Если эксперимент удался, изменения с экспериментальной ветки переносятся на основную, если нет – новая ветка попросту удаляется, а проект остается нетронутым. 3. Помимо прочего, ветки можно использовать **для** разных выходящих **параллельно релизов** одного проекта. ## Клонирование (git clone) **Клонирование** — это когда вы копируете репозиторий себе на жёсткий диск. Это нужно, чтобы начать в нём что-то менять. Чем это отличается от простого копирования: когда вы клонируете репозиторий, вместе с файлами вашего проекта вы также тянете всю историю версий, все ветки, всю историю работы. И если кто-то дальше будет вносить изменения в проект, благодаря этим данным вы сможете тоже их получить. А если просто скопировать нужные файлы с чужого компьютера, то никаких историй и никаких связей не сохранится. Синхронизации не будет. Просто какие-то файлы. ## **Смёржить** (git merge) **Смёржить** (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки. ## Коммит (git commit) Программировать только в облаке неудобно — проще скачать себе на компьютер весь проект и писать код на своей машине. Но чтобы правки увидели остальные, их нужно отправить обратно в репозиторий. Это и есть коммит. Коммитить можно и один файл, и сразу несколько. Система сама найдёт, что изменилось в каждом файле, и добавит эти изменения в проект. Но все эти правки внесутся в репозиторий за один раз, потому что при коммите обрабатываются сразу все добавленные в список файлы. Единственное требование к коммитам — указывать, что именно вы поменяли в проекте, человеческим языком. Хорошим тоном и правильным подходом считается писать, что именно вы изменили: «Добавил цвет и стили основной кнопки», «Убрали метод вызова старого API», «Сделали рефакторинг функции SetOutOfDate()». Это описание будут читать другие разработчики. ## Пуш и пулл (git push, git pull) Чтобы отправить данные из своего проекта на сервер, используют gut push. Для этого программист указывает имя ветки, в которую хочет отправить свой код, а сервер их принимает, проверяет и добавляет к себе. Иногда бывает так, что сервер отказывается это сделать, потому что у программиста на компьютере была неактуальная ветка. За то время, пока он писал свои правки, другие программисты сделали несколько изменений, закоммитили их у себя и отправили на сервер. Получилось, что у одних эта ветка осталась свежей и актуальной, а у других она устарела. Чтобы не принимать запросы из устаревших веток, гитхаб просит сначала обновить данные у себя на комьютере с помощью git pull. Пулл работает просто: он скачивает с сервера актуальную версию ветки и добавляет код оттуда вам на компьютер. Иногда этот код вступает в противоречие с тем, что уже успел сделать программист, и тогда возникает конфликт — нужно принять решение, какая версия одинакового кода останется в проекте, а что нужно будет убрать. {% hint style="success" %} Отличия **get commit** и **push request** заключаются в следующем: 1. **Commit** сохраняет изменения в локальном репозитории, а **push** отправляет изменения из локального репозитория в удаленный репозиторий. 2. **Commit** создает контрольную точку в истории проекта, а **push** обновляет удаленный репозиторий последними изменениями. 3. Для **commit** требуется сообщение фиксации (что именно было сделано) для описания внесенных изменений, в то время как для **push** не требуется никаких сообщений. {% endhint %} ## Последовательность действий

Последовательность действий с шагами 1-8

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