GitHub: Что это такое и зачем?

2021-03-21

Рассмотрим тут решение одной из самых популярных задач - “как опубликовать файлы в интернет?”.

Почему может возникнуть такой вопрос? Например вы писатель и у вас есть знакомый редактор, который хотел бы вам помочь в написании книги. В этом случае кончено самым эффективным решением было бы встретится с ним лично. Вы, ваша рукопись и редактор читаете её вместе и решаете все проблемы.

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

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

По этим причинам обсуждения происходит не в режиме реального времени. Редактура происходит параллельно с написанием новых глав и личное присутствие помогает лишь на этапе обсуждения правок.

Поэтому было бы здорово что бы рукописи были доступны редактору по мере их готовности. Тоже самое со стороны писателя было бы здорово чтобы он мог видеть все замечания редактора по мере их появления и они могли обсудить конкретную строку конкретную правку. Именно это и позволяет достичь публикация файлов/рукописей в интернет.

Написание книги, работа с редактором это во многом очень похоже на то чем занимаются профессиональные программисты каждый день. Поэтому они создали множество инструментов для облегчения совместной работы друг с другом. Самый популярный и бесплатный инструмент сегодня на рынке это GitHub .

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

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

Так как тут мы имеем дело с файловой системой, а не с интернет ресурсом то тут возникают сложности с тем, что разные операционные системы работают с программами по разному. Но основная идея в том, что существует специальный тип программ, которые называют " системами контроля версии “, которые в свою очередь позволяют решать обозначенную тут задачу и не только ее. На самом деле это очень мощный инструмент для работы с файлами.

Я буду использовать одну - самую популярную программу этого типа. Она называется git. Эта программа доступна практически под все известные операционные системы. Официальный сайт этой программы https://git-scm.com/ . Эта система хороша тем, что задумана работать длительное время без соединения с интернетом. То есть чтобы работать с git, после ее установки, вам в принципе не нужно иметь подключение к интернету и сети. Сеть понадобится только в момент когда нужно будет опубликовать что либо или передать состояние своей папки по сети.

Относительно git существует очень популярное заблуждение, что эта программа была создана сервисом GitHub и является просто “клиентом” - способом работы с этим сервисом. На самом деле все наоборот! Git это программа которая была создана за долго до GitHub. Сам же web сервис предоставляет “удобный” бесплатный хостинг, обмен данных с которым осуществляется с использованием git. Так что выходит, что git довольно самостоятельная программа, которая завоевала большую популярность среди конкурентов и всяческие сервисы в стиле GitHub, GitLab, BitBucket используют ее чтобы предоставлять свои услуги.

На самом деле о git и о " системах контроля версий " можно говорить довольно много, задача " писателя и редактора " обозначенная тут решается при помощи git и GitHub. Git - является программой которую можно установить на компьютер, а GitHub это web сервис который умеет принимать данные отправляемые этой программой, а так же GitHub это своего рода социальная сеть, где люди могут комментировать файлы и код друг друга, что и требуется по условиям задачи.

Поскольку большинство читателей этого блога пользуется windows я попробую на примере этой операционной системы опубликовать очередную web страничку, но теперь уже используя не web интерфейс как это это было ранее, а с помощью GitHub Desktop

GitHub Desktop установка

Эта программа доступна для скачивания по адресу https://desktop.github.com/ обратите внимание что это субдомен GitHub это говорит о том, что эту программу поддерживают те же самые люди, что и GitHub.

Затем запускаем скачанную программу

1. Используем залогин из предидущего шага. 2. Продолжаем

Проект “страничка”

Теперь отложим в сторону “GitHub Desktop”, и создадим простенький сайт в своем любимом текстовом редакторе, я буду использовать VisuaStudioCode

Выделяем папку (1) и открываем ее в редакторе (2)

Создаем новый файл и называем его index.html

По аналогии создаем и заполняем style.css

Публикация - автор

Теперь когда у нас есть папка с проектом его наконец можно опубликовать

Выбираем опцию создать новый репозиторий

Заполняем название репозитория - имя которое будет видно в GitHub а так же это будет название папки в которой лежит проект (1) и описание проекта тоже будет там доступно (2) Затем выбираем папку где находится свеже созданная папка проекта

Выбираем папку в которой находится созданная папка helloGitHub

Теперь все готово к созданию репозитория в нужной папке, нажимаем на кнопку создать репозиторий

После не большого ожидание можно увидеть экран репозитория.

В нижнем левом углу (1) видно, что GitHub Desktop уже создал за вас первый коммит и все что осталось только сделать это опубликовать его в интернете кнопкой “опубликовать” (2)

Если нажать на кнопку история(1) можно убедиться, какие файлы (2) были добавлены в первом коммите

