Git для новичков

Лев Коваленко — Senior DS Engineer

Что такое Git?

Git — распределённая система управления версиями.

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

Git подходит для любых проектов, где нужно контролировать версии кода, управлять файлами данных и документацией проекта. В том числе подходит и для версионирования DS исследований, поэтому мы его с вами рассмотрим подробнее.

Для желающих потренироваться есть хороший тренажер

Структура git

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

Cтоит сразу оговориться, что ваш локальный репозиторий это каталог .git, где Git хранит метаданные и базу объектов вашего проекта. Это самая важная часть Git. Эти данные копируются при клонировании удаленного репозитория и при синхронизации с ним.

В чем разница между локальным и удаленным репозиторием? Локальный репозиторий находится только у вас и вы с ним можете делать все что угодно, он представляет собой копию удаленного репозитория. Удаленный репозиторий же находится на сервере и с ним могут взаимодействовать несколько человек. Кроме того, у удаленного репозитория есть ограничения на изменения, то есть напрямую что-то в нем менять не получится, вы можете только синхронизировать свой локальный репозиторий с ним.

В чем разница между локальным репозиторем и workspace? Локальный репозиторий — то папка .git, находящаяся в папке с вашим проектом. В ней хранится информация о репозитории и снимки версий файлов, которые вы делали. Workspace — это ваш рабочий каталог, то есть файлы вашего проекта, которые находятся под контролем версий git.

Как git версионирует?

Любая другая VCS

Git

Большинство систем контроля версий, с которыми вы так или иначе могли встречаться хранят информацию в виде списка изменений в файлах. Эти системы (CVS, Subversion и т. д.) представляют хранимую информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени (обычно это называют контролем версий, основанным на различиях).

Git же предлагает другой подход, он не хранит различия между версиями, а делает снимки вашего репозитория каждый раз когда вам нужно создать новую версию(коммит). Каждый раз, когда вы делаете коммит, то есть сохраняете состояние своего проекта в Git, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок. Для увеличения эффективности, если файлы не были изменены, Git не запоминает эти файлы вновь, а только создаёт ссылку на предыдущую версию идентичного файла, который уже сохранён. Git представляет свои данные как, скажем, поток снимков. Это делает Git больше похожим на миниатюрную файловую систему с удивительно мощными утилитами, надстроенными над ней, нежели просто на VCS.

Еще в гите есть техгология delta compression, которая по умолчанию не приенятется для закомиченных объектов. Объекты записываются в сжатом(но не delta) формате. Накопив большую историю изменений можно провести delta compression с помощью команды git gc --aggressive и у меньшить историю в разы. Наглядную демонстрацию вы найдете тут, а описание алгоритма тут.

Основные области в Git

У Git есть три основных области, в которых могут находиться ваши файлы: рабочая область, индекс(stage) и репозиторий (.git):

Рабочая копия(workspace) является снимком одной версии проекта. Эти файлы извлекаются из сжатой базы данных в каталоге Git и помещаются на диск, для того чтобы их можно было использовать или редактировать. В этой области вы можете удалять, изменять и создавать файлы и это никак не отразится на вашем репозитории.

Область индексирования — это файл, обычно находящийся в каталоге Git, в нём содержится информация о том, что попадёт в следующий коммит. Её техническое название на языке Git — «индекс», но фраза «область индексирования» также работает. Вы сами можете выбирать что попадет в индекс, а что нет, к тому же можете запретить добавлять gitу в индекс некоторые файлы прописав их в .gitignore. Все изменения файлов, удаленные и новые файлы изначально не добавлены в индекс, вам надо будет самим их добавлять.

Что такое репозиторий мы с вами уже проговорили.

Базовый подход в работе с Git выглядит так:

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

Ветвление в git

Еще один важный инструмент в гит это ветвление. Благодаря ветвлению как раз-так и можно организовать работу по различным методологиям. Сейчас мы попробуем разобраться, что же такое ветки в гите. Для начала нужно понять, что git благодаря принципу версионирования позволяет строит не цепочку изменений, а некоторое дерево изменений, то есть по сути каждый коммит может иметь более одного потомка. Для того что бы ориентироваться в путях этого дерева (последовательностях коммитов) в гите есть ветки, это некоторые названия/указатели/теги, которые ссылаются на последний коммит в определенной последовательности.

Таким образом гит позволяет работать разработчикам над одной и той же кодовой базе с минимум конфликтов в процессе разработки. Каждый разработчик может работать в своей ветке, складируя туда свои изменения.

Стоит еще сказать про названия веток на слайде. В гите есть основная ветка, ее называют master или main, от названия ничего особо не зависит, но в разных туториалах ее могут называть по разному. Так же есть HEAD - указатель на коммит в котором мы находимся.

Основные команды Git

