# 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. Пользователи счастливы, что вы добавили им новых возможностей. Источники: * * * * * --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.system-analyst-base.ru/hard-skills/devops-for-sa/git-vcs.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.