На чем написан github
Git и GitHub: что это такое и в чём разница
Авторизуйтесь
Git и GitHub: что это такое и в чём разница
Из этой статьи вы узнаете, что такое Git и какие в принципе бывают системы контроля версий, которые помогают разработчикам следить за изменениями в коде. Мы также посмотрим, что такое GitHub и какие ещё есть сервисы для работы с Git.
Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.
Содержание:
Что такое Git
Git — распределённая система контроля версий, которая даёт возможность разработчикам отслеживать изменения в файлах и работать над одним проектом совместно с коллегами. Она была разработана в 2005 году Линусом Торвальдсом, создателем Linux, чтобы другие разработчики могли вносить свой вклад в ядро Linux. Git известен своей скоростью, простым дизайном, поддержкой нелинейной разработки, полной децентрализацией и возможностью эффективно работать с большими проектами.
Подход Git к хранению данных похож на набор снимков миниатюрной файловой системы. Каждый раз, когда вы сохраняете состояние своего проекта в Git, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок.
Теперь пора разобраться, что такое GitHub и как он работает с Git.
Что такое GitHub и чем он отличается от Git
Как мы разобрались выше, Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.
GitHub — сервис онлайн-хостинга репозиториев, обладающий всеми функциями распределённого контроля версий и функциональностью управления исходным кодом — всё, что поддерживает Git и даже больше. Также GitHub может похвастаться контролем доступа, багтрекингом, управлением задачами и вики для каждого проекта.
Git-репозиторий, загруженный на GitHub, доступен с помощью интерфейса командной строки Git и Git-команд. Также есть и другие функции: документация, запросы на принятие изменений (pull requests), история коммитов, интеграция со множеством популярных сервисов, email-уведомления, эмодзи, графики, вложенные списки задач, система @упоминаний, похожая на ту, что в Twitter, и т.д.
Кроме GitHub есть другие сервисы, которые используют Git, — например, Bitbucket и GitLab. Вы можете разместить Git-репозиторий на любом из них.
Что такое система контроля версий
Чтобы лучше понимать, что такое Git и как он работает, нужно ещё знать, что такое система контроля версий.
Системы контроля версий (СКВ, VCS, Version Control Systems) позволяют разработчикам сохранять все изменения, внесённые в код. При возникновении проблем они могут просто откатить код до рабочего состояния и не тратить часы на поиски ошибок.
СКВ также позволяют нескольким разработчикам работать над одним проектом и сохранять внесённые изменения независимо друг от друга. При этом каждый участник команды видит, над чем работают коллеги.
Типы систем контроля версий
Теперь вы знаете, что такое система контроля версий. Однако они тоже бывают разными. Существует три типа СКВ: локальная, централизованная и распределённая.
Локальные системы контроля версий (ЛСКВ)
Принцип работы локальной системы контроля версий
В качестве метода контроля версий можно копировать файлы в отдельную директорию. Изменения сохраняются в виде наборов патчей, где каждый патч датируется и получает отметку времени. Таким образом, если код перестаёт работать, наборы патчей можно совместить, чтобы получить исходное состояние файла. Такой подход всё ещё распространён среди разработчиков.
Централизованные системы контроля версий (ЦСКВ)
Принцип работы централизованной системы контроля версий
ЦСКВ были созданы для решения проблемы взаимодействия с другими разработчиками. Такие системы имеют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища и там же их сохраняют. Тем не менее, такой подход имеет существенный недостаток — выход сервера из строя обернётся потерей всех данных. Кроме того, в таких системах может быть затруднена одновременная работа нескольких разработчиков над одним файлом.
Распределённые системы контроля версий (РСКВ)
Принцип работы распределённой системы контроля версий
Недостаток ЦСКВ был исправлен в РСКВ, клиенты которых не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени), а полностью копируют репозиторий. Это значит, что у каждого клиента есть копия всего исходного кода и внесённых изменений. В этом случае, если один из серверов выйдет из строя, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Ещё одним преимуществом РСКВ является то, что они могут одновременно взаимодействовать с несколькими удалёнными репозиториями. Благодаря этому разработчики могут параллельно работать над несколькими проектами. Именно поэтому Git сейчас так популярен.
Десять лет Git: интервью с создателем — Линус Торвальдс
На этой неделе исполнятся десять лет с того момента, когда разработчики ядра Линукса столкнулись с помехой: они больше не могли использовать свою систему контроля версий BitKeeper и никакая другая система контроля исходного кода не удовлетворяла их требованиям в плане распределённости ресурсов. Линус Торвальдс, создатель Линукса, принял вызов и пропадал в течение выходных дней для того, чтобы на следующей неделе появиться с Git. Сегодня Git используется в тысячах проектов и Git подтолкнул программирование в группах разработчиков на новый социальный уровень.
Чтобы отметить эту дату, мы попросили Линуса поделиться скрытой историей создания Git, рассказать нам что он думает об этом проекте и о его влиянии на разработку программных продуктов. Вы найдёте его комментарии ниже в тексте. За этим интервью последует неделя Git, в которой каждый день мы будем рассматривать отдельные проекты, использующие эту систему контроля версий. Ожидайте истории разработки KVM, Qt, Drupal, Puppet, Wine и многие другие.
Почему ты создал Git?
Торвальдс: На самом деле, я никогда не хотел заниматься системой контроля версий (СКВ) и чувствовал что это была просто наименее интересная штука в компьютерном мире (возможно, за исключением баз данных ;^), и я страстно ненавидел все такие системы. Но тогда появился БитКипер (BK) и, действительно, изменил то, как я рассматривал контроль исходного кода. BK сделал правильно многие вещи. И возможность держать у себя локальную копию репозитория и распределённое слияние кода были хорошими штуками. Важная особенность распределённой модели контроля версий заключается в том, что она исключает одну из самых серьёзных проблем СКВ — политику того, кто может делать изменения. BK показал что ты можешь избежать это просто раздав всем репозиторий. Но BK имел и свои собственные проблемы; несколько технических решений приводили к проблемам (переименование было болезненным), но наихудшим был факт того, что поскольку BK не распространялся вместе с открытым кодом, то было и много людей, которые не хотели им пользоваться. Так что мы закончили тем, что было несколько основных разработчиков, использующих BK, который был бесплатен для использования в проектах с открытым кодом, но это никогда не стало общепринятым. Так что это (ВК) помогало в разработке ядра, но там всё равно оставались больные моменты.
Это пришло мне в голову тогда, когда Tridge (Andrew Tridgell) начал реверс-инжиниринг достаточно простого протокола BK, что было нарушением правил использования BK. Я потратил несколько недель (месяцев? Так я себя и чувствовал), пытаясь быть посредником между Tridge и Larry McVoy, но в итоге стало ясно, что это просто не работало. Итак, на каком-то этапе я просто решил, что я не могу больше продолжать использовать BK, но я также и не хочу возвращаться к худшим дням, которые были до появления BK. Грустно, что тогда были и другие инструменты для СКВ, которые в какой-то мере пытались использовать распределённую модель разработки, но ни один из них не работал хорошо в случае удалённого использования. У меня были свои требования к производительности, которые даже приближённо не могли быть удовлетворены тем, что было доступно; и я также волновался по поводу целостности кода и процесса разработки, так что я решил написать своё.
Как ты к этому подошёл? Ты писал его все выходные или только в обычное время?
Торвальдс: Эх. Вы, кстати, можете видеть как всё приняло форму в репозитории исходного кода Git, за исключением первого дня или что-то около того. День был потрачен на то, чтобы Git стал сам себя хостить так, чтобы можно было начать коммитить в Git используя Git. Поэтому первый день или что-то около того не присутствует в истории, но всё остальное — там. Основная работа была проведена, в основном, в течение дневного времени, но есть пара полуночных записей и пара — после двух часов ночи. Наиболее интересное, это то, как быстро это приняло форму. Самый первый коммит в дереве Git — это не много кода, но это делало основное — достаточное для того, чтобы закоммитить себя самого. Трюк был не столько в кодинге, сколько в том, чтобы понять как Git должен упорядочивать данные.
Я бы хотел подчеркнуть, что несмотря на то, что это было собрано в течение десяти дней или что-то вроде этого (в течение которых я сделал свой первый Git коммит в репозиторий ядра Линукса), это не было ни в какой мере сумасшедшим кодингом. Объём этого раннего кода достаточно мал, всё зависело от правильной реализации основных идей. И поэтому, я некоторое время «перемалывал» прежде чем весь проект был запущен. Я видел проблемы других. Я видел то, что я хотел избежать.
Выросло ли это (Git) до уровня твоих ожиданий? Как хорошо это (Git) работает по твоим оценкам? Есть ли какие-либо ограничения?
Торвальдс: Я очень доволен Git. Он работает исключительно хорошо с кодом ядра и по-прежнему следует моим ожиданиям. Что интересно, так это то, что он принял так много других проектов. К удивлению быстро, в конце концов. Существует много инертности в переключении от одних СКВ к другим; только взгляните как долго оставались в использовании CVS и даже RCS, но на каком-то этапе Git принял и их дела.
Как ты думаешь, почему это (Git) было так широко принят в использование?
Торвальдс: Я думаю, что многие люди были раздражены теми же самыми проблемами, которые заставили меня ненавидеть СКВ. И, хотя, было много проектов в попытке исправить одну или две мелких проблемы, которые выводили людей из себя, в действительности не существовало ничего такого как Git, что действительно помогло больше не брать больших проблем себе в голову. Даже когда люди не понимали насколько важна распределённая модель разработки (и много людей боролись с этим), то как только они осознавали, что это позволяет делать более лёгкие и надежные резервные копии и позволяет людям делать свои собственные репозитории без необходимости задумываться о политике разрешения записи в определённый репозиторий, они никогда не смотрели назад.
Будет ли Git существовать всегда или ты предугадываешь пересмотр СКВ в течение следующих десяти лет? Будешь ли ты одним из тех, кто напишет это?
Торвальдс: Нет, я не буду тем, кто это напишет. И, возможно, мы увидим что-то новое в течение десяти лет, но я гарантирую что, это будет нечто достаточно Git-подобное. Не в смысле что в Git всё правильно, но в том смысле что Git имеет основные возможности прямо внутри, которые другие СКВ ранее никогда не имели.
Без фальшивой скромности 😉
Почему Git работает так хорошо в Линуксе?
Торвальдс: Ну, Git был создан для нашей работы, потому он часть неё. Я уже упоминал распределённую модель много раз, но имеет смысл ещё раз вспомнить о ней. Но Git был также создан для того, чтобы быть достаточно эффективным для большого проекта как Линукс, и написан чтобы делать то, что люди считали сложной задачей перед появлением Git — потому что это те вещи, которые я делаю каждый день.
Просто для примера: понятие слияния рассматривалась как что-то очень болезненное и сложное во многих СКВ. Тебе бы приходилось планировать свои сливания, потому, что они были серьёзным делом. Это не устаивает меня, так как я, обычно, делаю десятки слияний в день когда нахожусь в во временном окне слияния, и даже при этом, рабочая нагрузка не должна быть в слиянии, а в тестировании кода. Слияние само по себе занимает пару секунд, гораздо больше занимает написание объяснения слияния.
Итак, Git был построен и написан для моих требований. Так и происходит.
Торвальдс: Ну я думаю, что так было сначала, но это больше не так. Есть несколько причин того, что люди так себя чувствуют, но я думаю что только одна причина осталась. Та, что осталась, очень проста: «это можно делать такими разными способами».
Можно делать много вещей при помощи Git, и многие из правил относительно того, что ты должен делать происходят не от технических ограничений, а оттого, что так работает неплохо, когда приходится взаимодействовать с другими людьми. Git является очень мощным набором инструментов, что может перегружать вначале, но это также значит, что ты можешь делать часто те же самые или похожие вещи разными путями и все они сработают. В общем, лучший способ изучить Git, вероятно, заключается в том, чтобы просто делать простые вещи и даже не смотреть на другие вещи до тех пор, пока ты не будешь уверенным в отношении основ.
Существуют несколько исторических причин для восприятия Git как сложной вещи. Одна из них — то, что это действительно было сложным. Те люди, которые начали использовать Git раньше всех для работы с ядром Линукса, действительно должны были научиться использовать достаточно непростой набор скриптов чтобы заставить всё работать. Все силы были направленны на то, чтобы заставить работать основную технологию и совсем немного — на то, чтобы сделать это легким или очевидным. Так и Git, естественно, имел репутацию которая предусматривала знание того, что ты делал ранее. Но это было, в основном, правдой только в течение первых шести месяцев или года.
Другая причина того, что люди считали, будто Git — сложная штука в том, что Git очень своеобразен. Есть люди, которые пользовались такими вещами как CVS на протяжении десятилетия или двух, и Git — не CVS. Даже не похожи. Разные концепции. Команды различаются. Git никогда не старалась выглядеть как CVS, как и наоборот. И, если ты пользовался CVS-подобной системой в течение длительного времени, то создаётся впечатление сложности и беспричинного отличия Git. Люди были оттолкнуты странной системой номеров версий. Почему номер версии Git «1.3.1», а не так как приятно сделано с увеличивающимися номерами в версиях CVS? Почему там (в Git) странный и страшный 40-символьный номер в шестнадцатеричной системе исчислений?
Могла бы скорость разработки ядра Линукса расти с существующей скоростью без Git? Почему?
Торвальдс: Ну, «без git» — конечно. Но это бы предусматривало то, что кто-то бы написал некий эквивалент Git: некую распределённую СКВ, которая была бы также эффективна, как и Git. Мы определённо нуждались в чём-то вроде Git.
Какое твое текущее мнение о GitHub?
Торвальдс: Github является исключительным ресурсом для хостинга; у меня совсем нет ничего против него. Жалобы, которые у меня были, заключались в том, что GitHub как платформа разработки — коммиты, пулл-реквесты, отслеживание истории проблем и так далее — не работает достаточно хорошо. Это даже не близко, не походит для чего-то вроде ядра Линукса. Слишком ограниченно.
Это частично от того, как ядро Линукса разработано, но частично и потому, что интерфейсы GitHub активно стимулируют к плохому поведению. Коммиты, сделанные на GitHub содержали комментарии этих коммитов и так далее, просто потому что веб-интерфейс на GitHub активно стимулировал к плохому поведению. Они исправили некоторые из этих вещей, так что, вероятно, работает лучше, но это никогда не будет подходящим для чего-то вроде ядра Линукса.
Какое самое интересное использование Git и/или GitHub ты встречал?
Торвальдс: Я очень рад, что он (Git) так облегчил запуск новых проектов. Хостинг проекта раньше доставлял много боли, но с появлением Git и GitHub сделать любой маленький проект стало так просто. Не важно, что за проект, важно то, что ты можешь сделать.
У тебя есть побочные проекты «в рукаве»? Какие-нибудь замечательные проекты, которые будут доминировать в разработке программного обеспечения на следующие годы?
Торвальдс: Ничего не планируется. Но я дам тебе знать если эти планы поменяются.
p.s.: советы и пожелания к переводу приветствуются с целью улучшения качества перевода.
1 @spmbt предложил альтернативный и не менее убедительный перевод этого предложения: «Прежний опыт работы с CVS уходит.»
2 @LampTester внизу упомянул лучший перевод этой фразы: «Git нарочно сделан так, чтобы вы почувствовали себя более тупым, чем есть».
На чем написан github
Введение в систему контроля версий Git и систему для совместной разработки GitHub
На проработку материала и выполнение заданий у вас есть 2 недели.
Что такое контроль версий, и зачем он вам нужен? Система контроля версий — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов. Чаще всего в системах контроля версий хранятся исходные коды программ, но на самом деле под версионный контроль можно поместить файлы практически любого типа.
Система контроля версий даёт возможность возвращать отдельные файлы к прежнему виду, возвращать к прежнему состоянию весь проект, просматривать происходящие со временем изменения, определять, кто последним вносил изменения во внезапно переставший работать модуль, кто и когда внёс в код какую-то ошибку, и многое другое. Вообще, если, пользуясь системой контроля версий, вы всё испортите или потеряете файлы, всё можно будет легко восстановить. Вдобавок, накладные расходы за всё, что вы получаете, будут очень маленькими.
Git (произносится «гит») — распределённая система контроля версий. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. Основные требования к новой системе были следующими:
С момента рождения Git развивался и эволюционировал, становясь проще и удобнее в использовании, сохраняя при этом свои первоначальные качества. Он невероятно быстр, очень эффективен для больших проектов, а также обладает превосходной системой ветвления для нелинейной разработки
GitHub (произносится «гитхаб») — крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Основан на системе контроля версий Git и разработан на Ruby on Rails и Erlang. Сервис абсолютно бесплатен для проектов с открытым исходным кодом и предоставляет им все возможности (включая SSL), а для частных проектов предлагаются различные платные тарифные планы.
Создатели сайта называют GitHub «социальной сетью для разработчиков». Кроме размещения кода, участники могут общаться, комментировать правки друг друга, а также следить за новостями знакомых. С помощью широких возможностей Git программисты могут объединять свои репозитории — GitHub предлагает удобный интерфейс для этого и может отображать вклад каждого участника в виде дерева.
Первый частный репозиторий был создан 12 января 2008. К концу 2011 года в проекте уже было зарегистрировано более миллиона пользователей и более двух миллионов репозиториев. По состоянию на март 2017 года на сайте существовало более 58 миллионов репозиториев.
Интересные факты про Git и GitHub
Этот раздел будет дополняться студентами в процессе выполнения заданий
Автор Git, Линус Торвальдс, со своей командой при работе над ядром Linux бесплатно использовали коммерческую распределённую систему контроля версий BitKeeper. В 2005 году отношения между сообществом разработчиков ядра и компанией, разрабатывавшей BitKeeper, испортились, и право бесплатного пользования продуктом было отменено. Это и подтолкнуло разработчиков Linux разработать собственную систему, основываясь на опыте, полученном за время использования BitKeeper. Так и появился на свет Git.
К марту 2017 года на сайте существовало более 58 миллионов репозиториев, в том числе официальные репозитории многих IT-компаний (Facebook, Twitter, Google и др.).
GitHub можно назвать великим эквалайзером. У вас может не быть возможности получить работу в Австралии из Индии, но ничто не мешает вам работать с австралийцами из Индии с помощью GitHub.
Около двух третей сотрудников GitHub работают удаленно.
Горячие клавиши GitHub
Задания для самостоятельной работы
About
Введение в систему контроля версий Git и систему для совместной разработки GitHub
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
GitHub
| Type | Частная компания |
|---|---|
| Founded | 8 февраля 2008 года |
| Headquarters | Сан-Франциско, Калифорния, США |
| Area served | По всему миру |
| Founder(s) | Том Престон-Вернер Крис Ванстрас PJ Хиетт |
| CEO | Крис Ванстрас |
| Key people | PJ Хиетт (COO) |
| Industry | Программное обеспечение |
| Employees | 745 [источник 1] |
| Website | https://github.com/ |
| Written in | Ruby |
| Alexa rank |  63 (апрель 2018 [update] ) [источник 2] |
| Type of site | Git-репозиторий хостинг сервис |
| Registration | Необязательна (создание и объединение проектов) |
| Users | 26 миллионов пользователей (по состоянию на март 2017) |
| Available in | Английский язык |
| Launched | 10 апреля 2008 года |
| Current status | Активный |
GitHub предлагает тарифные планы, как для частных репозиториев, так и для бесплатных учетных записей, которые обычно используются для размещения проектов с открытым исходным кодом. На апрель 2017 года сообщается, что количество пользователей GitHub составляет почти 20 миллионов, а количество репозиториев приблизилось к отметке 57 миллионов, что делает GitHub самым крупнейшим хранилищем исходного кода в мире.
GitHub имеет собственный талисман – осьмикот (в оригинале «Octocat»). Это кошка по имени Мона с пятью щупальцами и человекоподобным лицом.
Содержание
История компании
24 февраля 2009 года члены группы GitHub объявили в беседе с Yahoo! что в течение первого года пребывания в сети GitHub собрал более 46 000 открытых репозиториев, из которых 17 000 были сформированы только в предыдущем месяце. В то время около 6200 хранилищ были раздвоены по крайней мере один раз и 4600 были объединены. 5 июля 2009 года компания объявила, что сайт теперь используют более чем 100 000 пользователей. 27 июля 2009 года в другом разговоре, выпущенном в Yahoo!, Том Престон-Вернер объявил, что GitHub расширился для того, чтобы разместить 90 000 уникальных открытых репозиториев, 12 000 из которых были раздвоены хотя бы один раз, в общей сложности насчитывалось 135 000 репозиториев. [источник 5]
25 июля 2010 года GitHub отметил свой 1 миллион репозиториев. 20 апреля 2011 года GitHub объявил, что количество репозиториев достигло 2 миллионов. [источник 6] On April 20, 2011, GitHub announced that it is hosting 2 million repositories. [источник 7] 2 июня 2011 года ReadWriteWeb сообщила, что GitHub превзошел SourceForge и Google Code в общем количестве фиксаций за период с января по май 2011 года. 9 июля 2012 года Питер Левин (Peter Levine), генеральный партнер инвестора GitHub Андреессен Горовиц, заявил, что доходы GitHub выросли на 300% по сравнению с 2008 годом. 16 января 2013 года компания объявила, что прошла отметку в 3 миллиона пользователей, и что в ней было размещено более 5 миллионов репозиториев. 23 декабря 2013 года GitHub объявил, что преодолел отметку в 10 миллионов репозиториев. В июне 2015 года GitHub открыл офис в Японии, который является его первым офисом за пределами США. 29 июля 2015 года компания оценивалась примерно в 2 миллиарда долларов. [источник 8]
В 2016 году GitHub занял 14 место в списке Forbes Cloud 100. [источник 9] С первым выпуском 21 июля 2017 года Brave web browser предлагает Github как одну из своих поисковых машин по умолчанию. 28 февраля 2018 года GitHub стал жертвой крупнейшей атаки с использованием DDoS’а в истории, достигнув пика около 1,35 терабит в секунду.
Цензура
3 декабря 2014 года GitHub был заблокирован в России на несколько дней из-за учебников по самоубийствам, опубликованными пользователями. [источник 10]
31 декабря 2014 года GitHub был заблокирован в Индии (наряду с другими 31 |веб-сайтом) по сравнению с содержанием ISIS, размещенным пользователями. [источник 11] 10 января 2015 года GitHub был разблокирован. 12 сентября 2015 года, GitHub был вновь заблокирован по всей Индии. Однако вскоре сайт был разблокирован.
26 марта 2015 года GitHub стал жертвой массовой DDoS атаки, которая длилась более 118 часов. Атака, которая, как предполагает, исходила из Китая, в основном предназначалась на контент, размещенный пользователями GitHub, описывающего методы обхода интернет-цензуры.
8 октября 2016 года доступ к GitHub был заблокирован турецким правительством, чтобы предотвратить утечку электронной почты взломанной учетной записи, принадлежащей министру энергетики страны.
На GitHub размещают свои открытые проекты федеральные агентства США.
Обвинения
В марте 2014 года программист GitHub Джули Энн Хорват утверждала, что основатель и главный исполнительный директор Том Престон-Вернер и его жена Тереза занимались преследованием против нее, что привело к ее уходу из компании. В апреле 2014 года GitHub опубликовал заявление, опровергающее утверждения Хорват. Однако, после внутреннего расследования, GitHub подтвердил претензии. Генеральный директор GitHub Крис Ванстрат написал в блоге компании: «Расследование показало, что Том Престон-ВернерS в качестве генерального директора GitHub действовал ненадлежащим образом, включая враждебное поведение, игнорирование жалоб на рабочем месте, понижения продуктивности из-за присутствия его супруги на рабочем месте и не соблюдение соглашения о том, что его супруга не должена работать в офисе». Престон-Вернер затем ушел из компании. В 2017 году было выдвинуто больше заявлений о дискриминационном и неприемлемом поведении в GitHub разработчиком, который был завербован обещаниями GitHub по улучшению его разнообразия и вовлеченности.
Талисман
GitHub переименовали Octopuss в Octocat, и зарегистрировали товарный знак с новым именем. Позже GitHub нанял иллюстратора Камерона МакЭфи (Cameron McEfee), чтобы адаптировать Octocat для различных целей на веб-сайте и рекламных материалах. С тех пор МакЭфи и различные пользователи GitHub создали сотни вариаций персонажа.
Структура Организации
GitHub, Inc. изначально была плоской организацией без менеджеров среднего звена; другими словами, «каждый сотрудник является менеджером». Сотрудники могли сами выбирать работу над проектами, которые их интересуют (открытое распределение). Однако заработная плата устанавливается руководителем.
С 2014 года GitHub, Inc. ввела в свою структуру среднего слой менеджмента.
Финансирование
Сервисы
GitHub
Проекты в GitHub можно получить и обработать с помощью стандартного интерфейса командной строки Git, и все стандартные команды Git работают с ним. GitHub также позволяет зарегистрированным и незарегистрированным пользователям просматривать общедоступные репозитории на сайте. Несколько настольных клиентов и плагинов Git также были созданы GitHub и другими третьими сторонами, которые интегрируются с данной платформой.
На сайте предусмотрены функции, подобные социальным сетям, такие как feeds, followers, вики (с использованием программного обеспечения wiki под названием Gollum) и график социальной сети, чтобы показать, как разработчики работают над своими версиями хранилища и какой fork новейший.
Для open-souce проектов использование сайта бесплатно. При необходимости иметь приватные репозитории, есть возможность перейти на платный тарифный план.
Пользователь должен создать учетную запись для внесения контента на сайт, но публичные репозитории могут просматриваться и загружаться кем угодно. С зарегистрированной учетной записью пользователи могут обсуждать, управлять, хранить репозитории, отправлять вклады в хранилища других и просматривать изменения в коде.
Программное обеспечение, которое запускает GitHub, было написано с использованием Ruby on Rails и Erlang разработчиками GitHub, Inc. Крисом Вантратом, PJ Хиеттом и Томом Престоном-Вернером.
Возможности
Создатели сайта называют GitHub «социальной сетью для разработчиков». Кроме размещения кода, участники могут общаться, комментировать правки друг друга, а также следить за новостями знакомых. С помощью широких возможностей Git программисты могут объединять свои репозитории — GitHub предлагает удобный интерфейс для этого и может отображать вклад каждого участника в виде дерева. (Пошаговая инструкция по работе git и github для студентов [источник 14] ) Пользователи могут создавать неограниченное число репозиториев, для каждого из которых предоставляется wiki, система issue tracking-а, есть возможность проводить code review и многое другое.
Для проектов есть личные страницы, небольшие Вики и система отслеживания ошибок. Прямо на сайте можно просмотреть файлы проектов с подсветкой синтаксиса для большинства языков программирования.
Помимо исходного кода, GitHub поддерживает следующие форматы и функции:
Для проектов есть личные страницы, небольшие Вики и система отслеживания ошибок. Прямо на сайте можно просмотреть файлы проектов с подсветкой синтаксиса для большинства языков программирования.
Подробнее о некоторых возможностях GitHub.
Статистика языков программирования
На главной странице репозитория в виде цветной полосы отображается статистика используемых в данном репозитории языков. Если щёлкнуть по ней, отобразятся доли в процентах.
GitHub предоставляет множество метрик для отслеживания работы, происходящей в репозитории (хранилище, где хранятся и поддерживаются какие-либо данные). Соответствующие инструменты мониторинга находятся на вкладках Pulse и Graph. Pulse показывает, что происходило в репозитории в определённый период времени. В разделе Graph разные показатели отражены в виде графиков. У владельцев репозиториев во вкладке Graph также появляется подпункт Traffic. По большому счёту это мини google analytics для репозитория: в нём можно отслеживать, сколько пользователей было в вашем репозитории и откуда они пришли.
Создание нового репозитория
При создании репозитория можно сразу выбрать, какой gitignore-файл необходим, какая лицензия будет у проекта и нужна ли заготовка для readme-файла. Если вашего типа проекта нет в списке gitignore, тогда следует эту ситуацию улучшить и предложить пулл-реквест в репозиторий gitignore GitHub.
Github умеет хостить статические сайты. Это очень удобно, если вам надо сделать web-документацию для вашего проекта или промо-сайт. Многие используют гитхаб для ведения личных блогов. В самом простом случае достаточно создать в вашем github-репозитории ветку gh-pages с index.html внутри. Страница будет доступна по адресу в таком формате: http(s)://.github.io/
Возможно использование GitHub не только для разработки и управления кодом, но и для обратной связи с пользователями. На вкладке «Issue» пользователи могут оставлять сообщения о проблемах, с которыми они столкнулись при использовании вашего продукта.
Начало работы с GitHub
Вы можете сразу же инициализировать репозиторий, создав файл Readme, для этого нужно отметить галочку «Initialize this repository with a README» внизу страницы. Также можно выбрать лицензию. Когда все будет готово, выберите «Create project», будет создан новый проект с файлом README, в котором находится описание и файлом лицензии.
В зависимости от того, как этот термин используется, репозиторий может быть доступен пользователям или может быть местом, из которого получаются конкретные базы данных, файлы или документы для дальнейшего перемещения или распространения в сети. Репозиторий может быть просто агрегацией данных в какое-то доступное место хранения и может подразумевать некоторую способность выборочно извлекать информацию.
Ветки Github позволяют работать с несколькими версиями проекта одновременно. По умолчанию при создании репозитория создается ветка master, это основная рабочая ветка. Можно создать дополнительные ветки, например, для того, чтобы тестировать программное обеспечение перед тем, как оно будет опубликовано в ветке master. Таким образом, можно одновременно разрабатывать продукт и предоставлять пользователям стабильную версию. Также можно создавать отдельные ветки для версии программы для разных систем.
Любые изменения файлов на Github делаются с помощью коммитов (commit). Коммит выполняется путем внесения самих исправлений и описания этих исправлений. Это необходимо для того, чтобы вы знали что и когда вы меняли, а также позволяет легко отслеживать работу команды. То есть можно внести изменения в несколько файлов, а затем их зафиксировать.
Запрос слияния или Pull Request — это возможность, благодаря которой любой разработчик может попросить другого, например, создателя репозитория просмотреть его код и добавить его в основной проект или ветку. Инструмент работы с запросами слияния использует инструмент сравнения diff, поэтому вы можете увидеть все изменения, они будут подчеркнуты другим цветом. Pull Request можно создать сразу же после создания коммита.
Лицензирование репозиториев
Условия обслуживания GitHub не требуют публичных программных проектов, размещенных на GitHub, для соответствия определению Open Source. По этой причине очень важно, чтобы пользователи и разработчики намеревались использовать часть программного обеспечения, найденного в GitHub, для чтения лицензии на программное обеспечение в репозитории (обычно в файле верхнего уровня, называемом «LICENSE», «LICENSE.txt» или аналогично), чтобы определить, удовлетворяет ли он их потребностям. В Условиях обслуживания говорится: «Если вы публично просматриваете свои репозитории, вы соглашаетесь разрешать другим просматривать и форкировать свои репозитории».
GitHub Enterprise
GitHub Enterprise похожа на открытую службу GitHub, но предназначена для использования крупными командами разработчиков программного обеспечения для предприятий, которое хочет разместить свои репозитории за корпоративным брандмауэром.
Gists
Gist — это git-репозиторий без поддержки директорий. Обычно его используют для хранения кусков кода и черновиков; там также можно найти полноценные туториалы и статьи. GitHub также управляет другими сервисами: сайт в стиле pastebin под названием Gist, предназначенный для размещения фрагментов кода (собственно сам GitHub предназначен для размещения больших проектов) и услуги хостинга слайдов под названием Speaker Deck.
Том Престон-Вернер представил тогда еще новую функцию Gist на панк-рок-конференции Ruby в 2008 году. Gist опирается на традиционную простую концепцию pastebin, добавляя управление версиями для фрагментов кода, простое наложение и шифрование SSL для личных вставок. Поскольку каждый «gist» имеет свой собственный репозиторий Git, несколько фрагментов кода могут содержаться в одной вставке, и их можно вытащить с помощью Git. Кроме того, раздвоенный код можно отбросить назад к оригинальному автору в виде патча, поэтому gists (пасты) могут стать больше похожими на мини-проекты. [источник 19]
Gist можно использовать на сторонних ресурсах. Многие используют его для подсветки синтаксиса кусков кода в статических блогах или на Medium.
Образовательная программа
GitHub запустил новую программу под названием GitHub Student Developer Pack, чтобы предоставить студентам бесплатный доступ к популярным инструментам и службам сервиса. GitHub для запуска программы сотрудничал с Bitnami, Crowdflower, DigitalOcean, DNSimple, HackHands, Namecheap, Orchestrate, Screenhero, SendGrid, Stripe, Travis CI и Unreal Engine.
Служба поддержки GitHub
GitHub также предоставляет некоторое программное обеспечение в качестве сервисной интеграции для добавления дополнительных функций в проекты. В данные услуги входят: