На чем написан гитхаб
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 сейчас так популярен.
Стартап с нуля: история Github
Это интервью Криса Уонстрота, CEO и сооснователя Github. Данное интервью — часть серии “Bootstrapped, Profitable, & Proud” о компаниях с выручкой более миллиона долларов, обошедшихся без венчурного финансирования на старте и приносящих доход.
Чем занимается ваша компания?
Мы предоставляем услуги открытого и закрытого хостинга проектов на базе распределённой системы контроля версий git. Наша цель — максимально упростить взаимодействие разработчиков, особенно в сфере открытого кода. Внесение изменений в какой-либо открытый проект не должно отвлекать разработчика от кода, процесс должен быть максимально прозрачен. Работа с коллегами, будь они в той же комнате, или на другом конце земного шара, должна быть сконцентрирована на развитии проекта, а не на борьбе с недостатками используемых инструментов.
Также мы проводим семинары по git, предоставляем материалы и спонсируем открытые проекты.
Как вы объясняете “обычным” людям (родственникам, друзьям), чем занимается ваша компания?
GitHub — это как Википедия для программистов. Можно править программы, смотреть историю правок, читать старые версии из любой точки мира, единственное отличие от энциклопедии в том, что работа идёт над исходным кодом, а не над текстом статей. Бизнес использует Github для разработки программного обеспечения и сетевых ресурсов, программисты делятся своим трудом и используют труд других.
Модель бизнеса проста: если код открыт для всех, то за это не надо платить. Если же код является важным для функционирования компании и открыть его нельзя, то для работы с ним придётся внести небольшую плату.
Слева направо: Рик Олсон, Том Престон-Вернер, и Крис Уонстрот. (Фото Дэйва Файрама).
Много ли зарабатываете на курсах?
Семинары составляют не самую большую часть нашей выручки, но дают возможность общаться с клиентами напрямую, укреплять связи, узнавать об их пожеланиях напрямую. Скотт Чейкон (наш гит-гуру), проводит семинары по всему миру.
Поддержка открытой разработки и git полезна для индустрии в целом, но мы делаем так просто потому, что нам так нравится. Мы ценим желание наших разработчиков участвовать в открытых проектах.
Как вы начали делать Github?
Первый прототип мы начали писать по выходным. Том Престон-Вернер и я сидели в спорт-баре после встречи местной программистской тусовки, тогда он и поделился со мной идеей сделать простой хостинг проектов на git. Ресурс, на котором будет легко поделиться кодом, освоиться с git, эдакий хаб. Этот инструмент делался не просто так, а по необходимости: нам обоим нравился git, а общедоступной возможности делиться кодом тогда не было. Том решил, что мне будет интересно разрешить эту проблему, так и получилось.
Мы встречались по субботам, собирая по кусочкам наш сайт. Мы завтракали, обсуждали планы, потом приступали к работе. Том указывал, как должны выглядеть страницы, я же, в основном, занимался реализацией. Как только основной функционал был готов, мы сразу же внедрили GitHub на моей основной работе, другом стартапе, который мы делали вместе с PJ Hyett. Разрабатывать GitHub стало проще, ведь и он, и я пользовались им ежедневно и легко понимали, чего не хватает.
Одну вещь при разработке своего предыдущего стартапа, Gravatar, Том уяснил точно: предоставлять ресурсоёмкий сервис безо всякой дополнительной платы — очень накладно. В том случае это был хостинг картинок с большим трафиком, здесь же это был git. Хранение и обмен кодом могли влететь в копеечку. Нужно было найти способ заработка.
Подумав об этом, мы запустили бету для наших друзей. И сайтом сразу же стали пользоваться! Было просто создать как открытый, так и закрытый проект, все стали размещать там свой рабочий код – и мы с PJ тоже так делали. Через некоторое время, люди начали обращаться к нам с вопросом, нужно ли платить за закрытые репозитории.
И тогда мы поняли, как наилучшим образом монетизировать Github, что помогло в дальнейшем сделать это не просто развлечением, а бизнесом. Мы стали предоставлять всем участникам неограниченные возможности по размещению открытого кода, а плату стали брать только за закрытый. То есть, платили только те, кто хотел платить.
PJ стал сооснователем Github и предыдущий наш проект был заброшен. Теперь нашим проектом стал Github. Сайт был открыт для публики 10 апреля 2008 г., сервис существует и активно пользуется спросом с тех пор.
Много ли денег потребовалось для запуска? Как их нашли?
Сперва, конечно, купили домен в Slicehost, заказали немного графики. Несколько сотен долларов на регистрацию фирмы удалось наскрести, просто скинувшись всем вместе.
Большие затраты уходили на личные расходы, ведь необходимо было жить и развивать бизнес. PJ и я занимались консультациями, Том работал полный день. По мере развития бизнеса, мы придумали подход, как постепенно перейти к постоянной зарплате.
Мы выплачивали из дохода фирмы каждому небольшую сумму, если продажи шли хорошо, эта сумма увеличивалась. Постепенно, наш доход приблизился к полноценной зарплате и стал достаточным для постоянной работы.
Сперва всё шло очень хорошо. Потом были несколько месяцев, когда продажи совсем не росли, но коллективным трудом нам удалось решить и эту проблему.
Насколько ваш бизнес успешен?
Мы нанимаем замечательных людей и хорошо оплачиваем их труд, не привлекая финансирование из дополнительных источников. С этой точки зрения, мы очень успешны.
По мере роста численных показателей (у нас сотни тысяч пользователей, десятки тысяч из которых платят, миллион репозиториев – тысяча новых каждый день). Всего этого мы добились за два года.
В каких условиях вы работаете?
Работаем мы в удобное нам время. Мы не нанимали менеджеров, мы сами можем определить, какие у нас приоритеты, задачи и цели. Тот, кому та или иная задача наиболее важна, занимается её реализацией.
Это может показаться странным, но такой подход действительно работает. Это отличный способ почувствовать интерес людей к тому, что они делают. Если какая-то вещь никому не нужна, никто ей и не займётся. Мы все сами пользуемся нашим продуктом, поэтому сразу становится понятно, что не работает и чего не хватает. Мы стараемся поддерживать неформальные отношения с клиентами, это также помогает нам выбирать приоритеты.
Мы работаем распределённо. У нас есть офис в центре Сан Франциско, но, как правило, все находятся там, где им удобно и работают когда удобно. Настоящий офис — групповой чат в Campfire. Сперва это было по необходимости – денег на офис просто не было, поэтому мы сидели дома и в кофейнях, а связывались через интернет. Теперь же стало понятно, что так просто удобнее. Сотрудники Github могут провести день в офисе, сесть на самолёт, и без проблем продолжить работу на следующий день. Нет необходимости отрабатывать определённый объём в часах, просто нужно решать выбранные задачи.
Самое важное — доводить дело до конца. Нам везёт, что мы работаем над веб-приложением (в основном), это означает, что изменения вносятся легко и быстро. Мы уже поняли, что лучше выпустить хоть что-то сейчас, а ошибки исправить по ходу, пользователи сами подскажут, где проблема. Старайтесь как можно раньше пускать новые фичи в продакшен.
Почему важно сначала выпускать продукт, а уже потом править ошибки? Есть простой пример?
Никогда не удаётся сделать что-то сразу и хорошо – это естественная особенность человека, понимание её — уже большое преимущество. Ранний пуск позволяет узнать, как пользователи воспринимают данное нововведение. Нет ли более важных проблем, которые ещё не решены? Не превзошёл ли продукт ожидания? Столкнулся ли кто-то с проблемой, которую можно было предположить? Пытаясь продумать всё это заранее, можно просто потеряться.
Иногда трудно понять, что важнее, проще дать пользователям возможность выбрать самим. Определите, что более всего необходимо и сделайте это.
Кроме того, реализация и выкатка — само по себе интересно. Если есть дедлайн — это работа, иначе это своего рода соревнование.
Последний раз я участвовал в выкатке функциональности для организаций. Как только что-то начало работать, мы пригласили своих друзей поучаствовать в бете. Наблюдение за их работой помогало не только скорее исправлять ошибки, но и строить и улучшать модель.
Каковы цели компании?
Как сейчас, так и через 5 лет, мне хотелось бы поддерживать хорошие отношения с коллегами и не терять интерес к работе. Мы хотим расти, больше зарабатывать и больше нанимать, удовлетворяя потребности пользователей, но самое важное — получение удовольствия от самого процесса. Надеюсь, мы никогда не устанем работать над Github, а людям никогда не надоест им пользоваться.
Пока у нас есть такие люди, которые наслаждаются работой, и делают хороший продукт для себя, проблем с удовлетворением просьб клиентов не будет.
Github может визуализировать процесс изменения кода. Здесь цветом отмечен вклад разных участников в проект homebrew – ширина пропорциональна объёму изменений.
Необходимость выбора встала раньше, чем я могу предположить. Я мог либо стать сотрудником Microsoft и получить бонус, либо уйти и заняться вплотную Github… В конце концов, я, как и Индиана Джонс, не стал отказываться от поисков Грааля, от возможности делать то, что действительно любишь, вне зависимости от стабильности альтернативных условий. Когда я стану старым, оглянувшись назад я смогу сказать “какие классные штуки я делал!”, а не “как мне было комфортно и безопасно.”
В общем случае мы полагаемся на себя, а не на помощь советчиков. Каждое решение должно быть обдумано и обосновано перед тем, как принято. То, что когда-то в похожих условиях определённое решение привело к успеху (или не привело) ещё не означает, что стоит действовать именно таким образом.
Многие люди предлагали нам отказаться от семинаров по git (“куда развиваться дальше, время же ограничено”), или не предлагать локальное размещение служб Github, но оба продукта сейчас существуют и радуют наших клиентов. Все компании разные, мы очень внимательно относимся к наблюдениям и советам клиентов, но полагаемся, всё же, на себя.
Какая самая трудная проблема была в компании?
Первый год напомнил тот этап подростковой жизни, когда осознаёшь себя. Github был просто развлечением, он не был основным проектом, от него не было больших ожиданий. Мы просто хотели делать что-то классное. Хотелось бы сказать, что этого достаточно, но должно быть видение в перспективе, философия. Каждый сотрудник (по крайней мере, сооснователь) должен быть на одной волне. Проблема только в том, чтобы поймать эту волну.
Мы делаем веб-приложение, или просто контроль версий? Какую зарплату платить сотрудникам? Стоит ли выступать на конференциях? Как подходить к вопросу техподдержки? Это, вроде бы, разные вопросы, но ответы на все из них определяются политикой компании. Когда понятно, к чему мы стремимся, на данные вопросы сразу появляются ответы. Но первое время приходилось помногу задумываться.
Философия компании записана в документах? Или люди сами понимают, как вы работаете?
Мы обсуждаем это на собеседованиях и подходим к этому очень серьёзно. Каждый потенциальный сотрудник Github должен понимать, что представляет из себя работа и понимать, что ему это комфортно. Разговоры за обедом о культуре, философии — часть рабочего процесса.
Некоторых сотрудников мы нанимали только исходя из их технической компетенции, оставив в стороне взгляды на жизнь. И мы не смогли сработаться. Поэтому не меньшее внимание при поиске людей мы уделяем жизненной позиции.
Офис (Фотография Дэйва Файрама).
Что ещё примечательного в вашем деле?
Двое из трёх сооснователей не закончили университет.
Как вы считаете, это совпадение?
Не думаю – Том и я оставили университет, чтобы скорее начать работать в индустрии. У него был стартап, у меня работа по заказу, но нам обоим хотелось создавать. Было ясно, что когда-нибудь мы сделаем что-то своё.
PJ получил диплом в области computer science, но уже в день выдачи дипломов он летел в Сан-Франциско. Он работал в CNET (где мы и встретились) ещё до окончания университета, а собственные проекты реализовывал на протяжении всего времени обучения.
У меня нет определённого мнения о том, нужно получать высшее образование или нет, замечательные люди примечательны не своим образованием, а сообразительностью, чувством юмора, упорством, но причины, по которым в универе мне было некомфортно схожи с тем, что я бы испытал в большой компании. Большинство людей даже не догадываются, насколько это удобно — работать на себя. Работа должна нравиться.
Какой совет вы бы дали начинающим свой бизнес?
Работайте, смотрите в будущее. Думайте. Обращайте внимание на смысл того, что делаете. Внимательно относитесь к расходам (даже тогда, когда получаете значительный доход). Концентрируйтесь на важных для вас вещах, не гонитесь за новыми технологиями. Когда проект будет работать, успеете всё переписать.
Национальная библиотека им. Н. Э. Баумана
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 также предоставляет некоторое программное обеспечение в качестве сервисной интеграции для добавления дополнительных функций в проекты. В данные услуги входят: