Как сделать организацию github

Обновлено: 05.07.2024

Git - система контроля версий (version control system, VCS), созданная программистом Линусом Торвальдсом для управления разработкой ядра Linux в 2005 году. Хорошо, а что это всё-таки значит?

Представьте, что вы с коллегами вместе пишете ~~ядро Linux~~научную статью. У вас на компьютере есть папка, где лежат текстовые документы, картинки, графики и прочие нужные файлы; то же самое есть и у ваших коллег. Когда кто-то из вас изменяет, добавляет или удаляет файлы, остальные этих изменений не видят. Вы пишете друг другу об изменениях, пересылаете обновленные версии файлов, но в процессе работы непременно возникает путаница: какая версия текста - последняя? Куда и когда исчезла пара абзацев? Кто внес те или иные правки? Избежать таких проблем и помогают системы контроля версий. Устроено это так:

Чем-то похоже на Dropbox, Google Drive и прочие облачные хранилища, правда? Только в данном случае ваши файлы синхронизируются не автоматически, а по команде, и возможностей управления ими гораздо больше.

Понятно, что для совместной работы над текстом научной статьи вполне хватит и Google Docs, но вот если, например, вы хотите опубликовать результаты исследования в интернете и сделать для этого собственный сайт, то без VCS обойтись сложно. И ещё раз, системы контроля версий хороши тем, что:

они позволяют работать над проектом в команде;
вы видите, кем и когда были внесены те или иные изменения;
их всегда можно откатить назад;
вы не потеряете проделанную работу, даже если что-то удалите на своем компьютере;
ваши наработки могут быть полностью открыты для других (а это доступность знаний и ускорение развития технологий, ура!);
GitHub и GitLab позволяют не только хранить и просматривать файлы проекта, но и публиковать веб-сайты, документацию и т.п.

Существует много систем управления версиями, но мы будем пользоваться самой распространенной - git. Также нам нужно как-то отдавать гиту команды, и делать это можно двумя способами: с помощью командной строки и через графический интерфейс (graphical user interface, GUI). Графический интерфейс программы - это все те окошки с кнопочками, которые мы привыкли видеть. Существует много графических интерфейсов для Git, например:

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

Git - разновидность системы контроля версий (самая популярная). Его можно скачать и установить, далее использовать через командную строку.
Можно использовать графический интерфейс для работы с Git. При этом скачивать и устанавливать сам Git отдельно не нужно, он обычно идет в комплекте с графическим интерфейсом (но не во всех GUI).
Репозиторий - это место где мы храним наш код проекта и всю информацию по файлам, их изменения и т.д. Репозиторий должен где-то хранится, чтобы у всех был доступ к нему и они могли видеть изменения. Его можно хранить и на домашнем компьютере, но не всегда удобно держать компьютер включенным целыми сутками, поэтому используют хостинги для репозиториев. Одними из самых известных являются GitHub и GitLab.

GitHub

GitHub - крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Веб-сервис основан на системе контроля версий Git и разработан на Ruby on Rails и Erlang компанией GitHub, Inc. Так как мы будем хранить на нём наши репозитории, поэтому мы и выбрали GitHub Desktop, т.к. он разрабатывался специально для максимальной интеграции и упрощения работы с GitHub.

После регистрации вы попадете на приветственную страницу, где сначала нужно, ничего не меняя, нажать зеленую кнопку Continue, а потом Skip this step (но если не лень, можно заполнить опросник и нажать Submit).

Далее подтвердите свой аккаунт на указанной ранее почте и все, вы готовы к работе.

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

Создать репозиторий можно двумя способами:

Сначала создадим через сайт. Чтобы создать репозиторий, нажимаем кнопку Start a project и выбираем название. Оно может быть любым, но должно отражать суть того, что лежит внутри, например, “homeworks”. Впрочем, GitHub предлагает более креативные варианты. Также в специальном поле можно добавить описание. Для публичных репозиториев хорошей практикой является заполнение всех полей, чтобы другие пользователи (или люди, проходящие по ссылке из резюме) могли сразу понять, о чём конкретно данный репозиторий.

