Git — это систем контроля версий (от англ. Version Control System, VCS) . Она позволяет записывать изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии. Такие системы помогают разработчикам хранить и версионировать исходный код приложений, настройки систем и другие текстовые файлы. И хотя ничего не мешает использовать VCS в других областях, чаще всего они применяются именно в IT.
Git был разработан командой Линуса Торвальдса в 2005 году, как open-source аналог уже существующим системам. Но разработка Git не была спонтанным решением. Дело в том, что с самого первого релиза в 1991 году разработка ядра Linux выполнялась по старинке: старая версия архивировалась, а новые патчи от разработчиков становились новой версией.
Что такое Git
Большинство других систем контроля версий хранят информацию в виде списка изменений в файлах. Git работает иначе — он хранит скорее набор снимков — полное отображение того, как выглядит файл в момент сохранения. Это позволяет всегда иметь полную информацию обо всех файлах и быстро восстанавливать любую из предыдущих версий.
Рассмотрим, как это работает, на примере.
Есть проект, в котором пишется код. В нём создано окружение Git ― все изменения файлов отслеживаются в рамках настроенных параметров и заданных фильтров. Нужно добавить в проект новую функцию, изменив или доработав существующий код. Для этого потребуется создать внутри проекта отдельную ветку — в Git они называются branch. Работа в этой ветке никак не затрагивает основной код — если с новыми изменениями что-то пойдёт не так и код станет невалидным и перестанет запускаться, основной проект не пострадает. А когда новая функция будет дописана и протестирована, ветку можно будет «наложить» на основной код.
Также в рамках Git можно объединять разные версии кода в один. Например, над проектом трудится несколько программистов, и каждый разрабатывает или изменяет код в собственных ветках. В конце работы появится необходимость слить ветки вместе — и получается цельная программа. Это значительно облегчает совместную работу, так как не нужно ждать, пока другой разработчик допишет код, — можно работать параллельно.
Если же в одной из веток разработка пойдёт не по плану и произойдёт ошибка — всё можно просто откатить до предыдущей ветки в системе контроля версий Git, где ошибок не было. И начать разработку заново.
Git может быть локальным, централизованным или распределённым:
● Локальный установлен на одном компьютере и хранит файлы только в одном экземпляре в рамках настроенного окружения — подходит, если программист пишет код в одиночку.
● Централизованный находится на общем севере и хранит все файлы на нем.
● Распределённый хранит данные и в общем облачном хранилище, и в устройствах участников команды.
Распределённая система лучше всего подходит для командной работы. Даже если с центральным хранилищем что-то случится, проект можно восстановить из копий участников команды.
Удобство и гибкость сделали Git стандартом для большинства современных IT-компаний. Поэтому умение работать с ним критично для любого программиста. Но разобраться с ним можно только на практике, работая в связке с другими разработчиками. Этим в том числе занимаются студенты Практикума на курсе «Фронтенд-разработчик».
Принципы работы с Git
При работе с Git в среде разработчиков принято руководствоваться тремя принципами:
1. Регулярно коммитить ― сохранять изменения в Git. Такой подход позволит сохранять более подробную историю версий и быстро замечать ошибки в коде.
2. Создавать новые ветки. Они позволяют легко управлять изменениями, особенно параллельными. Лучше создать ещё одну ветку, чем что-то испортить в старой.
3. Чётко и лаконично описывать коммиты. Изменения кода, которые отправляются в Git, обязательно должны содержать пояснения и комментарии по добавленным правкам, доработкам и изменениям. Это значительно облегчает совместную работу и помогает быстрее разбираться в своем старом коде.
Git — мощный инструмент со множеством различных возможностей. Если изучить их досконально, можно серьёзно облегчить себе работу.
Начало работы с Git: установка и настройка
Установить систему контроля версий Git можно по алгоритму:
1. Перейти на страницу загрузки Git.
2. Скачать дистрибутив для нужной операционной системы.
3. Запустить установочный файл и следовать инструкциям на экране.
4. После завершения установки открыть терминал или командную строку и ввести команду git —version. Если Git правильно установлен, отобразится версия Git.
Это схема для установки Git локально. Для серверов алгоритм в целом такой же, но потребуется ещё настроить взаимодействие с локальными устройствами — но это уже работа системного администратора.
В настоящее время для операционных систем *nix/linux (MacOS, Debian, Fedora, Ubuntu, etc) система контроля версий Git чаще поставляется уже предустановленной.
Чтобы его настроить, нужно:
1. Ввести команды git config —global user.name «Your Name» и git config —global user.email «youremail@example.com». Это установит параметры автора коммитов.
2. Настроить редактор кода, используя команду git config —global core.editor «editor-name». Вместо editor-name следует ввести свой редактор кода. По умолчанию Git использует Vim.
3. Проверить настройки с помощью команды git config —list.
Также для работы потребуется создать репозиторий в Git. Это можно сделать по схеме:
1. Создать пустую директорию на диске.
2. Перейти в созданную папку и запустить терминал.
3. Инициализировать репозиторий командой git init. После выполнения этой команды в директории появится скрытая папка .git
4. Добавить в репозиторий файлы командой git add. После указанной команды выбранные файлы перейдут в статус «отслеживаемых» и можно будет увидеть производимые с ними изменения ― удаление, перемещение, переименование и изменения содержимого файлов.
5. Создать первый коммит командой git commit -m «Initial commit».
6. Создать ветку в Git командой git branch <название_ветки>
Чтобы полностью понять, как использовать Git, нужно изучить все его основные команды. Это можно сделать в документации.
«Джентльменским набором» для работы в Git можно считать набор команд:
● git commit — фиксация изменений
● git diff — просмотр актуальных или предыдущих изменений в рамках работы над репозиторием
● git checkout — переход на предыдущее состояние или ветку
● git push/pull — отправка и получение изменений из удалённого репозитория
● git stash — сохранение изменений в архив для последующего использования
Что такое репозиторий Git
Репозиторий может быть локальным ― храниться на компьютере пользователя. А может быть удалённым — лежать на сервере или в облачном хранилище. В таком случае пользователи со своих устройств подключаются к этому репозиторию через интернет.
Зачем нужен GitHub
По сути GitHub — это сайт-хранилище. Нужно сначала установить Git, потом зарегистрироваться на GitHub, создать там онлайн-репозиторий — и перенести туда файлы из своего репозитория. Можно настроить автоматический перенос и многие другие функции, которые позволят работать с кодом совместно.
На GitHub можно создавать публичные или открытые проекты — это позволяет знакомить со своим кодом других людей. А можно приватные или закрытые, доступные только тем, кто работает над кодом.
Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Каждое состояние файлов в Git можно зафиксировать (сделать коммит), причем это навсегда останется в истории репозитория. Поэтому можно в любой момент посмотреть историю изменений файлов, сравнить различные версии и отменить отдельные изменения.
Также Git упрощает ведение параллельной разработки несколькими членами команды. Для этого используется ветвление. Условно можно сказать, что в Git-репозитории есть одна основная ветка, в которой хранится текущая стабильная версия исходного кода. Когда разработчик хочет изменить этот код, он «откалывает» себе отдельную ветку от основной и работает в ней (паралельно). Когда работа закончена, он «вливает» изменения в основную ветку, чтобы его доработками смогли воспользоваться другие члены команды.
Использование VCS также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо дополнительных усилий.
1. Полная копия репозитория лежит у вас на машине.
- Чтобы создать репозиторий нужна всего одна команда — git init.
- Все файлы VCS хранятся только в одной папке .git. Никаких .svn в каждой директории.
- Вам не нужен постоянный и бесперебойный интернет. Утром — скачали данные с сервера к себе на машину, днем — поработали у себя, вечером — залили данные обратно на север. Проще, чем заливать каждый файл после изменения.
- В локальном репозитории вы можете создавать дополнительные ветки, тестировать что-то новое и делать все, что угодно. Никто не увидит этого, ведь репозиторий только ваш.
2. Контроль
- Удалить
- Изменить
- Поменять местами
- Объединить несколько коммитов в один
- Разделить один коммит на несколько
- Перетаскивать коммиты между ветками
3. Ветки
- Создать ветку, переключиться между ветками, слить ветки, удалить ветку — рутинные операции.
- За исключением релизных, ветки живут 1-3 дня. Создали ветку, написали новую функцию, протестировали, убедились, что все работает, слили с основной и удалили.
4. Коммиты
- Перед тем, как делать коммит, можно посмотреть и настроить, какие файлы в него попадут. Например, если вы хотите зафиксировать изменения только в одном файле из целого проекта — Git позволит вам это сделать.
- Вы можете занести в коммит только часть изменения в файле. А остальные изменения откатить, или положить в другой коммит.
- Просмотр истории коммитов и различий в файлах
- Можно посмотреть, какие изменения были внесены в файл в разных коммитах.
- Можно посмотреть историю коммитов всей ветки, чтобы проследить, как менялись файлы.
5. Stash
Например, коллега попросил вас срочно помочь ему с его работой, а у вас множество изменений в файлах, которые еще рано класть в коммит. Вы просто прописываете git stash, после чего переключаетесь на ветку коллеги и помогаете ему. Вам не придется создавать бесполезный коммит, только чтобы сохранить изменения в своих файлах, но при этом вы их и не потеряете при смене ветки.
6. Работа в команде
Очень удобно проводить ревью задачи, которая выполнена в отдельной ветке. Посмотреть различия коммитов, что-то исправить, прокомментировать, отправить обратно на доработку, а потом объединить отдельные коммиты и слить в основную ветку.
7. GitHub, BitBucket etc.
8. Основные понятия
| Название | Описание |
|---|---|
|
repository pепозиторий |
совокупность файлов, состояние которых отслеживается, и история их изменений. По факту, репозиторий — это проект, над которым ведется работа, и все изменения в этом проекте. Для отслеживания состояния файла его необходимо добавить в репозиторий. |
|
commit коммит |
сохраненное состояние (версия) файлов репозитория. |
|
branch ветка |
последовательность коммитов (история изменения состояния репозитория). Каждый коммит в ветке имеет «родителя» (parent commit) — коммит, на основе которого был получен текущий. В репозитории может быть несколько веток (в случаях, когда к одной версии репозитория применяется несколько независимых изменений). |
|
HEAD |
указатель на текущий коммит (указатель на состояние, в котором репозиторий находится на данный момент). |
|
master, main мастер |
основная ветка репозитория, создается автоматически при создании репозитория. |
|
merge мердж, слияние |
объединение двух или более веток. В процессе мерджа изменения с указанной ветки переносятся (копируются) в текущую. |
|
мерджа — целевая ветка |
ветка, изменения с которой объединяются с текущей веткой. |
|
merge base база слияния |
последний общий коммит двух веток. |
|
merge commit мердж коммит |
коммит, который создается автоматически по завершению процесса слияния веток. Мердж коммит содержит в себе все изменения целевой ветки мерджа, которые отсутствуют в текущей (все коммиты целевой ветки, которые начиная с базы слияния, но не включая её). |
|
fast-forward merge слияние перемоткой |
слияние веток, при котором в текущей ветке отсутствуют новые коммиты (последний коммит текущей ветки является базой слияния). При таком мердже текущая ветка просто переходит в состояние целевой ветки (указатель HEAD переносится на последний коммит целевой ветки). Мердж коммит при этом не создается. |
|
non fast-forward merge слияние без перемотки |
слияние, при котором новые коммиты (относительно базы слияния) присутствуют как в текущей, так и в целевой ветках. |
|
merge conflict мердж конфликт |
ситуация, когда при слиянии веток в один или несколько файлов вносились независимые изменения. В некоторых случаях (например, если изменялись разные, не пересекающиеся части одного файла) git способен самостоятельно решить, как выполнять слияние таких файлов. Если автоматически это сделать не удалось — возникает конфликт. В таком случае необходимо самостоятельно указать, как выполнять слияние конфликтующих версий (решить конфликт, resolve merge conflict). Изменения, внесенные в процессе решения конфликта автоматически попадают в мердж коммит. |
|
checkout чекаут |
переход на другое (существующее) состояние репозитория (на другой коммит или ветку). При этом все файлы в репозитории возвращаются в состояние, в котором они находились на момент указанного коммита. Если перед переходом в репозиторий были внесены изменения, которые были добавлены в репозиторий, но не попали в коммит — они будут перенесены «поверх» состояния после перехода. Как и при мердже, git попробует применить эти изменения к новому состоянию автоматически, при неудаче — возникает конфликт и изменения необходимо применить вручную. |
|
diff дифф |
разница двух состояний (коммитов, веток, подготовленных или модифицированных файлов). |
|
three-way diff трехсторонний дифф |
дифф, возникающий при мердже и решении конфликтов. Является разницей трех состояний: состояния репозитория в текущей ветке, состояния в целевой ветке слияния и общего состояния между этими ветками (состояния в базе слияния). |
|
cherry-pick черри-пик |
процесс добавления в текущую ветку одного (или нескольких) коммитов из другой ветки, без необходимости выполнять слияние веток. |
|
revert реверт |
отмена внесенных изменений (коммита или группы коммитов). В процессе реверта создается дополнительный коммит, который так же можно отменить при необходимости (вернув репозиторий в изначальное состояние). Реверт мердж коммита позволяет отменить выполненное ранее слияние веток. |
|
rebase ребейз |
перенос изменений текущей ветки «поверх» другой ветки. При этом все коммиты текущей ветки, которых нет в целевой, удаляются из текущей и заново создаются в целевой ветке (последовательно применяются к состоянию в целевой ветке). Поскольку ребейз пересоздает коммиты заново и меняет существующую историю, его использование не рекомендуется при командной разработке. Ребейз в ветке, над которой работает несколько человек, может привести к потере чужих изменений и/или невозможности корректно выполнить слияние. |
Объект FileSystemObject обеспечивает практически полный доступ к файловой системе Windows. Его конструктор имеет вид:\