Теперь нужно ввести название под которым он будет опубликован наружу (1). Описание (2) оба этих поля пред заполнены на основе данных введенных при создании репозитория. Галка (3) позволяет опубликовать репозиторий только для “своих” то есть его будет видеть не все пользователи GitHub а только те которым вы дадите доступ. “Было бы классно, что бы все репозитории были такими” - подумаете вы, но это понимают и владельцы GitHub по этому количество приватных - “скрытых” репозиториев ограничено, чтобы создавать их много вам придется заплатить за эту услугу. По этому я рекомендую делать все репозитории на GitHub публичными, а для приватных есть и другие сервисы.

Далее нажимаем на кнопку публикации (4) и наблюдаем как на самом web сервисе GitHub появляется новый репозиторий

С теми самыми файлами с локального диска

С этого момента вы можете воспользоваться сервисом GitHub Pages, о котором я писал в конце статьи ранее .

Все это повествование выше актуально для писателя, он выложил свою рукопись теперь посмотрим, что же должен сделать редактор, чтобы предложить свою правку

Редактура - редактор

Редактор должен забрать тексты себе на компьютер, что бы ему было удобно работать в своем текстовом редакторе

Если же у него уже есть репозитории он сможет сделать это через меню

Далее нужно получить у писателя его логин на GitHub и название репозитория и ввести его в форму (1) затем в форме 2 указать куда положить данные из этого репозитория и затем нажать на кнопку клонирования

Далее внесем правки как редактор в один из файлов пусть для примера это будет style.css

Далее изображения представлены из операционной системы MacOS как можно заметить различия минимальны, в плане того как выглядит сама программа GitHub Desktop.

GitHub Desktop сразу замечает правки в файле style.css и предлагает сделать коммит с коротким описанием Update style.css и пустым длинным описанием.

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

Редактору предлагают сделать fork, я бы перевел это как ответвление, эти самые ответвления являются копиями исходного репозитория, но за тем исключением, что это копия которая принадлежит редактору, а не писателю, а это значит что в ней редактор может менять все что захочет. В том числе и дописывать новые изменения/коммиты.

GitHub Desktop показывает всплывающее окно, если нажать на fork, в котором программа просит подтверждения создания еще одной копии репозитория.

Подтверждаем, что мы хотим создать fork.

Далее программа выясняет как вы планируете использовать эту копию репозитория

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

Далее редактор может закоммитить правки, так же как это делал автор ранее, в свою копию репозитория. Так как эта копия принадлежит ему тут не должно больше возникнуть проблем с доступом.

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

Чтобы рассказать о новых правках редактор создает " запрос на изменение " он же pull request. Дословно это будет как " запрос на затягивание “, то есть мы просим автора забрать/затянуть из нашей версии репозитория правки, которые сделал редактор в свой " оригинальный " репозиторий.

Создание pull request в web версии GitHub

В форме создания " запроса на затягивани е” (pull request - PR) есть несколько очень важных полей " Базовый репозиторий " и " Головной репозиторий " и рядом с этими полями указываются названия веток, о которых было выше. На данном этапе предположим, что нет других веток кроме main и важно только чтобы базовый репозиторий был автора в головной - редактора

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

Затем редактор создает PR нажатием на кнопку Create pull request и после этого появляется еще одна форма

Форма создания PR, очередная в которой уже окончательно можно описать что же предлагает сделать редактор

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

Затем, после того как, описание PR придумано и опубликовано кнопкой Create pull request. Уведомление об этом получает автор.

Поскольку автор является владельцем репозитория у него есть право принимать решения, объединять ли правки редактора или нет. Если у автора есть возражения он может предложить редактору описать поподробнее о смысле этих правок или вовсе закрыть PR без комментариев.

Если в PR не знакомые вам люди предлагают какую то дичь всегда есть опция отклонить/закрыть PR

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

Кнопка merge pull request позволяет принять правки

Если же у автора есть возражения он может начать дискуссию " абстрактную " во вкладке " Conversation " или предметную во вкладке " Files changed "

Синий крестик позволяет начать дискуссию на любой строке предложенных правок

Секция files changed позволяет более точечно выразить свои комментарии к конкретным местам правок.

В секции измененных файлов (1) есть возможность прокомментировать, начать обсуждения конкретных правок. Также если коментариев будет множество хорошей идеей будет воспользоваться кнопкой (3) так как каждый отдельный комментарий (2) - это отдельное уведомление редактору на почту. Обычно очень не приятно получать множество маленьких писем на почту по этому лучше сразу создать ревью (review) то есть пачку комментариев

После ревью нужно сделать выводы, возможные варианты - опубликовать комментарии без вердикта, подтвердить правку, попросить новых правок на основе комментариев

Редактор получает соответствующие уведомления и принимает решение стоит ли ему дальше, что то делать…

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

Буду рад комментариям идеям лайкам, всему тому что поможет сделать эту статью лучше. Поможет вам и другим людям, что прочтут их.