У нас есть выбор между Public и Private. Разница между ними в том, что публичные репозиторий видно в поиске, в вашем профиле, любой может просмотреть весь код и предложить свои исправления (pull request, пулл-реквест, ПР, пи-ар). Приватный репозиторий доступен только определённым пользователям, хозяин репозитория сам выбирает, кто видит репозиторий и кто может делать коммиты. На обычном (бесплатном) аккаунте возможность создавать приватные репозитории обычно ограничена несколькими.

Далее у нас есть возможность инициализировать репозиторий с файлом README. В нем может быть отображена информация о репозитории, о его использовании, установке файлов и т.д. Описание происходит в формате Markdown. Также за этой галочкой скрывается команда init, которая превращает пустую папку в Git-проект.

Также стоит упомянуть про файл .gitignore и LICENSE. Файл .gitignore нужен для того, чтобы в репозиторий не попадали разные временные файлы или сборки, например, при сборке проекта в Visual Studio создается множество временных бинарных файлов, которые при каждом изменении исходного кода программы, будут другими, поэтому для репозитория (хранилища исходного кода) это по факту мусор. Поэтому в этом файле прописано, что определенные папки и файлы не будут учитываться при подготовке коммитов и, следовательно, загрузке в удалённый репозиторий. При создании репозитория можно выбрать уже заранее созданные файлы под язык программирования или среду разработки. Также его можно прописать или дополнить и указать какие файлы включить или убрать из репозитория. Файл LICENSE указывает на то, по какой лицензии распространяется код. Про каждую лицензию можно почитать отдельно и в основном они отличаются тем, что можно делать с кодом: продавать, распространять, изменять и т.д. При создании нашего репозитория можно либо выбрать эти файлы, либо оставить их пустыми.

Популярные лицензии (в сторону уменьшения количества ограничений):

GNU GPL;
MIT;
Unlicense;
WTFPL (do whatever you want public license).

Текст лицензии понадобится скопировать в файл LICENSE.

Клонируем репозиторий

Для дальнеших шагов нам потребуется скачать и установить GitHub Desktop. После установки и первого запуска, возможно, потребуется войти в ваш аккаунт GitHub. Далее выбираем Clone repository или через File, а затем уже Clone repository.

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

Тут мы выбираем из списка репозиторий:

Тут мы вставляем ссылку на репозиторий:

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

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

Если мы откроем GitHub Desktop, мы увидим что наш файл увидела система и пометила как добавление новгго файла, отметив зеленым плюсом. Справа отобразив что именно сделали с файлом: зеленым выделены добавленные фрагменты.

Когда мы готовы сделать коммит, нажимаем кнопку Commit to master. Это означает сделать коммит в локальную ветку master, про сами ветки расскажем чуть позже. Но мы сделали только коммит, теперь нужно чтобы изменились файлы в удаленном репозитории, то есть синхронизировать локальную и удалённую ветки master. Для этого нажимаем кнопку сверху Push origin.

Если все прошло успешно, и изменения запушились в удаленный репозиторий, то, обновив его страницу на GitHub, мы увидим новый файл hello world.txt.

Поверьте, адекватные описания коммитов - это очень важно!

Теперь давайте создадим файл на GitHub и скопируем его в локальный репозиторий. Нажимаем кнопку Create new file и называем его newfile.

Осталось “прописать” коммит и сделать его, нажав Commit new file:

Откроем GitHub Desktop и обнаружим, что система сама определила, что произошел внешний коммит и наши файлы нужно обновить. Если изменений не видно, нажмите F5 или перезапустите приложение. Нажмём на Pull origin и скачаем файлы в свой локальный репозиторий:

Верните всё назад!

Любой коммит можно отменить, щёлкнув по нему правой кнопкой мыши и выбрав Revert this commit. Так, если мы проведём эту процедуру с последним коммитом и запушим изменения на GitHub, то файл goose там исчезнет. В истории изменений данное действие будет видно, как ещё коммит, отменяющий изменения выбранного (анти-коммит). Чтобы посмотреть историю коммитов, нужно нажать на History.

Откатывать коммиты можно также через веб-интерфейс (на сайте GitHub).

