Что такое GitHub: зачем он нужен, как с ним работать, создавать и удалять репозитории
Оглавление:
GitHub — это глобальная онлайн-платформа для хостинга разных IT-проектов (чаще всего, приложений и программ), а также для их совместной разработки. По сути — это многофункциональный сервис для разработчиков, состоящий из трех больших модулей: облачное хранилище данных, одноименная социальная сеть, система контроля версий проекта. GitHub неразрывно связан с Git — системой контроля версий. Такая система необходима любому разработчику: в процессе создания приложения в его постоянно вносятся изменения, выпускаются всё новые и новые версии до тех пор, пока не будет опубликован релиз. Системы контроля версий типа Git отслеживают такие изменения и автоматически сохраняют их в облаке. Благодаря Git разработчики проекта легко координируют свою работу: они могут загружать новую версию ПО в общее хранилище, вносить в неё изменения, загружать новые редакции. При этом каждый участник проекта видит такие изменения (с указанием даты внесения).
Простыми словами, GitHub — это веб-сервис для хостинга приложений или других программных проектов. GitHub — не единственная платформа такого рода, но на сегодняшний день — самое популярное решение для размещения исходного кода. Она проста в использовании, поддерживает как публичные, так и частные репозитории, и является бесплатной для большинства проектов небольшого масштаба.
Как это работает
По сути GitHub — это просто веб-интерфейс, использующий Git. Это программное обеспечение для контроля версий с открытым исходным кодом, которое позволяет вносить отдельные изменения в код продукта. Поскольку платформа позволяет вести в работу в режиме реального времени, она также стимулирует команды к более эффективной совместной работе над созданием и редактированием программного продукта.
С помощью GitHub разработчики могут:
- Одновременно создавать код.
- Отслеживать изменения.
- Находить решения проблем, которые могут возникнуть в процессе разработки продукта.
Не-разработчики могут:
- Создавать, редактировать и обновлять содержимое продукта.
- Ознакомиться с публичными версиями проекта.
Главные термины и понятия
Мы подготовили восемь главных терминов, которые вы будете слышать наиболее часто в процессе взаимодействия с «ГитХаб». И усвоить их, желательно, как можно раньше. Вот эти термины:
- Репозиторий (repo) — папка, в которой хранятся все файлы и история их версий.
- Филиал — рабочая область, в которой можно вносить изменения, не влияющие на реальный продукт.
- Markdown (.md) — способ написания текста в «ГитХаб», который преобразует обычный текст в код «ГитХаб». Для работы с markdown, чаще всего, используются специализированные редакторы, лучшие варианты — Atom и Sublime Text (к тому же, они полностью бесплатны).
- Commit Changes — сохраненная запись изменений, внесенных в файл внутри репозитория.
- Pull Request (PR) — запрос на объединение / слияние изменений (внесенные в ветку) с другой веткой. Такой запрос позволит нескольким пользователям видеть, обсуждать и проверять выполняемую работу наиболее подробным образом.
- Слияние — после одобрения запроса на слияние, коммит будет перенесен из одной ветки в другую, а затем — развернут уже на реальном продукте.
- Вопросы — способ отслеживания работы при использовании Git. Они сообщают о новых задачах и исправлениях контента, а также — позволяют отслеживать прогресс на доске проекта: от начала до окончания разработки конкретного проекта.
- Federalist — платформа, которая обеспечивает безопасное развертывание программы или приложения из репозитория «ГитХаб» за считанные минуты. Благодаря «федералисту» можно видеть как предложенные, так и уже опубликованные изменения.
Поначалу терминология «ГитХаб» может показаться усложнённой. Но это — обманчивое впечатление. И чем дольше члены команды работают с платформой, тем легче понять все тонкости и нюансы «ГитХаб». Нужно больше практики.
Пошаговая инструкция, как разрабатывается продукт
Даём пошаговую инструкцию, как происходит развёртывание программного продукта с помощью «ГитХаб»:
- Шаг 1 — участники проекта открывают конкретную проблему (это тема продукта) на доске проекта.
- Шаг 2 — участники проекта создают новую ветку из самой последней версии основной ветки в репозитории. В таком репозитории будет коммуницировать вся команда. Подобное разделение создано для избежание конфликтов и ошибок в ходе разработки продукта.
- Шаг 3 — участники проекта добавляют коммиты (правки или изменения) в свои ветки.
- Шаг 4 — участники проекта открывают запрос на исправление, в котором пользователи могут назначать других членов команды для просмотра изменений содержимого и внутреннего обсуждения деталей исправлений.
- Шаг 5 — дождавшись завершения Federalist-сборки, участники проекта могут предварительно просмотреть изменения на тестовой версии программы и попросить рецензентов одобрить или прокомментировать изменения. Как только рецензенты одобрят запрос на исправление, изменения сливаются в основную ветку и публикуются в действующем продукте.
Пример с кодом
Теперь посмотрим, как это работает с точки зрения новичка.
Допустим, у вас есть файл с некоторым кодом:
//file.txt
Это оригинальный файл.
Это будет исходный файл. Допустим, вы добавляете новую строку, как здесь:
Это новый контент, который мы добавили.
Теперь файловая система запомнила файл file.txt следующим образом:
//file.txt
Это оригинальный файл.
Это новый контент, который мы добавили.
Но Git не запоминает вещи таким образом, как мы показали выше. Вместо этого — он запоминает, какие изменения вы внесли. Затем — он складывает эти изменения вместе, чтобы восстановить файл. Это в какой-то степени похоже на человеческую память (память восстанавливается путем объединения серии событий), В Git каждое из этих событий называется коммитом. Каждый файл — это набор коммитов. Однако простое сохранение файла не превращает его автоматически в коммит. Для превращения файла в коммит мам нужно сказать Git’у, что это изменение (или набор изменений) является коммитом. Для этого нужно выполнить команду commit. Затем вы добавляете сообщение рядом с ней.
git commit -m "Мы добавили новую строку в этот файл, чтобы показать, что означает коммит"
Основное преимущество коммитов заключается в том, что вы можете откатывать и свое приложение. Таким образом, вы можете запустить свое приложение в том виде, в котором оно было сегодня. Затем — вы можете запустить его в том виде, в котором оно было пять дней назад. Вы можете продолжать возвращаться назад и вперед по своему усмотрению.
Некоторые коммиты хранятся на серверах «ГитХаб» (удаленно). Другие — хранятся на вашей локальной машине (это локальные). Коммиты связаны друг с другом, поэтому Git знает, какой коммит был сделан раньше.
Вот, что важно запомнить о коммитах:
- Самый последний коммит называется HEAD.
- Если вы хотите перенести коммиты с удаленной машины на локальную, вы делаете pull.
- Если вы хотите перенести свои коммиты с локального на удаленный, вы делаете push.
Когда вы тянете, разные коммиты от разных людей в разных файлах происходит слияние. Однако, если два коммита произошли в одном файле, ваши локальные коммиты запутаются в том, который является HEAD-коммитом. В этом случае — возникает конфликт слияния. Но это уже тема для другого разговора.
Зачем нужен «ГитХаб»
Ответ мы уже частично дали в начале этой статьи. Давайте подытожим главное назначение этого веб-сервиса. «ГитХаб» — это сайт, который хранит репозитории Git в интернете, чтобы облегчить совместную работу, которую позволяет осуществлять Git. Репозиторий же — просто место для хранения кода и всех изменений в нем.
При помощи «ГитХаб» разработчик может:
- Отслеживать изменения в коде проекта.
- Синхронизировать код между разными участниками команды (обычно — это разработчики продукта).
- Тестировать изменения в коде без потери оригинала.
- Без труда возвращаться к старым версиям кода при необходимости.
- Делиться своими репозиториями с другими.
- Получать доступ к репозиториям других пользователей.
- Хранить удаленные копии ваших репозиториев (на серверах «ГитХаб») в качестве резервных копий ваших локальных копий.
Отвечая на вопрос, зачем нужен GitHub, нельзя не заметить любопытный факт: всё чаще и работодатели смотрят на GitHub. Особенно эта практика распространена у зарубежных компаний, когда опыт разработки оценивается исключительно по профилю соискателя на «ГитХаб».
Как новичок — вы можете сделать свой профиль на GitHub и делиться своим кодом с друзьями, дорабатывать и вносить в свой продукт вклад.
Как веб-разработчик — вы можете иметь свой собственный сайт, разместив его на GitHub.
Чем GitHub отличается от Git
Это из разряда: «чем отличается сыр от творога». Git — это система контроля версий, инструмент для управления историей вашего исходного кода. GitHub — это хостинг-сервис для репозиториев Git. Таким образом, это не одно и то же: Git — это инструмент, GitHub — это сервис для проектов, использующих Git.
Но одно из основных заблуждений относительно GitHub заключается в другом. Многие думают, что этот инструмент — только для разработчиков (как языки программирования или, например, компиляторы). Но это миф. Сам GitHub — не более чем социальная сеть, подобная «ВКонтакте»: вы создаете профиль, загружаете проекты, которыми хотите поделиться, и общаетесь с другими пользователями, «следуя» за их аккаунтами. И хотя многие хранят программы или исходный код в таких папках, ничего не мешает вам хранить в них текстовые документы или изображение, например (чтобы показать их другим пользователям).
Теперь подробнее об отличиях между двумя терминами.
- Git — это распределенная одноранговая система контроля версий. Каждый узел в сети — представляет из себя пир (в нём содержатся целые репозитории). Пир также может выступать в качестве многоузловых распределенных резервных копий.
- GitHub — это веб-сервис хостинга репозиториев Git. Он предоставляет все функции распределенного контроля ревизий и управления исходным кодом (SCM) Git, а также — добавляет свои собственные возможности (контроль доступа, функции совместной работы, управление задачами, отслеживание ошибок и запросы функций).
GitHub (и любая другая локальная, удаленная или размещенная система) может быть одним и тем же распределенным репозиторием в рамках одного проекта.
Как создать репозиторий на GitHub
Каждый проект, над которым вы работаете, помещается в так называемый репозиторий. Каждый репозиторий имеет свой собственный набор коммитов.
- После создания учетной записи на GitHub вы сможете создать новый репозиторий из веб-интерфейса GitHub.
- После создания репозитория вы увидите его URI. Затем вы можете установить его как удаленный с вашей локальной машины, а затем выполнить на него push.
На локальной машине процедура будет выглядеть следующим образом:
Чтобы создать репозиторий на «ГитХаб» на сайте платформы выполните следующие действия:
- Нажмите на плюс в правом углу экрана.
- Выберите пункт New repository.
Нажмите на строку New repository
- Дайте хранилищу имя. Лучше если оно будет кратким и запоминающимся.
Мы называли хранилище my-new-project
- Опционально добавьте описание для создаваемого репозитория.
- Укажите уровень видимости для создаваемого репозитория.
Мы создали публичный репо
Доступно три варианта видимости:
- Public (любой может увидеть такой репозиторий).
- Internal (только члены вашей команды могут видеть такой репозиторий, вы сами выбираете кто может коммитить).
- Private (вы сами выбираете, кто может видеть репозиторий и коммитить).
Пропустите настройку видимости репозитория, если ваша задача заключается в импортировании уже существующего репозитория.
- Отметьте чекбокс — для инициализирования создаваемого репозитория с помощью файла README.
Не забудьте отметить этот чекбокс
- Нажмите зелёную кнопку Create repository.
Как просмотреть репозиторий
Вот пошаговый алгоритм действий:
- В левой боковой панели, под списком репозиториев, воспользуйтесь выпадающим меню Manage notifications.
- В меню нажмите Watched repositories.
- Оцените репозитории, за которыми вы следите, и решите, являются ли их обновления по-прежнему актуальными и полезными для вас.
Как просмотреть файлы в репозитории
Вы можете просмотреть необработанное содержимое файла или отследить изменения строк в файле и узнать, как части файла изменялись с течением времени. Рассмотрим оба способа.
Как просмотреть или скопировать необработанное содержимое файла
В режиме просмотра необработанного содержимого вы можете просмотреть или скопировать необработанное содержимое файла без какой-либо стилизации.
- На сайте GitHub.com перейдите на страницу репо.
- Кликните по файлу, который вы хотите просмотреть.
- В правом верхнем углу окна просмотра файла нажмите Raw.
Нажмите эту кнопку, чтобы просмотреть необработанное содержимое
По желанию, чтобы скопировать содержимое необработанного файла, в правом верхнем углу просмотра файла нажмите на эту иконку:
Используйте эту иконку, чтобы скопировать содержимое RAW-файла
Как посмотреть построчную историю ревизий файла
В режиме blame-просмотра можно увидеть построчную историю ревизий для всего файла или историю ревизий отдельной строки в файле, нажав на размноженный квадрат:
Нажмите эту иконку, чтобы посмотреть построчный лог ревизий файла
Каждый раз, когда вы нажимаете на иконку размноженного квадрата, вы увидите информацию о предыдущей ревизии для этой строки, включая информацию о том, кто и когда внес изменения.
В левом углу вы увидите, кто вносил изменения
В файле или запросе на доработку вы также можете использовать меню для просмотра blame — только для выбранной строки или диапазона строк.
Выберите эту строчку в меню, чтобы оценить blame для строки или диапазона
- На сайте GitHub.com откройте на главную страницу репо.
Кликните, чтобы открыть файл, историю строк которого вы хотите просмотреть.
- В правом верхнем углу представления нажмите Blame, чтобы открыть соответствующее представление.
Нажмите эту кнопку для открытия blame-представления
- Чтобы просмотреть более ранние изменения конкретной строки или повторное blame-представление, щелкайте по размноженному квадрату, пока не найдете интересующие вас изменения.
Нажмите на эту иконку, чтобы найти ранее внесенные изменения по строке
Как удалить репозиторий на GitHub
Вы можете удалить любой репозиторий или форк, если вы являетесь владельцем организации или имеете права администратора для репозитория или форка.
Если параметр Allow members to delete or transfer repositories for this organization отключен, только владельцы организации могут удалять хранилища организации.
После вашего подтверждения репо будет предварительно стерт, но вы сможете восстановить его в течение девяноста дней. По истечении девяноста дней — репозиторий будет полностью удален.
Предупреждения:
- Удаление хранилища приведет к окончательному удалению вложений релиза и разрешений команды. Это действие нельзя отменить.
- Некоторые удаленные хранилища могут быть восстановлены в течение 90 дней после удаления.
- Удаление частного хранилища приведет к удалению всех форков хранилища.
Вот алгоритм действий, как удалить репозиторий:
- На сайте GitHub.com откройте на главную страницу репо.
- Кликните по шестеренке (Settings).
Нажмите на эту кнопку
- В блоке Danger Zone нажмите кнопку Delete this repository.
Нажмите эту кнопку
- Прочитайте предупреждения.
- Чтобы убедиться, что вы удаляете правильное хранилище, введите его название. Если не знаете название, удалить хранилище не удастся.
- Нажмите I understand the consequences, delete this repository, чтобы завершить удаление репозитория.
Укажите название удаляемого репозитория и отметьте чекбокс
Когда вы удаляете репозиторий GitHub, вы удаляете его навсегда со всеми его данными, включая кодовую базу, проблемы, запросы на исправление и все остальное, связанное с ним. Будьте осторожны при использовании этого метода, так как данные восстановить не получится (после 90 дней).
Ветки и коммиты
Кратко о ветвях
Репозитории похожи на ветви деревьев. Они начинаются с одной основной ветви. Если хотите — можете фиксировать всё в одной мастер-ветке. В противном случае, вы можете создать новую ветвь и фиксировать там, пока участники команды фиксируют в мастер-ветви.
Но можно также работать над совершенно разными проектами в каждой ветке. Но это будет сродни выращиванию яблок из мангового дерева.
Примечание: Вы можете создать ветви только в том хранилище, к которому у вас есть push-доступ.
Вы можете создавать и удалять ветви непосредственно на GitHub. Сделать это можно различными способами.
Как создать новую ветку через Overview
Вот пошаговая инструкция, как создать ветку с помощью обзора:
- На сайте GitHub.com перейдите на главную страницу репозитория.
- Нажмите на кнопку Branches, которая находится сразу над списком файлов.
Нажмите эту кнопку, чтобы открыть управление ветками
- Кликните по зеленой кнопке New branch.
Нажмите эту кнопку, чтобы создать новую ветку
- 4. В диалоговом окне введите имя ветви.
Опционально вы можете изменить источник ветки.
Если хранилище является развилкой, у вас также есть возможность выбрать в качестве источника ветки вышестоящее хранилище. - Нажмите кнопку Create branch, чтобы завершить создание ветку.
Как создать новую ветку через выпадающий список ветвей
- На сайте GitHub.com откройте самую главную страницу репо.
Если вы хотите создать новую ветку из ветки, отличной от ветки репозитория по умолчанию, нажмите Branches и выберите другую ветку.
Нажмите эту кнопку, чтобы открыть управление ветками
- Нажмите на меню селектора ветвей.
Нажмите на кнопку main
- Введите какое-нибудь название для новой ветки и нажмите зеленую кнопку Create branch.
Создаем новую ветку и сохраняем результат
Как удалить ветку
Алгоритм действий не вызовет затруднений:
- На сайте GitHub.com откройте главную страницу репозитория.
- Нажмите на кнопку Branches, которая находится сразу над списком файлов.
Нажмите эту кнопку, чтобы открыть управление ветками
- Прокрутите до ветки, которую вы хотите удалить, затем нажмите иконку корзины.
После прокрутки до необходимой ветки кликните по красной корзине
- 4. Если вы пытаетесь удалить ветку, которая связана хотя бы с одним открытым запросом на исправление, вы должны подтвердить, что намерены закрыть запрос или запросы.
Чтобы подтвердить удаление связанной ветки нажмите Delete.
Коммиты
Когда мы создавали наш репозиторий мы инициализировали его файлом README (см. в разделе «Как создать репозиторий на ГитХаб», 6-й пункт). Такой файл может содержать детальное описание проекта или, например, техническую документацию проекта.
===============================
Вот как скоммитить изменение в файле README:
- Откройте проект.
- В списке файлов найдите файл README с расширением .MD.
- Нажмите на карандаш над содержимым файла.
- Откроется новое окно и на вкладке Edit file укажите информацию о проекте (или, например, о себе).
- Чтобы увидеть изменения содержимого нажмите кнопку Preview Changes.
- Проанализируйте изменения, которые вы добавили в файл. Вы увидите новое содержимое зелёным цветом.
- В самой нижней части окна укажите краткое пояснение, которое емко описывает внесенное изменение.
- Чуть ниже укажите, в какую ветку нужно добавить изменение. Можно добавить фиксацию в новую ветку или уже существующую.
- В самом низу страницы нажмите зелёную кнопку Propose File Change.
Теперь вы создали репозиторий, включая файл README, и создали свой первый коммит на GitHub. Вы также можете клонировать репозиторий GitHub, чтобы создать локальную копию на своем компьютере.
Уже из локального хранилища можно сделать коммит и создать запрос для обновления изменений в вышестоящем хранилище.
Резюме: как быстро научиться работать с GitHub
Хотите сделать этот сервис своим инструментом и сильной стороной? Сосредоточимся на техническом граунде, который вам понадобится:
- Сначала изучите ОС Linux и научитесь свободно пользоваться этой ОС.
- Научитесь писать, компилировать и запускать:
- Программы на C / C++ / Java / Python в Linux.
- Сценарий оболочки Linux.
- Основные команды системного администрирования Linux.
Поймите и изучите все вышеуказанные инструменты досконально, прежде чем начать использовать GitHub. Возможно, в начале могут возникать трудности, если вы раньше не работали с Linux.
Вы можете легко интегрировать свой код с облачными платформами, такими как AWS, Microsoft Azure, Google Cloud и другими.
Вы можете работать над проектами удаленно, как часть большей команды, даже не выходя из дома.
Вы можете участвовать в проектах с открытым исходным кодом и многому научиться.
Рекомендации от практиков GitHub:
- При запуске проекта с использованием проектных досок, лучше пользоваться внешними текстовыми редакторами (например, Google Docs), а затем — сохранять эти файлы на соответствующих проектных досках. Эти шаги позволят иметь основную копию файла(ов), что поможет отслеживать изменения в ходе создания проекта более эффективно и точно.
- Для новичков хорошо начать с GUI-приложений для GIT, таких как Gitkraken. Они помогут новичкам стать более продуктивными и эффективными при работе с Git.
- Обязательно скачайте клиент для компьютера GitHub Desktop. Он позволяет делать все то, что можно делать в веб-интерфейсе GitHub, но локально на вашем компьютере.
GitHub создан как интерфейс для совместной работы. Позволяя нескольким специалистам одновременно работать над одним проектом и требуя межкомандного одобрения запросов (на внесение изменений), GitHub улучшает качество взаимодействия разработчиков в группах. Такой тип совместной работы может помочь обеспечить более высокий уровень контроля качества проекта.
Важно: GitHub является стандартом в современной разработке, хотя существуют и другие системы контроля версий. Но именно GitHub имеет большое количество преимуществ перед другими подобными системами, например, он позволяет хранить логи изменений более эффективно и обеспечивает необходимую целостность проекта.
Чтобы эта статья принесла максимальную – пользу дадим еще несколько команд.
Чтобы загрузить или клонировать репозиторий:
git clone <repository_url>
Чтобы внести или обновить свои изменения в репозитории:
git add.
git commit -m "commit-message"
git push origin <your-branch-name>
Чтобы извлечь последние изменения, внесенные вами или вашим коллегой:
git pull
Чтобы сбросить свои изменения в конкретный коммит:
git reset --hard <commit-id>
Чтобы проверить бренч:
git checkout <branch-name>
И напоследок: если вы запутались, то нужно еще раз проговорить разницу между Git (система контроля версий) и GitHub (сервис для хостинга проектов). Git всегда работает независимо от GitHub. Или вы можете использовать GitHub для размещения своего основного репозитория, как мы рассказывали выше.