Что такое репозиторий и для чего он нужен
Гит-словарик для начинающих программистов
Мёржим бранчи и коммитим реквесты
Мы часто упоминаем Git — способ организации хранения и контроля версий файлов в рабочем проекте. Сегодня расскажем о странных словах: «бранч», «коммит», «пулл-реквест» и об остальных понятиях в гите.
О чём речь
Гит — это такой способ хранения файлов и их версий. Гит позволяет смотреть историю изменений файлов, кто какие дополнения и когда вносил, как развивался проект, кто что в него добавлял и почему.
Главная особенность гита — он помнит всё, что вы в него внесли, и может показать, какие именно строчки вы правили несколько лет назад, когда чинили ошибку авторизации, например.
На базе гита есть сервис «Гитхаб». Работает так:
Это полезно, например, когда несколько человек параллельно пилят совместный проект. Каждый работает над своим файлом или даже своим куском одного файла. Всю работу авторы синхронизируют между собой: чтобы не было ситуации, что два человека редактируют один и тот же файл, а потом затирают результаты работы друг друга, сами того не зная.
Это если вкратце. Теперь будут подробности.
Что такое репозиторий (git repository)
Гит-репозиторий — это облачное хранение вашего проекта на сервере (например, на сервере Гитхаба, но можно и на другом).
У каждого программиста может быть сколько угодно репозиториев, по одному на каждый проект. А можно вести все проекты в одном репозитории, но тогда это превратится в мешанину. Но каждый имеет право на мешанину.
В репозитории могут храниться:
Что такое бранч (git branch)
Бранч — это ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект.
В гит-репозитории всегда есть как минимум один бранч, который называется master. Если не создавать других веток, то все изменения будут сразу идти в главную ветку проекта. Для очень маленьких или учебных проектов это терпимо, но в любом коммерческом коде поступают иначе: создают ветки.
Дело в том, что ветка master используется для выпуска новых версий проекта, которые будут доступны всем. То, что добавляется в мастер-бранч, сразу становится доступно пользователям.
Но представьте такую ситуацию: мы только что запустили сайт для заказчика и он срочно хочет добавить интерактивный раздел со скидками. Можно сделать так: править рабочие файлы проекта «по живому», чтобы сразу видеть результат. А можно сделать из мастера отдельную ветку news и работать уже в ней (и это очень похоже на форк). В этом случае мы получим полную копию проекта, в которую можно вносить любые правки и они никак не повлияют на запущенный сайт. Мы в этой ветке пилим всё, что нужно клиенту, показываем ему результат на секретном сайте, а потом объединяем её с мастером. Это называется «смёржить бранчи».
Что такое клонирование (git clone)
Клонирование — это когда вы копируете репозиторий себе на жёсткий диск. Это нужно, чтобы начать в нём что-то менять.
Чем это отличается от простого копирования: когда вы клонируете репозиторий, вместе с файлами вашего проекта вы также тянете всю историю версий, все ветки, всю историю работы. И если кто-то дальше будет вносить изменения в проект, благодаря этим данным вы сможете тоже их получить.
А если просто скопировать нужные файлы с чужого компьютера, то никаких историй и никаких связей не сохранится. Синхронизации не будет. Просто какие-то файлы.
Что значит «смёржить» (git merge)
Смёржить (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки.
Получается, что схема работает так:
Что такое коммит (git commit)
Программировать только в облаке неудобно — проще скачать себе на компьютер весь проект и писать код на своей машине. Но чтобы правки увидели остальные, их нужно отправить обратно в репозиторий. Это и есть коммит.
Коммитить можно и один файл, и сразу несколько. Система сама найдёт, что изменилось в каждом файле, и добавит эти изменения в проект. Но все эти правки внесутся в репозиторий за один раз, потому что при коммите обрабатываются сразу все добавленные в список файлы.
Например, вы изменили файл главной страницы index.html и добавили его в список файлов текущего коммита. Теперь его можно отправить на сервер, а можно ещё поправить сразу style.css и внести в этот же коммит. Системе всё равно, сколько файлов обрабатывать, поэтому как и что коммитить — решает программист.
Единственное требование к коммитам — указывать, что именно вы поменяли в проекте, человеческим языком. Хорошим тоном и правильным подходом считается писать, что именно вы изменили: «Добавил цвет и стили основной кнопки», «Убрали метод вызова старого API», «Сделали рефакторинг функции SetOutOfDate()». Это описание будут читать другие разработчики.
Коммитить можно хоть после правки каждой строчки — весь вопрос в том, насколько нужна такая детализация в проекте. Но иногда и изменения из одной строчки можно закоммитить, если оно действительно важное.
Что такое пуш и пулл (git push, git pull)
Чтобы отправить данные из своего проекта на сервер, используют gut push. Для этого программист указывает имя ветки, в которую хочет отправить свой код, а сервер их принимает, проверяет и добавляет к себе.
Иногда бывает так, что сервер отказывается это сделать, потому что у программиста на компьютере была неактуальная ветка. За то время, пока он писал свои правки, другие программисты сделали несколько изменений, закоммитили их у себя и отправили на сервер. Получилось, что у одних эта ветка осталась свежей и актуальной, а у других она устарела. Чтобы не принимать запросы из устаревших веток, гитхаб просит сначала обновить данные у себя на комьютере с помощью git pull.
Пулл работает просто: он скачивает с сервера актуальную версию ветки и добавляет код оттуда вам на компьютер. Иногда этот код вступает в противоречие с тем, что уже успел сделать программист, и тогда возникает конфликт — нужно принять решение, какая версия одинакового кода останется в проекте, а что нужно будет убрать.
Чем коммит отличается от пуша
Коммит — это когда вы фиксируете изменения в проекте, как бы подводите итог своей работе.
Пуш — это когда вы отправляете сделанную работу туда, где хранится копия вашего кода.
Получается, последовательность действий такая:
Что дальше
Чтобы все эти бранчи и реквесты стали понятнее, в следующий раз сделаем вот что: заведём учебный проект на Гитхабе и будем работать с ним так, как делают настоящие программисты.
Git для новичков (часть 1)
Что такое Git и зачем он нужен?
С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.
Так же ваши репозитории можно хранить и в интернете. Обычно для этого используют три сервиса:
Как работает
В итоге получается очень простой граф, состоящий из одной ветки ( main ) и четырех commit. Все это может превратиться в более сложный граф, состоящий из нескольких веток, которые сливаются в одну.
Об этом мы поговорим в следующих статьях. Для начала разберем работу с одной веткой.
Установка
Основой интерфейс для работы с Git-ом является консоль/терминал. Это не совсем удобно, тем более для новичков, поэтому предлагаю поставить дополнительную программу с графическим интерфейсом (кнопками, графиками и т.д.). О них я расскажу чуть позже.
Но для начала, все же установим сам Git.
Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.
Для Mac OS. Открываем терминал и пишем:
Linux. Открываем терминал и вводим следующую команду.
Настройка
Вы установили себе Git и можете им пользоваться. Давайте теперь его настроим, чтобы когда вы создавали commit, указывался автор, кто его создал.
Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.
Создание репозитория
Теперь вы готовы к работе с Git локально на компьютере.
Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.
Теперь Git отслеживает изменения файлов вашего проекта. Но, так как вы только создали репозиторий в нем нет вашего кода. Для этого необходимо создать commit.
Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.
Процесс работы с Git
Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:
Создан новый функционал
Добавлен новый блок на верстке
Исправлены ошибки по коду
Вы завершили рабочий день и хотите сохранить код
Это поможет держать вашу ветки в чистоте и порядке. Тем самым, вы будете видеть историю изменений по каждому нововведению в вашем проекте, а не по каждому файлу.
Визуальный интерфейс
Как я и говорил ранее, существуют дополнительные программы для облегчения использования Git. Некоторые текстовые редакторы или полноценные среды разработки уже включают в себя вспомогательный интерфейс для работы с ним.
Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:
Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.
Создаем свой первый проект и выкладываем на GitHub
Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).
Перед началом предлагаю зарегистрироваться на GitHub.
Создайте папку, где будет храниться ваш проект. Если такая папка уже есть, то создавать новую не надо.
Установите себе дополнительно анализаторы кода для JavaScript и PHP
Откройте вашу папку, которую создали ранее
После этого у вас появится вот такой интерфейс
Здесь будут располагаться все файлы вашего проекта
Здесь можно работать с Git-ом
Кнопка для создания нового файла
Кнопка для создания новой папки
Давайте теперь перейдем во вкладу для работы с Git-ом.
Откроется вот такое окно:
Кнопка для публикации нашего проекта на GitHub
Вы создали и опубликовали репозиторий на GitHub.
Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.
Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:
Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки
Добавляем наш файл для будущего commit
Отправляем наш commit в GitHub
Поздравляю, вы научились создавать commit и отправлять его в GitHub!
Это первая вводная статья по утилите Git. Здесь мы рассмотрели:
Как его устанавливать
Как его настраивать
Как инициализировать репозиторий и создать commit через консоль
Как на примере VS Code, опубликовать свой код на GitHub
Забегая вперед, советую вам погуглить, как работают следующие команды:
P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.
Kodomo
Репозитории
конфликты – они в головах, а не в репозиториях
В прошлый раз мы работали в командной строке и я всячески пресекал попытки сохранять команды в файле, править файл и исполнять команды оттуда.
Я делал это затем, чтобы прежде, чем вы станете писать программы и сохранять их на диске, я хочу вас познакомить с понятием «репозиторий» и научить с ним работать.
Что такое репозиторий и зачем он нужен
Репозиторий – это хранилище файлов, в котором кроме самих файлов хранится ещё и всякая полезная всячина: прежние версии каждого файла, комментарии к каждому изменению и заметка, кто это изменение внёс. Кроме того, репозиторий отвечает за обмен свежими версиями между соавторами проекта.
Зачем он может понадобиться вам? (За исключением того, что я буду требовать, чтобы все плоды вашего труда в рамках моего курса хранились в репозиториях)
Пример. Вы пишете курсовую работу. Вы написали две трети, пришёл научный руководитель, и сказал: «что за ерунда? всё переписать!». Вы переписали снова две трети, пришёл научный руководитель, и сказал: «а в прошлой-то версии 2-я глава была лучше». И тогда вы начинаете сохранять рядом кучу файликов, то ли пронумерованных цифирками, то ли датами. И не дай боже вам приходит в голову идея прежде, чем переносить изменение из прошлой версии в новую, исправить что-то на месте в старой версии – и оказывается у вас несколько файлов, про которые у вас и только у вас имеется в голове тайное знание, где хранится наиболее свежий вариант чего.
Второй пример. Собрались вы в соавторстве с кем-нибудь писать работу. Разделили ответственность: я пишу первую половину, ты – вторую. Написали, склеили – плохо читается. Потом вам соавтор пишет (спутся два дня – а вы как раз только обнаружили кучу опечаток и правите их), что он сделал всё хорошо – и вот результирующий текст. Пристальный просмотр выявляет, что текст-то может и лучше, а всё те же опечатки во всё тех же местах остались. Ещё более пристальный просмотр выявляет, что вы таки не поняли, что же таки соавтор поправил и вы идёте с ним выянять, которые из 200 страниц вам надо перечитывать на тему улучшений.
В каждом из этих случаев репозиторий мог бы несколько облегчить работу (но, разумеется, лишь взяв на себя то, что очевидно даже глупому компьютеру).
Работа в darcs
Для работы в репозитории нужно уметь: создавать репозиторий, записывать в него изменения, обмениваться изменениями между репозиториями. Очень полезно также уметь изучать содержимое, но это я оставляю на самостоятельное изучение (так как самостоятельно такие вещи учатся легко при наличии достаточного любопытства).
Создание репозитория
Итак, создавать репозиторий можно двумя способами, создать пустой репозиторий:
или присоединиться к чужому репозиторию:
внутри репозитория лежит папочка _darcs, в которой, собственно, и хранится вся история проекта, настройки, и прочая служебная-вспомогательная ерунда. Не трогайте эту папочку почём зря.
Запись изменений
Теперь, предположим, мы хотим создать в репозитории новый текстовый файл. (Важное замечание: вообще, в репозитории лучше хранить именно текстовые файлы. К ним относятся что обычные тексты, набранные, например, в FAR, что исходные коды программ большинства языков программирования. А вот файлы word к ним не относятся – их, конечно, тоже можно хранить в репозитории, но толку от этого будет уже не ощутимо больше, чем от того, чтобы просто хранить отдельными нумерованными файлами старые версии и приписывать к ним руками комментарии, что где поменялось).
Командочка cat к darcs не имеет никакого отношения. Она выводит на экран содержимое файла. Привожу я её здесь, чтобы показать, в каком состоянии находится проект в тот момент, когда мы начинаем работать с darcs.
Команда darcs add hello.txt говорит darcs о том, что отныне он должен следить за изменениями ещё и в файле hello.txt. При этом в истории изменений с точки зрения репозитория файл hello.txt ещё не появился.
Команда darcs record hello.txt (сокращается до darcs rec) говорит darcs записать некоторые из изменений, случившихся с файлом hello.txt в историю внутри репозитория. Вспоминаем, что одно из главных назначений репозитория – вспомнить потом, где нужно искать нужный фрагмент текста, или же сообщить соавтору, что изменилось, чтобы он понимал, что с этим делать. При записи изменений нужно сопроводить изменение комментарием. Комментарий должен быть достаточно короткий, описывать суть изменения полностью, и быть достаточно специфичным («очередная запись в репозиторий» – это короткое и полное описание, но оно недостаточно специфично, из него нельзя понять, что же именно произошло).
И тут мы заметили, что в содержимом у нас опечатка!
Очень полезная (на мой вкус) команда darcs whatsnew (сокращается до darcs wh) сообщает, что изменилось в рабочей директории по сравнению с последним записанным изменением.
Командочка darcs changes выдаёт то, как увидят ваши правки в первую очередь ваши соавторы. Да и вы, когда будете искать прежнюю версию, тоже будете смотреть именно сюда, чтобы выяснять, в какой именно версии затерялись полезные строчки. (Или просто ностальгии ради).
И так далее. Всё, что нужно для работы в репозитории в-одиночку – это команда darcs record и изредка darcs add. Добавьте команд по чтению истории по вкусу, – и вы получили ответ на первый вопрос – как хранить хронологию изменений к чему-нибудь (тексту или программе).
Обмен изменениями между репозиториями (и соавторами)
Наконец, третья группа команд – обмен изменениями между репозиториями. Предположим, что вы создали репозиторий с помощью darcs get (тогда darcs уже знает, откуда он его получил, и ему не нужно подсказывать, куда отправлять ваши изменения).
Команда darcs push отправляет все записанные изменения туда же, откуда вы скачали репозиторий.
Команда darcs pull вытягивает в локальный репозиторий изменения, которые сделал соавтор. Казалось бы, досадно удалять файл, на который вы с соавтором потратили два дня – но помните, в каждом из вашего репозитория и репозитория соавтора хранится вся история его изменений, а значит, и, например, последнюю его версию вытащить из репозитория не проблема (как? читайте документацию!). darcs record увидит удаление файла как два изменения: сначала вы стёрли в файле каждую строку, и лишь потом сказали darcs удалить сам файл. Когда ваш коллега скажет darcs pull, файл hello.txt у него в рабочей директории исчезнет (а история и возможность отменить удаление файла останутся).
Тут всё было бы хорошо, если бы все соавторы работали по очереди. (Только тогда вопрос, а зачем и репозиторий то был бы нужен, так можно было бы и просто дисциплину между собой устроить и файлы пересылать с наказом «не думай (дабы не потерять умную мысль), пока к тебе не придёт последняя версия файла»). В жизни может так случиться, что два автора одновременно поправят в одном и том же файле одно и то же место. Такая ситуация называется «конфликт», и поступает в таком случае репозиторий следующим образом: тому, кто первым наткнётся на такое противоречие он сообщит, что случился конфликт, разметит, где случился конфликт, и предложит решить, что с этим делать.
Конфликты бывают двух видов: конфликт между свежевыкаченным и рабочей директорией (незаписанным в репозиторий), и конфликт между двумя записанными изменениями, когда они попадают в общий репозиторий.
Первый тип конфликтов хороший. Если он случился (а случиться он может только во время darcs pull), то darcs вам разметит в том файле, который вы вот сейчас прямо редактируете стрелочками и звёздочками фрагмент файла, в котором хранится версия вашего соавтора и соответствующий ему кусок в том же месте, который только что написали вы. darcs whatsnew очень полезна в этом случае, чтобы увидеть эти стрелочки и понять, где же именно находится конфликт. Чтобы его разрешить, нужно посмотреть на получившиеся две версии и собрать из них одну осмысленную – тут совет один: полагаться на здравый смысл. Важно (/!\): darcs record этих самых стрелочек да чёрточек, которыми darcs разметил конфликт, увидеть не должен (это должно следовать очевидным образом из того же здравого смысла; если оно не следует из здравого смысла, подуймайте снова и выберите себе более подходящий здравый смысл для ситуации).
Второй тип конфликтов (если ими изрядно увлечься) может выцепить в теории, на которой строится darcs, слабое место. Тогда могут возникнуть проблемы с работоспособностью и производительностью darcs. Правду скажу: я всегда опасаюсь конфликтов второго типа и делаю всё, чтобы их не случилось. Впрочем, когда в ситуациях из реальной жизни они случаются, оказывается чаще, что их легко разрешить, точно так же, как и конфликты первого рода.
Как избегать второго типа конфликтов? Нужно придерживаться достаточно строгой дисциплины работы с репозиторием: всегда перед record и push делать pull, притом желательно тратить поменьше времени на record (дабы другой соавтор влезть не успел и всё попортить):
Документация
Прекрасное руководство по darcs на английском языке обитает тут: http://darcs.net/manual (оно меняется вслед за версиями darcs – сейчас оно соответствует той версии, которая установлена на kodomo и kodomo-count).
Судя по всему, русская документация, какая была, канула в лету с обновлением сайта darcs.net.
Если у вас не уложилось в голове, зачем нужен репозиторий и как им пользоваться, то это лечится всё-таки только практикой, а по мелочи подглядывать уж, я надеюсь, каждый из вас осилит и английскую документацию (не верю я, что среди вас есть люди, которые всегда заранее знают, что из плодов собственного труда можно стирать, а что лучше оставить – и только такие люди могли бы говорить, что репозитории им не нужны). Если же вы всё-таки хотите что-то ещё про darcs прочитать по-русски, то в прошлом году я писал тексик, аналогичный этому, но с другими акцентами: как пользоваться darcs.
Полезные добавки
Полезные замечания для тех, кто ленится читать help или хотя бы контекстную помощь в диалогах с darcs:
Почти во всех диалогах с darcs есть варианты ответов y – yes, n – no, a – yes to all
Команды record, push, pull и многие другие принимают флаг -a, который означает то же самое, что если бы вы сказали «a» (yes to all) в первом же диалоге команды
У команды record есть параметр -m "change description". Если он указан, record не будет спрашивать описание изменения.
Большинству команд можно (например, darcs whatsnew) давать в качестве аргумента список файлов, тогда они будут делать то же, что и обычно, но ограничивать свой интерес только перечисленными файлами.
Историческая демагогия (наверное, близкая к исторической справке)
Видимо, история репозиториев начинается с создания команд diff и patch (живых и активно используемых и поныне), первая из которых умела сравнивать два файла (старый и новый) и выдавать построчные различия между ними – соучастник проекта правил какой-нибудь файл, делал diff между старой и новой версией и слал автору проекта с комментарием, что он исправил. Автор проекта использовал patch и менял старый файл так, чтобы он совпадал с тем, как оно было у соучастника. Командочки diff и patch возникли на заре UNIX (если не раньше) и им много больше лет, чем каждому из нас или вас.
Следующей возникла командочка rcs (Revision Control System), которая умела хранить историю изменений одного файла в соеднем файлике в виде последовательностей тех самых diff’ов с комментариями и датами.
Сильно позже и этой командочки стало не хватать, и возник монстр под названием CVS (Concurrent Versioning System), который являлся обвязкой к rcs, и был, в сущности полноценной системой контроля версий, в которую с каждым годом запихивали коленкой каждую новую идею, которая казалась авторам полезной.
Долгое время именно CVS являлся стандартом для совместной разработки программ, но у него было несколько неприятностей: он обязательно требовал наличия «администратора репозитория» в проекте, он был довольно сложен, и для некоторых задач его возможностей не хватало.
Где-то годах в 90-х оказалось довольно много способных программистов, которые видели эти недостатки и пытались их решать. Тогда появились проекты: SVN (subversion), GNU Arch (tla), darcs, mercury, bazaar, git и пр. Имя им легион.
Я рассказываю вам про darcs, как репозиторий, с которым проще всего (на мой субъективный вкус) работать. Darcs возник из курсовой, а затем аспирантской (точнее, ph.d.) работы физика David Roundy на тему «теория патчей».
С другой стороны, самый популярный среди программистов репозиторий сейчас git, который умеет всё то же, что и darcs (и много больше – чем сторонники git хвастаются – но нужно ли оно на самом деле?), но чтобы работать с git, нужно освоить существенно больше теории (о том, как git устроен). Впрочем, переходить с darcs на git, как правило, оказывается тоже довольно просто.