Клонирование чужих репозиториев

Клонировать можно не только свои репозитории, но и чужие. Для этого найдите нужный репозиторий в поиске на github. И выбираем Clone or Download.

Далее делаем все как и при копировании своего репозитория, только в данном случае доступен вариант клонировать только по ссылке.

Что это нам дает? Это позволяет получать файлы, сразу после их добавления или изменения и не требует захода на сайт и ручной проверки на изменения.

Fork репозитория

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

В чем же отличие от клонирования репозитория? При клонировании мы только используем файлы оригинального репозитория и при создании коммита с какими-то изменениями, GitHub Desktop скажет нам, что у нас нет доступа на запись и сам предложит сделать форк. (Если доступ к этому репозиторию у нас есть, то сделать коммит мы сможем.) А если мы сделали форк, то изменения уйдут в нашу копию в нашем аккаунте.

Fork может быть полезен при разработки открытого ПО, например, мы сделали форк алгоритма сжатия, в нем мы изменили функцию сжатия и теперь алгоримт сжимает в 10 раз лучше. Мы можем сделать Pull request, т.е. запросить у хозяина оригинального репозитория с алгоритмом сжатия, интегрировать наши изменения в его репозиторий.

Ветки

В git есть понятие branch (ветка). Ветка - это покоммитный “путь” до некоторого коммита, называемого “концом” (tip) ветки. Мы можем иметь несколько независимых веток при работе. Коммит делается в конкретную ветку, по умолчанию это ветка master. Создать новую ветку можно как на сайте, так и в приложении GitHub Desktop. Для этого нужно выбрать вкладку Current branch и нажать на New branch:

Выбираем имя и в эту ветку пойдет вся информация с ветки master (точнее, новая ветка будет “смотреть” на тот же коммит, что и master), в том числе и все файлы:

И теперь мы можем переключать ветки и вносить изменения в конкретную ветку, не затрагивая основную, в данном случае master. Например, мы удалим один файл, и изменим другой. Удалённый файл будет отмечен красным минусом, а изменённый - желтой точкой. При этом справа видно, что мы работаем в ветке Features.

Делаем коммит в новую ветку и смотрим, что произошло. Как мы видим, в ветке master всё осталось, как прежде. Она по прежнему указывает на тот же коммит, что и раньше.

А вот в ветке Features удалённого файла уже нет. Переключить ветку можно, нажав на кнопку Branch с названием ветки:

Ветки удобно использовать для добавления новых функция, что они не ломали рабочий код до новой функции. После разработки ветку можно объединить с master (merge, смёржить, слить) сделав так называемый Pull request.

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

Как говорилось ранее, новый репозиторий можно создать и из самого приложения. Для этого идем в File/New repository:

Указываем все данные аналогично тому как создавали на сайте и нажимаем Create repository:

Не забудьте нажать на Publish repository, чтобы он ушёл на сайт.

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

Адаптированный перевод статьи The beginner's guide to contributing to a GitHub project. Здесь приведены только общие рекомендации по работе с Open Source из визуального интерфейса GitHub. Обязательно ознакомьтесь с README выбранного вами проекта для уточнения деталей.

Шаг 0: Выберите проект

На эту тему очень много статей. Мы будем считать, что вы уже выбрали проект и решились на свой первый шаг. Для примера используется работа над реальным PR в проект Хекслет Sicp.

Шаг 1: Создайте рабочую копию на своем компьютере

Это создаст копию репозитория в вашем аккаунте на GitHub. При переходе в вашу копию проекта вы увидите, откуда он был форкнут:

Используйте эту ссылку для клонирования проекта на ваш компьютер с помощью терминала. Если вы не знаете, как им пользоваться — на Хекслете есть большой курс по базовым командам в командной строке.

Результат будет выглядеть примерно так:

Перейдите в директорию нового проекта:

Теперь ваша локальная копия проекта связана с двумя репозиториями на GitHub:

origin, который указывает на ваш форк проекта на GitHub. Вы можете читать его, и писать в этот репозиторий.
upstream, который указывает на GitHub-репозиторий основного проекта. Этот репозиторий можно только читать.

