Github что это за программа и для чего она предназначена

Что такое GitHub

В 2005 году создатель ядра Linux Линус Торвальдс столкнулся с проблемой: с ним над проектом работало много людей, каждый делал свою часть — и надо было управлять добавлением нового кода, тестированием и устранением багов.

Так знаменитый разработчик придумал Git — распределённую систему управления версиями. Её устанавливают на все компьютеры, где ведётся работа над проектом. Система позволяет создавать и развивать ветви проекта, откатываться к предыдущим версиям, клонировать. Подробнее про Git мы писали в отдельной статье.

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

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

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

Разбираемся с терминами

Репозиторий — папка с вашим проектом, где лежат файлы, иконки программы, разные картинки. В GitHub у каждого репозитория есть страница с описанием проекта.

Ветка (Branch) — копия проекта в рамках одного репозитория. Есть главная ветка проекта, или main. Но любой разработчик может скопировать проект в свою ветку и работать над его частью, не трогая исходный код и не мешая другим разработчикам. Ветки независимы друг от друга, но их можно объединять, мёржить (от англ. merge — слияние), даже если есть разница в коде.

Клонирование — копирование репозитория из GitHub на жёсткий диск. При клонировании на компьютер пишется вся история версий, все ветки. Если кто-то вносит изменения в репозиторий, вы их тоже получите. Простое копирование таких возможностей не даёт.

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

Форк — копирование репозитория, обычно чужого, для продолжения разработки по другому пути. Часто бывает в опенсорсных проектах.

Пул-реквест (pull request) — предложение автору проекта своих улучшений, чтобы он залил их в исходный репозиторий.

Как работать на GitHub

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

Выберите пункт New Repository, заполните название и краткое описание, проставьте нужные галочки и щёлкните на Create Repository

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

Работа с GUI-клиентом GitHub Desktop — следующий уровень погружения в GitHub. Он не требует знания команд для терминала, но позволяет удобно настроить работу с платформой и полноценно заниматься написанием кода в локальной копии репозитория у себя на компьютере.

Клиент позволяет клонировать репозиторий из хостинга себе на компьютер и отправлять локальные репозитории обратно. Он похож на клиент Яндекс Диска: синхронизирует ваши файлы с облаком.

Но только GitHub CLI (Command Line Interface) позволяет использовать все возможности платформы. В Linux (например, в Ubuntu) CLI Git установлен «из коробки». Иногда предустановлен CLI и в MacOS. В Windows для ввода команд можно использовать PowerShell.

Как посмотреть чужие репозитории

Многие ваши задачи кто-то уже решил. Например, Яндекс написал асинхронный фреймворк userver для быстрого создания микросервисов, сервисов и утилит на C++. Почему бы не воспользоваться чужими наработками?

Вот что можно увидеть на главной странице репозитория — на примере фреймворка Яндекса userver

Справа — краткое описание проекта. Видно, что у репозитория 15 веток, в ветке master 3801 коммит, 18 пул-реквестов, последний релиз был вчера. У проекта лицензия Apache-2.0.

На что обращать внимание при поиске нужных решений в других проектах:

  • Описание на главной странице под списком файлов.
  • Лицензия проекта — GPLv3 или Apache 2.0. В ней указано, на каких условиях вы можете его использовать.
  • Популярность и дата последнего обновления. В редких случаях может подойти инструмент, который написан десять лет назад, но чаще нужен проект, который поддерживается автором или сообществом разработчиков. На это указывает частота обновлений, количество и содержание коммитов, форков. Посмотрите также на звёздочки — это некий аналог лайков и репостов.

Как оформить свой профиль на GitHub

Разработчики используют аккаунт GitHub как портфолио. Чтобы он привлекал работодателей, важно правильно его оформить. Вот несколько советов:

  1. Используйте в профиле свои реальные имя и фамилию и поставьте качественную фотографию. Но личную электронную почту лучше не публиковать, чтобы не получать много спама.
  2. Размещайте в открытом доступе только те репозитории, что вы хотите показать потенциальному работодателю.
  3. Описывайте каждый проект как можно более точно и подробно, используя файл Readme.md.
  4. Посмотрите во вкладке Trending, как оформлены профили самых трендовых разработчиков GitHub, и пользуйтесь лучшими практиками.

Материалы для погружения в GitHub

  1. Изучите официальную документацию GitHub. Она есть на русском языке, в ней достаточно подробно расписаны шаги по изучению этого инструмента.
  2. Почитайте статьи про GitHub на Хабре, например «Работаем с Git: первые шаги в GitHub», «Как начать работать с GitHub: быстрый старт».
  3. Посмотрите видеоуроки по Git и GitHub от ITDoctor или «Базовый курс по Git» от Devcolibri.

Что такое Git и для чего он используется

Что такое Git

Рассказываю про Git – популярнейшую систему контроля версий для разработчиков.

Что такое Git?

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