Краткий перечень команд

Теперь рассмотрим основные команды, которыми вам приходилось пользоваться при работе с git.

У каждого разработчика есть локальный репозиторий, синхронизация репозиториев происходит с помощью push и fetch команд. Команда push позволяет отправить изменения из вашего локального репозитория в удаленный репозиторий, а fetch – подтянуть изменения с удаленного репозитория в ваш локальный, при этом не меняя ваше текущее рабочее пространство.

За добавление файла в индекс отвечает команда git add, а за фиксацию изменений в индексе – git commit. За объединение или сливание изменений из различных ветвей отвечает команда git merge, которая создает коммит с информацией о том как изменения были объединены.

Сравнить состояние workspace c индексом можно командой git diff, а с последним коммитом в локальном репозитории – git diff HEAD.

Откатиться на изменения в индексе или локальном репозитории можно командами checkout и checkout HEAD.

Команда pull позволяет подтягивать изменения с удаленного репозитория в локальный репозиторий и сразу применить полученные изменения в workspace, это последовательное применение команд fetch и merge.

В целом это основной набор команд, который вам пригодиться и ими вы чаще всего будете пользоваться при работе с git, теперь пройдемся по ним поподробнее.

Создание репозитория

Новый git repo

git init — инициализировать git репозиторий
git remote add <NAME> <URL> — добавить удаленный репозиторий

Существующий git repo

git clone <URL> — склонировать репозиторий
git clone <URL> <PATHNAME> — склонировать репозиторий в определенную директорию

Протоколы передачи для git:

FILE — мы имеем прямой доступ к файлам репозитория.
SSH — мы имеем доступ к файлам на сервере через ssh.
HTTP(S) — используем http в качестве приёма/передачи.

Если вы хотите инициализировать новый гит репозиторий в существующем проекте или в полностью пустом проекте, то вам понадобится первый столбец. Во первых вам нужно инициализировать гит репозиторий в проекте, во вторых создать и добавить удаленный репозиторий, с которым будет проводится синхронизация данных.

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

Так же небольшой, но важный момент насчет работы с удаленным репозиторием, у вас есть несколько протоколов для обмена данными с ним. Файловый протокол подойдет только если ваш удаленный репозиторий находится на той же машине где вы работаете и вся синхронизация будет проходить в рамках одной операционной системы. SSH или HTTPS подойдут для обмена данными с удаленными репозиториями в таких сервисах как github/gitlab/bitbucket и тд. Разница для разработчика между ними в том, что для синхронизации по https требуется вводить логин и пароль каждый раз или кешировать где-то их как обычный текст. SSH позволяет авторизироватся на сервисах с помощью связки публичный-приватный ключ, и вся авторизация происходит для разработчика незаметно. Много раз наблюдал проблему у коллег с авторизацией в github/gitlab по http, так что советую разобраться и настроить ssh подключение и использовать ssh url для работы с удаленным репозиторием.

Добавление изменений

git add <FILENAME> — добавить файл в индекс
git commit -m "<MESSAGE>" — зафиксировать изменения файла
git status — текущее состояние файлов в репозитории

Еще раз пройдемся по жизненному циклу файлов в гит. Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status. Он позволяет увидеть какие файлы:

находятся не в индексе, так называемые Untracked files
изменения файлов которые добавлены в индекс Changes to be committed
изменения которые еще не добавлены в индекс Changes not staged for commit

Собственно, что бы новые файлы или изменения существующих файлов вошли в индекс и были в дальнейшем закомичены есть команда git add <FILENAME>, вы можете написать git add ., но будьте осторожны в индекс будут добавлены все файлы в текущем каталоге, за исключением тех которые находятся в файле .gitignore, эти файлы git add будет игнорировать.

После того как вы добавили все нужные изменения в гит пришло время коммита, для этого вам пригодится команда git commit. Эта команда откроет выбранный вами текстовый редактор (по умолчанию nano или vi). в нем вы можете ввести свое сообщения для коммита, а так же увидеть вывод команды git diff, которая показывает какие изменения будут закомичены. В самом коммите в дальнейшем будет сохраняться только ваше сообщение. Что бы сразу указать сообщение в коммите используйте git commit -m

Работа с файлами

Удаление файлов

git rm <FILENAME> — удалить файл
git rm --cached <FILENAME> — удалить только из индекса

Перемещение файлов

git mv <FILE_FROM> <FILE_TO> — переместить/переименовать файл

Для того чтобы удалить файл из Git, вам необходимо удалить его из отслеживаемых файлов (точнее, удалить его из вашего индекса) а затем выполнить коммит. Это позволяет сделать команда git rm, которая также удаляет файл из вашего рабочего каталога, так что в следующий раз вы не увидите его как «неотслеживаемый».

