Git *

Вся соль 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.

Что нового?

Хотите поднять клон Github на своём собственном сервере с приватными репозиториями за корпоративным файрволом? Теперь вы можете это сделать благодаря появлению open source проекта GitLab. Он является хорошей альтернативой для корпоративной версии Github стоимостью до $5000 в год.

По сравнению с Gitorious, система GitLab отличается приятным интерфейсом и гораздо проще в установке.

13 октября вышла версия 1.0, через неделю обещают выкатить 1.1, а затем новые релизы GitLab 1.2, 1.3 и т.д. будут выходить каждый месяц.

Здравствуйте,

Тихо и незаметно (по крайней мере на Хабре) вышло обновления для git. Полный changelog. Кратко опишу главные вкусности, которым я очень рад и думаю вы тоже будете рады.

Привет, товарищ!

Как все знают, довольно большое распространение получает система контроля версий git.
И все бы хорошо, но многими любимый Gitosis не дружит с АД, а работа через http немного туповата.
Особенно, если настроен через WebDAV.

И тут я немного расскажу как подружить git с AD с последующим использованием через ssh.
К моему удивлению, в рунете (да и на просторах интернационального интернета) я подобных инструкций не видел.

Что у нас есть:
* Debian lenny
* git 1.7

Что нужно:
* openlikewise
* acl

И так. Быстрый HOWTO.

На новой панели Issues Dashboard можно просматривать все тикеты (issues) для всех ваших проектов.



Как и в Pull Request Dashboard, здесь консолидируются тикеты со всех проектов на одной компактной страничке. При помощи фильтров можно отобразить тикеты в ваших репозиториях, назначенные вам, созданные вами или за которыми вы следите.

Так что теперь не осталось оправданий оставлять открытые тикеты в ваших репозиториях. Наслаждайтесь!

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

Похоже, Git постепенно утверждается в качестве всеобщего стандарта для децентрализованных систем управления версиями. Всё больше известных проектов делают выбор в пользу Git. На днях за переход на Git проголосовали участники группы разработки PHP. Вот поимённые результаты голосования (спасибо за ссылку Irker).

По итогам двух недель обсуждения и голосования результаты оказались следующими:
52 высказались за переход на Git
15 за Mercurial
1 за Bazaar
13 за то, чтобы остаться на SVN

На Github с 2008 года существует зеркало исходников с SVN, хотя полноценно использовать Github никто не собирается, вся работа будет на git.php.net.

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

Я потратил несколько месяцев на борьбу с глюками Git-svn и обдумывание разных вариантов, прежде чем пришёл к этому методу организации рабочего процесса с сайтом — простому, гибкому и удобному в работе.

Основные преимущества:

• Делая push из удалённой копии мы автоматически обновляем live-копию сайта
• Правки файлов на сервере не будут разрушать историю коммитов
• Простота, не нужны особые правила выполнения коммитов
• Можно применить к уже запущенному сайту, без повторного деплоя или перемещения файлов

Только что стало изветно, что на любимом гитхабчиге можно прямо на месте открыть редактирование файла в ACE Editor (бывший Mozilla Bespin), отредактировать и закоммитить изменения. Лично мне этой фичи часто не хватает, когда надо сделать пулл-реквест на мелкий багфикс, а клонировать все сорцы лень. По этому случаю далее перевод официального анонса с инструкцией.

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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