Шаг 2: Заставьте его работать на вашей машине

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

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

Шаг 3: Сделайте что-нибудь полезное

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

Ветвление

В нашем примере мы исправляем README.md, поэтому мы создадим ветку readme-update:

В первую очередь мы убеждаемся, что находимся на master-ветке. Затем команда git pull синхронизирует нашу локальную копию с основной веткой проекта, а команда git push синхронизирует ее с нашим форкнутым проектом на GitHub. Наконец, мы создаем новую ветку readme-update.

Теперь вы можете заняться устранением проблемы.

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

Убедитесь, что вы коммитите логичными блоками. Каждый коммит должен быть обоснованным. Прочитайте статью Как правильно составлять описания коммитов и почему это важно.

Шаг 4: Создайте Pull Request

В результате будет создана ветка в вашем проекте на GitHub. Флаг -u связывает эту ветку с удаленной, так что в будущем вы сможете просто набрать git push origin в терминале.

Нажмите эту кнопку!

Если вы видите выделенную надпись, как показано ниже:

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

Если вы прокрутите страницу немного вниз, вы увидите diff с вашими изменениями. Дважды проверьте, что он содержит то, что вы ожидаете.

Шаг 5: Проверка разработчиками проекта

Чтобы ваши изменения были приняты в проект, разработчики должны проанализировать вашу работу. После этого они либо запросят изменения, либо объединят ее с основной веткой (либо отклонят их).

Как участвовать в Open Source проектах Хекслета: На Хекслете есть множество Open Source проектов разной сложности — нам всегда нужна помощь разработчиков для развития этих сервисов.

Итоги

Главные этапы работы в Open Source:

Форкни проект и склонируй его на свой компьютер.
Установи связь с основным репозиторием проекта (upstream remote) и синхронизируй с ним локальную копию.
Создавай локальный бранч для каждого логического блока работы.
Внеси изменения, создавай хорошие описания коммитов и читай файл CONTRIBUTING, если он есть.
Синхронизируй изменения со свом форком (origin remote).
Создай Pull Request на GitHub.
Отвечай на все замечания, полученные в ходе код-ревью.

Дополнение от переводчика

Оригинальная статья была написана в 2015 году. С тех пор вышла GitHub cli, и в git появились новые команды. Теперь эти шаги можно сделать ещё проще.

Всем привет! Несмотря на такой долгую паузу после последней статьи о VestaCP, буду пробовать переходить на более интенсивный режим работы. С этого дня темы новых статей будут немного сменены, теперь вы увидите больше статей, связанных с вёрсткой сайтов. Я не беру на себя функцию обучить вас вёрстке, а, скорее, предоставляю вам миниконспект основ, к которому будет легко вернуться и повторить. Надеюсь, вам понравится и вы сможете эффективно использовать предложенную информацию. Хватит предисловий, приступим к работе.

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

Системы контроля версий

Древняя система контроля версий

Наверное, все когда-нибудь сохраняли 2 версии файла с небольшими отличиями под разными именами? К примеру, научка-вер1.txt и научка-вер1-проверил_Пушкин.txt. Первый файл вы отправили своему научному руководителю, он его проверил, внёс свои изменения и отравил вам второй файл. Такое может повторять вплоть до бесконечности, плодя множество файлов, названия которых ставятся все более и более странными. А ваша папка с версиями с "научкой" становится похожа на что-то дикое и сложное в понимании, и найти промежуточную версию становится очень и очень сложно.

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

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

Современная система контроля версий

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

Система контроля версий — это та штука, которая позволяет удобно хранить все версии проекта (т.е. ничего не удаляется и не теряется), и, при надобности, вернуться к более ранним, а также посмотреть, кто, когда и что изменил, комментарии к правкам.

Цель такой системы - поддержание актуальной версии проекта у всех ее пользователей.

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

Виды современной системы контроля версий

Централизованная.

Существует только один репозиторий.
Простые номера версий файлов (1, 2, 3 и т.д.).
У пользователей хранится только текущая версия проекта.
Требуется подключение к интернету.
Просто, но медленно.
Сложности в одновременной работе над одним файлом.

