Git *

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

По информации близких к руководству венчурного инвестиционного фонда 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. Там оказалось все настолько интересно и просто, что я решил поделиться этим с вами.

Мы переделали уже существующие графики и добавили три новых, чтобы помочь вам еще лучше изучать репозитории, размещенные на 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. И всегда мне казалось — что-то тут лишнее.

И когда пришло время задуматься и мне над расставлением номеров версий, я сказал: «Нет! Я не буду прописывать эти номера в файлы руками. Пусть это делает за меня моя система контроля версий!»

Спустя пол года после голосования о переходе на DVCS
и вслед за релизом PHP5.4, команда разработчиков PHP переехала с Subversion на Git.
Официальный анонс: www.php.net/archive/2012.php#id2012-03-20-1

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

В соответствии с календарем релизов осталось всего несколько недель до заморозки списка фич следующего релиза git (1.7.10), в который войдет улучшение работы git merge, нарушающее обратную совместимость и ставящее «под удар» тех, кто использует merge в своих скриптах.
Мы решили последовать совету Джейка Эджа (Jake Edge): «Большинство свободных проектов обсуждают планируемые изменения до их реализации и дают пользователям возможности протестировать новые фичи задолго до релиза. Лучшая помощь проекту на этом этапе — четко обоснованные, конкретные описания существующих проблем, отсутствующей функциональности и т.д., а не бесконечный поток сообщений „Project XYZ ОТСТОЙ!!!11“ в списках рассылки или комментариях»

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

Два с половиной месяца назад я написал о своем приложении.
За это время я позакрывыл пару десятков issue, добавлял функционал, выполнил и пофиксил пожелания пользователей Yeah, kekekeks.
В кратце, что добавилось:

• Для исходников и diff теперь плавающие скролы
• Для diff плавающие заголовки
• Бинарные файлы распознаются более качественно (ICU4J)
• Поддержка http для git
• Оповещения на почту (apache camel)
• Обновил доку
• Мелкие изменения в gui и багфиксы

А теперь о том, как мое приложение можно использовать. http я пилил не просто так…

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

Выбираем нужный бранч(ветку), у меня она master
git checkout master

делаем откат изменений в репозитории для примера на два коммита назад
git reset --hard HEAD~2

Можно сделать до какого то определенного коммита по хешу
git reset --hard HEAD hash
Хеш можно взять в вебинтерфейсе гитхаба.

Далее делаем принудительный коммит в основной репо на гитхабе
git push -f origin master
без -f будет ругаться что у вас версия младше чем в гитхабе и вам надо сделать pull

Джошуа Редстоун (Joshua Redstone) пожаловался в листе рассылки Git на некоторые проблемы с производительностью, которые возникли у Facebook на большом репозитории. Они создали синтетический репозиторий и провели тесты.

Тестовый репозиторий
4 млн коммитов, линейная история и около 1,3 млн файлов. Размер папки .git — около 15 ГБ, её упаковали командой repack:

git repack -a -d -f --max-pack-size=10g --depth=100 --window=250

Процесс занял около двух суток на хорошей машине (много памяти, SSD). Размер индексного файла составил 191 МБ.

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

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

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

Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect

Данная мини-заметка в первую очередь является ответом на вопрос. Так как мой аккаунт read-only, то вот такой вот способ ответа. «А жизнь-то налаживается!» ©

Первый вывод после прочтения вопроса и ответов — не делайте так, как предложил defuz. Он не понимает суть проблемы, и если вы сделаете как им предложено — скорее всего, вы потеряете данные.
Второй: alekciy тоже не совсем прав, но тут шансов на потерю данных гораздо меньше. Почти никаких.
Ну и третий: блин, ну когда же люди поймут, что владеть используемым инструментом это реально необходимо? Читайте документацию!

gitolite — это средство для создания централизованных репозиториев для совместной разработки через git.

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

Родные средства git для этой задачи на сегодня явно недостаточны: родной git-протокол не содержит каких-либо средств авторизации, а для работы через ssh потребуется завести полноценного юзера в ОС (с шеллом), что далеко не всегда уместно и желательно.
gitolite же позволит вам заводить пользователей независимо от наличия аккаунта в ОС и гибко раздавать права.

22 декабря мы зарелизили версию 2.0.

Основные изменения:

• Переезд с gitosis на gitolite.
• Пересмотрен дизайн. Теперь он более удобен и практичен.
• Улучшенное управление правами
• Улучшенная система email — нотификации.
• Улучшение dashboard.
• Улучшение работы дерева файлов и каталогов.
• Atom лента для комитов и тасков.
• Багофикс + другие мелкие изменения.

Около полутора лет назад мы анонсировали поддержку svn, которая позволила ограниченно использовать репозитории GitHub через клиенты subversion.

Сегодня мы запускаем новую улучшенную поддержку svn.

Что нового?