Другая полезная штука, которую вы можете захотеть сделать — это удалить файл из индекса, оставив его при этом в рабочем каталоге. Другими словами, вы можете захотеть оставить файл на жёстком диске, но перестать отслеживать изменения в нём. Это особенно полезно, если вы забыли добавить что-то в файл .gitignore и по ошибке проиндексировали, например, большой файл с логами, или кучу промежуточных файлов данных. Чтобы сделать это, используйте опцию --cached.

В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован.Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.

Для того что бы переименовать файл стоит использовать команду git mv. Файл будет перемещен, а результат сразу проиндексирован. Как альтернатива вы можете сами перенести файл, добавить его в индекс и удалить предыдущий файл из индекса git rm.

Git неявно определяет, что произошло переименование, поэтому неважно, переименуете вы файл так или используя команду mv. Единственное отличие состоит лишь в том, что mv — одна команда вместо трёх — это функция для удобства. Важнее другое — вы можете использовать любой удобный способ для переименования файла, а затем воспользоваться командами add или rm перед коммитом.

Работа с ветками

Создание веток

git branch <NAME> — создать ветку

Переключение веток

git status — узнать текущую ветку
git checkout <NAME> — переключиться на ветку
git checkout -b <NAME> — создать и переключиться на ветку
git switch <NAME> — переключиться на ветку
git switch -c <NAME> — создать и переключиться на ветку
git switch - — вернуться к предыдущей извлечённой ветке

Мы чуть-чуть поговорили про ветвление, про то что история изменений в гит, это некоторый граф. Теперь рассмотрим основные команды для работы с ветками. Для того что бы создать ветку нужно исполнить команду git branch <NAME>. При исполнении этой команды гит создает новый указатель указывающий на текущий коммит.

Ветка в Git — это простой файл, содержащий 40 символов контрольной суммы SHA-1 коммита, на который она указывает; поэтому операции с ветками являются дешёвыми с точки зрения потребления ресурсов или времени. Создание новой ветки в Git происходит так же быстро и просто как запись 41 байта в файл (40 знаков и перевод строки).

Как гит понимает в какой ветке вы находитесь? Ранее я уже говорил про указатель HEAD, так вот если вы находитесь в ветке, то HEAD будет указывать на указатель текущей ветки, который указывает на последний коммит в этой ветке. Что бы посмотреть текущую ветку можно выполнить команду git status и увидеть текущую ветку, а так же изменения от последнего коммита.

Команда git branch только создаёт новую ветку, но не переключает на неё. Для переключения на существующую ветку выполните команду git checkout <NAME>. В результате HEAD будет указывать на вашу новую ветку, то есть при переключении веток, изменится только указатель HEAD. Сейчас у git разрабатывается новый синтаксис и альтернативой git checkout стала команда git switch, но функционал переключения веток у этих команд одинаковый.

Важно запомнить, что при переключении веток в Git происходит изменение файлов в рабочем каталоге. Если вы переключаетесь на старую ветку, то рабочий каталог будет выглядеть так же, как выглядел на момент последнего коммита в ту ветку. Если Git по каким-то причинам не может этого сделать — он не позволит вам переключиться вообще.

Объединение веток

git merge <BRANCH> — влить изменения из ветки BRANCH в текущую
git merge --ff <BRANCH> — “быстро перемотать” текущую ветку на BRANCH, если BRANCH - продолжение текущей ветки
git merge --no-ff <BRANCH> — создать коммит слияния ветки BRANCH в текущую
git merge --ff-only <BRANCH> — “быстро перемотать” текущую ветку на BRANCH по возможности

Сейчас начнем важную тему слияния веток. Так как зачастую над проектом вы работаете не один, то так или иначе вам придется объединять свои наработки с чужими. Иногда у вас будут возникать конфликты, но сначала разберем как вообще можно объединить ветки. В кратком перечне команд проскакивала такая команда git merge которая позволяет объединять ветки, то есть из какой-то ветки branch перенести изменения в текущую. Нужно знать уть-чуть про ее особенности, если новая ветка является прямым продолжением текущей ветки, то гит применит так называемую быструю перемотку — fast-forward — которая переключит указатель текущей ветки на указатель вливаемой ветки.

Если же вливаема ветка не является продолжением ветки, то произойдет слияние посредствам нового коммита, то есть будет записан объединяющий коммит, то есть команда сработает с аргументом --no-ff, вместо --ff. Так как коммит, на котором мы находимся, не является прямым родителем ветки, с которой мы выполняем слияние, Git придётся немного потрудиться. В этом случае Git выполняет простое трёхстороннее слияние, используя последние коммиты объединяемых веток и общего для них родительского коммита.Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый результирующий снимок трёхстороннего слияния, а затем автоматически делает коммит. Этот особый коммит называют коммитом слияния, так как у него более одного предка.