Распределенная.

На один проект приходится много репозиториев.

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

Теперь можно дать определение и слову Git.

Git — это инструмент для реализации работы распределённой системы контроля версий.

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

Как работает GitHub

Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop ) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.

Принципы работы с репозиторием GitHub

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

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (pull) с GitHub с дополнительной версией этого файла. При копировании произойдет конфликт.

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

Способы решения конфликта:

Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

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

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development - ветка для непосредственной разработки; dev-adaptive - ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

На этом небольшое введение походит к концу. Не мучайтесь с допотопной системой версий, переходите на GitHub. Спасибо за внимание.

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

Изучение GitHub позволит ознакомиться с рабочими процессами управления версиями, которые являются общими для многих инструментов docs-as-code. По этой причине на этом курсе есть подробное руководство по использованию GitHub. Независимо от того, используется GitHub в качестве инструмента публикации, это руководство познакомит с рабочими процессами работы Git с контентом.

О Wiki на GitHub

Wii на GitHub можно использовать в качестве сайта документации. Вот пример API Basecamp, который размещен на GitHub.

Wiki-страницы на GitHub используют синтаксис Markdown. Для этого есть специальная версия, названная Github-flavored Markdown или GFM. Эта версия Markdown позволяет создавать таблицы, классы для блоков кода (для корректной подсветки синтаксиса) и т.д.

Поскольку с вики-файлами можно работать локально, можно использовать другие инструменты (например, генераторы статичных сайтов или даже DITA) для генерации файлов Markdown при желании. Работая локально, можно обрабатывать переиспользование, условную фильтрацию и другую логику за пределами вики-сайта GitHub. После чего можно вывести свой контент в виде файлов Markdown и зафиксировать их в своем хранилище GitHub.

Warning: Git используется только для отслеживания текстовых файлов. Не работает Git c большими двоичными файлами, такими как аудиофайлы, видеофайлы, файлы Microsoft Word или файлы Adobe PDF. Системы контроля версий действительно не справляются с такими форматами, и размер репозитория будет возрастать в геометрической прогрессии. Используя Git для управления документацией, такие файлы исключаются через файл .gitignore. Можно также исключить изображения, так как они увеличивают размер вашего репо.

Ограничения wiki на GitHub

Github имеет некоторые ограничения:

ограниченный дизайн: все Wiki GitHub в значительной степени выглядят одинаково;
открытый доступ в Интернете: если документация должна быть приватной, GitHub вряд ли будет подходящим местом для хранения (однако, есть опция делать репозитории приватными);
нет структуры: Вики-страницы GitHub выдают пустую страницу и позволяют добавлять разделы. Но нет возможности делать какие-либо продвинутые стили или интерактивные функции.

Note: Здесь речь именно о встроенной функции Wiki на GitHub, а не GitHub Pages. Для стилизования и автоматического создания контента можно использовать такие инструменты, как Jekyll. Более подробно GitHub Pages рассмотрим в руководстве по Jekyll.

Установка Git

Прежде чем начать работать с GitHub нужно настроить Git и установить все необходимые инструменты и учетные данные для работы с GitHub (особенно если вы работаете в Windows).

Установка на Mac

Установка Git на Mac: Installing on Mac

После установки можно пользоваться Git несколькими вариантами:

в предустановленном терминале, выбрав Applications > Utilities > Terminal;
установить сторонний терминал iTerm;
использовать PlatformIO IDE Terminal в Atom (наверное самый удобный способ работы с проектами)

Установка на Windows

Самый подходящий установщик для Windows это Git for Windows

Этот инсталлятор включает в себя эмулятор терминала Git BASH, который позволят использовать команды Git и Unix.

Проверить, установлен ли у вас Git, открыв терминал и введя следующее:

Настройка автоматической аутентификации GitHub

Git можно настроить так, чтобы не приходилось каждый раз вводить имя пользователя и пароль каждый раз при внесении изменений в GitHub. Как настроить можно почитать по ссылкам:

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

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

👨‍💻 Практическое занятие: Создаем Wiki на GitHub и публикуем пример страницы

