По информации близких к руководству венчурного инвестиционного фонда Andreessen Horowitz источников сайта PandoDaily.com, GitHub
скоро начнёт первый раунд финансирования. Точная сумма и условия сделки пока неизвестны, но, по предварительным данным, компания на этом этапе будет оценена в 500 — 800 миллионов долларов. До сих пор Гитхаб развивался самостоятельно, не прибегая к помощи инвесторов. Сейчас в нём пятьдесят пять сотрудников.
На Гитхабе зарегистрировано 1.6 миллиона пользователей и 2.8 миллиона репозиториев. Платная подписка для индивидуальных пользователей стоит от 7$ в месяц, а цены на
Enterprise-версию, устанавливаемую внутри корпоративной сети, начинаются с 5000$ в год. Крупные компании тратят на услуги Гитхаба до миллиона долларов в год.
Официальных комментариев от компании GitHub пока не поступало.

Всегда хотели найти более простой способ для работы с git и github на своей windows машине? Боялись командной строки и генерации ssh ключей через putty? Хотите присоединиться к огромнейшему сообществу разработчиков в мире?
Сегодня github анонсировал свой
клиент для Windows, который можно использовать прямо из коробки.
Клиент написан на C#, работает на Windows XP, Vista, 7 и пре-релизе Windows 8. Прямо в установку включена инсталляция msysGit (git для win машин). Вливайтесь!
Вот и мне посчастливилось познакомиться с git. Каюсь, пользуясь Subversion, я знал, как в IDEA или TortoiseSVN сделать то, что мне надо, но даже не представлял, что происходит за сценой. В данном случае я решил подойти к git более ответственно и хорошенько изучить его перед использованием. Сейчас я знаю какие команды надо использовать для выполнения задуманного, но не знаю, как это сделать в IDEA или TortoiseSVN.
Но я решил пойти еще дальше и узнать, что происходит в самой директории .git. Там оказалось все настолько интересно и просто, что я решил поделиться этим с вами.
30 апреля 2012, 20:45
310

Мы переделали уже существующие графики и добавили три новых, чтобы помочь вам еще лучше изучать репозитории, размещенные на GitHub.
Привет, Хабросообщество!
Продолжая тему использования git хуков, хочу вам рассказать о post-merge и post-checkout
Что имеем
У нас есть веб приложение, которое мы разрабатываем. Нам нужно быстро и легко добавлять изменения на продакшн
Что предлагает нам Git
post-merge — Этот хук вызывается 'git-merge', после того, как мы выполнили 'git-pull' или 'git-merge' на локальном репозитории. Хук не выполнится, если у нас будут конфликты при мердже.
post-checkout — Этот хук вызывается 'git-checkout', после того, как мы выполним 'git-clone' или 'git-checkout'.
В разработке проекта зачастую принимают участие разработчики разного уровня. Это приводит к тому, что нет строгого формата написания кода. За качеством кода на проекте приходится постоянно следить старшим разработчикам и это отнимает у них кучу времени.
Для того чтобы
наказать говнокодеров облегчить страдания тех, кто делает ревью кода, можно использовать автоматические средства проверки кода, которые всем давно известны. Это PEAR и PHP Code Sniffer.
От переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.
Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.
Гуляя по github'у я много раз видел в разных репозиториях одновременно и теги вида «v2.3.4» и коммиты с сообщениями типа «Bump version» и сменой номеров версии где-нибудь в lib/version.rb. И всегда мне казалось — что-то тут лишнее.
И когда пришло время задуматься и мне над расставлением номеров версий, я сказал: «Нет! Я не буду прописывать эти номера в файлы руками. Пусть это делает за меня моя система контроля версий!»