Чаще всего Git используется в разработке приложений и сайтов, но он также находит применение и в других сферах, например в переводах книг.

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

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

Под системой контроля в контексте Git подразумевается программный механизм для работы с контентом. В «работу» также входит хранение, передача данных, отслеживание изменений и прочие аспекты.

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

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

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

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

Распределенная система контроля версий

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

Стейджинг в Git

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

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

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

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Зачем нужен Git?

Затем, чтобы не случился апокалипсис в мире разработки (и не только, но мы будем оперировать именно областью IT). Сейчас трудно представить себе мало-мальски крупное приложение, над которым работал бы один человек. За проектом всегда стоит целая команда создателей. И чтобы им всем было комфортно работать вместе, нужна распределенная система контроля версий. Это гарантия отсутствия конфликтов в коде и возможность вести разработку нескольких функций ПО, не соприкасаясь друг с другом и общим кодом.

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

Подробнее о внутреннем строении Git

Репозитории

Репозиторий (репо, реп) – это хранилище файлов проекта. То есть все компоненты, относящиеся к одному приложению (код, изображения, конфигурационные файлы, стили, скрипты и т.п.). С ним как раз и работают люди, ведущие совместную работу над одним продуктом.

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

По умолчанию каталог .git скрыт, но его видят git-приложения, например git, Sublime Merge, Gitfox и другие аналоги.

Коммиты, пуши и стейджинг

Коммит – это единица контента, хранящая в себе информацию о том, какие компоненты репозитория были изменены на текущий момент времени.

За счет них и работает контроль версий. Допустим, вы решили немного поменять оформление сайта. Открываете файл .css, вводите туда новое значение шрифтов или цветов, а потом сохраняете их. Чтобы это изменение отразилось в git, нужно создать коммит (git commit — m, «описание коммита»). Теперь вы можете в любой момент вернуться к этому этапу в разработке сайта.

Стейджинг-зона – это временное пристанище измененных файлов. Отправляясь в стейджинг-зону (git add), они помечаются как «в разработке», но при этом из них все еще можно выбрать готовые файлы, чтобы непосредственно их закоммитить. Файлы хранятся в стейджинг-зоне (git add) до тех пор, пока пользователь не сделает коммит и не запушит (git push) изменения на сервер, то есть не выгрузит с локального репозитория в удаленный.

Удаленные репозитории (GitHub, GitLab и т.п.)

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

Схема работы с GitHub

Коммиты остаются в локальном репо, но с помощью команды push можно отправить их в GitHub. А при помощи команды pull можно вытащить их в локальный реп, чтобы иметь под рукой самую новую версию проекта для дальнейшей разработки новых функций.

Ветви и мерджинг

Две функции, вокруг которых строится параллельная разработка.

Ветви (branches) – это разные состояния одной программы. Например, есть ветка master (иногда ее называют main) – в ней обычно хранится приложение с полным набором функций и дизайном, готовое к деплою (то есть публикации в App Store или загрузке на сервер). Есть ветка develop, в которой программисты корпят над нововведениями. Веток может быть неограниченное количество, хоть по одной для каждой функции.

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

Мерджинг (merging) – это процесс объединения одной ветки с другой. Чаще всего – ветки develop с веткой main.

Пул-реквесты

Pull Request – это запрос на проверку и одобрение кода. Когда один из программистов заканчивает свою работу, он отправляет PR своим коллегам. Те проводят аудит кода и выносят вердикт, публикуется этот код или нет.

Схема пул-реквеста

При этом сам пул-реквест является не просто оповещением о готовности куска кода – это целая система взаимодействия и обсуждения. Один PR может превратиться в десятки комментариев и правок кода. После «обработки» PR превращается в мердж.

Разработчики также стали использовать функцию Pull Request Preview, позволяющую подключить к процессу проверки кода дизайнеров, начальство и заказчиков.

С чего начать работу в Git?

Скачиваем git последней версии с официального сайта. Затем создаем директорию для репозитория и переходим в нее с помощью команды cd.

Создаем новый репо:

git int

Далее создаем документ в формате .txt или .html. Реп готов!

Теперь можно работать с git. Вот список основных команд:

  • git add – добавить файл в стейджинг-зону для работы над изменениями.
  • git commit – создать коммит.
  • git status – посмотреть статус коммитов (их количество, внесенные изменения).
  • git branch название ветки – создать новую ветвь.
  • git checkout название ветки – переключиться на другую ветвь.
  • git merge название ветки – объединить выбранную ветвь с той, к которой подключен пользователь. То есть сначала надо сделать checkout, а потом merge.
  • git remote add origin ссылка на удаленный репозиторий – подключиться к удаленной платформе. Ссылку на репо можно взять в GitHub или в GitLab в соответствующем разделе.
  • git push -u origin название ветки – отправить набор коммитов в удаленный реп.
  • git clone ссылка на удаленный репозиторий – скопировать себе на устройство все данные из GitHub или BitBucket.

На этом все. Вас можно поздравить – теперь вы знаете, что такое git и как работать с системой контроля версий.