Создаем wiki на GitHub и публикуем контент на пробной странице

В этом упражнении создадим новый репозиторий на сайте GitHub и опубликуем файла.

Открываем GitHub и логинимся там. После нажимаем кнопку + и выбираем New repository

Вписываем имя репозитория, краткое описание, выбираем видимость public , выбираем Initialize the repo with a README и затем нажимаем Create repository (Не стоит обращать внимания на выбор лицензии настроек gitignore для этого упражнения).
Переходим на вкладку Wiki в навигационной панели нового репозитория.
Нажимаем кнопку Create the first page (Если wiki уже существует, то нажимаем New Page ).
На начальной странице Home вставляем свой документ, предпочтительно написанный в Markdown. Или можно просто перетащить содержимое страницы fake endpoint called surfreport here.
В поле Edit message вписываем краткое описание (коммит).
Нажимаем Save Page

Обратите внимание, как GitHub автоматически преобразует синтаксис Markdown в HTML и стилизует его для удобства чтения.

👨‍💻 Практическое занятие: Делаем локальную копию репозитория

Клонируем репозиторий на локальную машину

До сих пор мы работали с GitHub в браузере. Теперь мы возьмем тот же контент и будем работать с ним локально. Это то, что делает вики GitHub уникальным среди других вики - это репозиторий Git, поэтому вы можете управлять контентом так же, как и любым другим репозиторием Git (работая локально, выдвигая, вытягивая, объединяя, разветвляя и т. Д.).

Note: Вики имеет отдельный URL, не относящийся к репозиторию проекта. Убедитесь, что вы просматриваете вики, а не проект. URL клона будет включать .wiki.

Открываем командную строку
- те кто пользуется Windows, открывают эмулятор терминала Git Bash,
- пользователи MacOS запускают Applications > Utilities > Terminal или iTerm
Нажимаем Enter и ждем пока система клонирует wiki. В это время видим на экране исполнение команды:

В примере Git создал папку weatherapi.wiki
- Переходим в папку с клонированным репозиторием, чтобы посмотреть какие файлы клонированы.
Tip: Необязательно вводить полное имя каталога. Просто начните вводить первые несколько букв, а затем нажмите клавишу Tab , чтобы автоматически ввести полное имя.

👨‍💻 Практическое занятие: Отправляем локальные изменения в удаленный репозиторий

Отправляем локальные изменения на удаленный репозиторий
- В текстовом редакторе открываем наш файл, скачанный с репозитория git Hub. Файл будет открыт в приложении по умолчанию, связанном с этим типом файла. Вы также можете открыть файл, перейдя к нему вручную и открыв его, как обычно (просмотр в Finder или Explorer).
- Внесем изменения и сохраним файл. Например напишем свое имя вверху документа.
- В терминале удостоверимся, что находимся в нужной папке.
Для просмотра впишем команду ls под текущей строкой. Потом введем команду сd/ для входа в папку или cd ../ для перемещения на уровень выше.

После команды git add Git добавляет файлы в так называемую область подготовки. Используя спортивную аналогию, площадка для постановки похожа на беговую дорожку. Эти файлы готовы для фиксации, когда вы запускаете git commit .

В области подготовки перечислены все файлы, которые были добавлены в Git и которые вы каким-либо образом изменили.

Рекомендуется всегда проверять git status перед фиксацией файлов, потому что вы можете понять, что, набрав git add . , Вы могли случайно добавить некоторые файлы, которые вы не собирались отслеживать (например, большие двоичные файлы). Если вы хотите удалить этот файл из промежуточной области, вы можете ввести команду git reset HEAD Home.md , чтобы удалить его.

Коммит создает слепок файла в данный момент времени для версионирования.

Если ввести только git commit, то будет предложено ввести описание коммита в режиме редактора Bash. Опишите изменения в верхней строке, а затем сохраните и закройте окно.
- Отправляем изменения на удаленный репозиторий командой
Если автоматическая аутентификация на GitHub не настроена, то будет предложено ввести ваши учетные данные: логин и пароль (Ваш username - это логин ID на GitHub).

Читайте также: