- Вступление
- Работа с локальным репозиторием
- Работа с GitHub
- Организация совместной работы команды над одним проектом
- Работа с ветками, локальный репозиторий и
origin - Пулл-реквесты
- Другие площадки: GitLab, Bitbucket
Здравствуйте, сегодня мы разберёмся с git - системой контроля версий. Эта технология позволяет организовать работу с исходным кодом, управлением его версиями, в том числе при командной работе над одним и тем же проектом, поскольку является распределённой системой.
Проблема, которую решает система контроля версий - как организовать работу команды над одним и тем же проектом, чтобы изменения каждого участника не потерялись. Конечно, можно просто обмениваться заархивированной папкой с проектом, каждый раз когда нужно внести какую-то правку. Но что делать, если сразу несколько человек отредактировали один и тот же файл в проекте? А что делать, если таких файлов десятки или сотни, а сам проект состоит из тысяч файлов с исходным кодом - а такие проекты встречаются нередко.
На помощь в таком случае приходит система контроля версий. При работе с такой системой, каждой изменение в коде фиксируется в этой системе, так что изменения не потеряются, даже если возникнет конфликт версий из-за одновременной работы с одним и тем же файлом разными участниками команды. Кроме того, можно гибко переключаться по разным версиям, так чтобы, например, поддерживать не только последнюю версию программы, но и вносить патчи в предшествующие версии, и при необходимости затем применить те же исправления и в последней версии.
Надо заметить, что в отличие от большинства клиент-серверных приложений, благодаря распределённой архитектуре, на каждом компьютере где была клонирована папка с git-проектом, она является полноценным репозиторем, наравне с тем который доступен на общем сервере. Впрочем, при командной разработке всё же обычно есть один сервер, на который каждый разработчик ориентируется, когда клонирует проект (то есть впервые скачивает его себе), заливает на этот сервер информацию о внесённых изменениях в проект.
Обычно исходный код программного продукта представляет собой множество текстовых файлов, которые содержат код на языке программирования, конфигурацию и другие файлы. Все они лежат в структуре папок, при этом у нас есть корневая папка, которая содержит всю эту иерархию целиком. Эта папка и будет являться git-репозиторием.
Я подготовил пример проекта, здесь содержится всего несколько текстовых файлов, но для знакомства с git этого должно хватить:
.
└── git-demo/
├── first-document.txt
├── second-document.txt
└── some-folder/
└── other-document.txt
Также у меня уже установлен git-клиент под Windows, инструкции по установке Вы можете найти по ссылкам в описании. Для установки на другие ОС также будут инструкции (Linux, macOs).
Давайте откроем командную строку в корневой папке проекта, и выполним команду git init:
User@MyPC MINGW64 /c/Repos/git-demo
$ git init
Initialized empty Git repository in C:/Repos/git-demo/.git/
Мы можем заметить, что в корневой папке появилась скрытая папка .git. В ней и находятся все служебные файлы, которые позволят нам управлять разными версиями нашего проекта. Обычно нет необходимости заходить в эту папку напрямую - все действия с git можно производить через командную строку или инструменты с графическим интерфейсом.
Только что мы инициализировали репозиторий, но он совершенно пустой. Впрочем, в этой же папке (и в дочерних папках) находятся несколько файлов, давайте добавим их в том виде, в котором они есть сейчас. Под добавлением имеется в виду, что в результате информация об этих файлах и их содержимом будет включена в git-репозиторий, и все последующие изменения в них также можно будет фиксировать в истории.
Я выполню добавление через командную строку, но последующие действия мы будем выполнять для простоты через графический интерфейс.
Для начала, я выполняю команду git add ., которая сообщит git'у, за изменениями в каких файлах нужно следить. Точка в данном случае указывает на то, что надо добавить все файлы в папке проекта. Используя команду git status, мы можем увидеть состояние репозитория:
User@MyPC MINGW64 /c/Repos/git-demo (master)
$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
first-document.txt
second-document.txt
some-folder/
nothing added to commit but untracked files present (use "git add" to track)
User@MyPC MINGW64 /c/Repos/git-demo (master)
$ git add .
User@MyPC MINGW64 /c/Repos/git-demo (master)
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: first-document.txt
new file: second-document.txt
new file: some-folder/other-document.txt
Теперь, когда git знает про все нужные файлы, мы можем зафиксировать эти изменения в истории. Для такой фиксации выполняется команда git commit, которая запишет в историю всё, что было только что добавлено в индекс командой git add:
User@MyPC MINGW64 /c/Repos/git-demo (master)
$ git commit -m "initial commit"
[master (root-commit) 638460f] initial commit
3 files changed, 9 insertions(+)
create mode 100644 first-document.txt
create mode 100644 second-document.txt
create mode 100644 some-folder/other-document.txt
Мы создали первый коммит в нашем репозитории, и в этом коммите зафиксирован факт добавления трёх файлов с их полным содержимым. Используя параметр -m, я указываю сообщение коммита: обычно это короткая фраза, описывающая суть изменений.
Давайте теперь для удобства перейдём в инструмент с графическим интерфейсом. Я открою папку с проектом в VS Code, в который также встроены инструмент контроля версий. Открываем один из файлов, и вносим в него некоторые изменения, а также добавляем новый текстовый файл new-file.txt. Теперь на вкладке "Source Control" мы видим список всех изменённых файлов:
Теперь давайте создадим второй коммит, зафиксировав эти новые изменения (редактирование одного файла и добавление второго). Вводим сообщение коммита и жмём "Commit", и все изменения будут автоматически добавлены в индекс и зафиксированы в истории, в коммите с указанным сообщением.
Надо заметить, что все коммиты в репозитории (кроме самого первого) помимо описания самих изменений в содержимом содержат ссылку на предыдущий коммит. Таким образом, формируется цепочка из коммитов, от первого до последнего. Забегая немного вперёд, можно отметить, что цепочка не обязательно линейная: она может ветвиться и сливаться вновь, поэтому корректнее говорить о том, что коммиты в git-репозитории формируют направленный ациклический граф, простите за духоту =)
Для просмотра истории коммитов (того самого графа коммитов) я открою эту же папку в Visual Studio, потому что там очень удобный на мой взгляд интрумент для этого:
Мы видим последовательность из всего двух коммитов. По каждому из них есть само сообщение коммита, его идентификатор, а также время и имя автора (его можно настроить глобально после установки git клиента). По клику на коммит открывается подробная информация о том, какие изменения были внесены.
- Расширение Git Graph для VS Code