GitHub: краткий обзор для новичков

GitHub: краткий обзор для новичков

Разработчики программ используют в работе различные платформы для обмена исходным кодом, его хранения и распространения. Одной из таких платформ является GitHub. Она настолько популярна, что ее мощностями пользуются даже такие «монстры», как Microsoft и RedHat. Инструментарий платформы включает возможности просмотра кода, а также его распространения с документацией и релизами.

Гитхаб

Веб-сервис GitHub востребован для хостинга IT-проектов и совместной разработки. Разработчики системы называют ее «социальной сетью» для программистов. Здесь они объединяют репозитории, комментируют примеры «чужого» кода и используют платформу в качестве облачного хранилища с возможностью быстрой передачи заказчику.

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

Первый шаг к использованию сервиса GitHub заключается в регистрации нового пользователя. В процедуре нет ничего сложного – достаточно зайти на официальный сайт https://github.com/ и создать новую учетную запись. Система запросит рабочую электронную почту.

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

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

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

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

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

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

  1. Нажать на кнопку «Start a project».
  2. Ввести название и описание репозитория.
  3. Поставить галочку на «Initialize this repository with a README».
  4. Выбрать нужный тип лицензии и нажать на кнопку «Create project».

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

Проект в Гитхабе

Подобный подход часто используют создатели продуктов, которыми пользуются «массы». Им передается ссылка на проверенные стабильные версии, в то время как команда продолжает работу над таким же комплектом файлов без опасения нарушить функциональность системы в целом. При использовании платформы следует ориентироваться на отметку «Branch».

Данная отметка обозначает текущую ветку. Создание новой инициируется просто – достаточно в списке начать набирать еще несуществующее название, и система выдаст сообщение «Create branch». Сразу после этого пользователь перекидывается в новую ветку (это стоит учитывать при работе, чтобы случайно не начать редактирование «не тех файлов»).

Изменение файлов и коммиты

Корректировка файлов на GitHub выполняется при помощи коммитов. Это непосредственно само исправление и краткое описание изменений. Такой подход позволяет «внешним» пользователям ориентироваться в нововведениях кода и упрощает контроль командной работы, когда один и тот же файл может редактироваться разными исполнителями.

Система сохранения информации о корректировках удобна, когда они вносятся в различные участки кода, но связаны с определенной задачей. Фактически текстовый файл с описанием «связывает» разрозненные изменения и объясняет непосвященному программисту их суть, назначение. Чтобы запустить редактирование README, нужно в правой панели нажать на «кисточку».

Коммит

После этого откроется текстовый редактор, где вносятся исправления. По завершении заполняется поле «Commit» внизу страницы (кратко, что изменилось) и нажимается кнопка «Commit changes». Сохраненные корректировки будут внесены в текущую (активную) ветку проекта, поэтому перед их внесением следует убедиться в правильном выборе.

Создание запросов слияния (Pull Request) в Github

При подключении к работе сторонних специалистов может понадобиться функция запроса слияния (Pull Request). Инструмент для работы в таком формате называется DIFF. Он подчеркивает любые «чужие» изменения, чтобы владелец программы сразу видел, где код писал не он. Пометки будут доступны только после создания коммита.

Пулл ркеквест

  1. Открыть вкладку «Pull Request».
  2. Нажать на кнопку «Create Pull Request».
  3. Выбрать ветку, которую следует слить с основной.
  4. Просмотреть внесенные кодером изменения.

После изучения информации созданный запрос на слияние подтверждается нажатием «Merge Pull Request». Новый код будет импортирован в основную ветку, а созданная сторонним исполнителем может спокойно удаляться.

Отчеты об ошибках

Платформа GitHub используется не только для совместной разработки, а еще и для получения обратной связи с пользователями продуктов. Так, на вкладке «Issue» любой «тестировщик» может оставить сообщение о проблемах, с которыми ему пришлось столкнуться при использовании ПО. Чтобы сделать это, нужно нажать кнопку «New issue».

После этого вносится заголовок и текст сообщения. «Проблема» отправляется нажатием на кнопку «Create new issue». Владелец ветки получает уведомления в личном кабинете или на электронную почту, указанную при регистрации.

Заключение

Финалом разработки обычно становится выпуск определенного релиза программного продукта. Это отражается на вкладке «Releases». Здесь следует нажать на кнопку «Create New Release», указать номер версии в поле «Tag Version», внести ее название и небольшое описание. Здесь же прикрепляются архивы с компилированными файлами.

Остается нажать на «Create Release» и убедиться в публикации релиза. Ссылки на исходный код в tar.gz и zip создаются автоматически. Остальные файлы понадобится добавлять вручную.

При подготовке материала использовались источники:
https://academy.yandex.ru/journal/chto-takoe-github
https://timeweb.com/ru/community/articles/chto-takoe-git
https://timeweb.com/ru/community/articles/kak-polzovatsya-github

Оцените статью