Но иногда при слиянии бывают конфликты, давайте разберем их.

Конфликты

Иногда процесс не проходит гладко. Если вы изменили одну и ту же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить и сообщит о наличие конфликта. Вам самим придется их разрешать. Всё, где есть неразрешённые конфликты слияния, перечисляется как неслитое. В конфликтующие файлы Git добавляет специальные маркеры конфликтов, чтобы вы могли исправить их вручную.

Вы можете решить их в ручную, изменив выделенные гитом части и объединить их между собой, либо воспользоваться git mergetool предварительно настроив конфигурацию гита, например в vscode есть прекрасный инструмент для разрешения конфликтов.

Работа с удаленными ветками

git remote show <remote> — получить список удаленных веток
<remote>/<branch> — название ветки слежения
git fetch <remote> — синхронизация вашего локального репозитория с удалённым
git push <remote> <branch> — отправить изменения в удаленный репозиторий в ветку <branch>
git push <remote> <branch>:<other branch> — отправить изменения из ветки <branch> в удаленный репозиторий в ветку <other branch>
git checkout -b <branch> <remote>/<branch> — подтянуть новую удаленную ветку в локальный репозиторий
git checkout --track <remote>/<branch> — подтянуть новую удаленную ветку в локальный репозиторий
git pull — получить изменения в текущую ветку из удаленной (при наличии ветки слежения)
git pull <remote> <branch> — получить изменения в текущую ветку из удаленной ветки <branch>

Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее.

Ветки слежения — это ссылки на определённое состояние удалённых веток. Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удалённым репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.

Для синхронизации вашего локального репозитория с удалённым сервером выполните команду git fetch <remote>. Эта команда извлекает с удаленного гит репозитория данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатели <remote>/<branch> на новую позицию.

Когда вы хотите поделиться веткой, вам необходимо отправить её на удалённый сервер, где у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными при отправке — вам нужно явно указать те ветки, которые вы хотите отправить. Выполните команду git push <remote> <branch>

Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется upstream branch). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull, то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния, он выполнит сначала git fetch, а затем git merge, если возможно то fast forward. Если указать для git pull конкретную ветку в удаленном репозитории, отличную от текущей, например вы хотите подтянуть мастер, то он также сначала сделает git fetch, а затем git merge. То есть по сути это некоторое сокращение команд для получения обновлений с удаленного репозитория. Так же можно настроить конфигурацию git pull и выбрать одну из трех стратегий:

git config pull.rebase false # merge (the default strategy)
git config pull.rebase true # rebase
git config pull.ff only # fast-forward only

Просмотр истории изменений

git log — показать всю историю изменений
git log -p -2 — показать историю изменений с патчами
git log --stat — показать историю изменений со статистикой
git log --pretty=oneline — показать каждый коммит в одну строку
git log --pretty=oneline" --graph — показать историю изменений в виде ASCII графа
git log -S <function_name> — показать коммиты где была добавлена или удалена строка
git log -- <path/to/file> — показать коммиты где менялся только этот файл

После того, как вы создали несколько коммитов или же клонировали репозиторий с уже существующей историей коммитов, вероятно вам понадобится возможность посмотреть что было сделано — историю коммитов. Одним из основных и наиболее мощных инструментов для этого является команда git log. По умолчанию (без аргументов) git log перечисляет коммиты, сделанные в репозитории в обратном к хронологическому порядке — последние коммиты находятся вверху.

Одним из самых полезных аргументов является -p или --patch, который показывает разницу (выводит патч), внесённую в каждый коммит. Так же вы можете ограничить количество записей в выводе команды; используйте параметр -2 для вывода только двух записей. Так же есть возможность использовать серию опций для обобщения. Например, если вы хотите увидеть сокращённую статистику для каждого коммита, вы можете использовать опцию --stat

Следующей действительно полезной опцией является --pretty. Эта опция меняет формат вывода. Существует несколько встроенных вариантов отображения. Опция oneline выводит каждый коммит в одну строку, что может быть очень удобным если вы просматриваете большое количество коммитов. К тому же, опции short, full и fuller делают вывод приблизительно в том же формате, но с меньшим или большим количеством информации соответственно. Так же можно добавить опцию --graph что бы отобразить все в виде ASCII графа.

Есть еще опция -S, которая принимает аргумент в виде строки и показывает только те коммиты, в которых изменение в коде повлекло за собой добавление или удаление этой строки. Например, если вы хотите найти последний коммит, который добавил или удалил вызов определённой функции, вы можете запустить команду git log -S <function_name>. Если вы укажете каталог или имя файла, вы ограничите вывод только теми коммитами, в которых были изменения этих файлов. Эта опция всегда указывается последней после двойного тире (--), чтобы отделить пути от опций.