Git *

Джошуа Редстоун (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, по этой теме есть множество хороших источников, которые я приведу в конце статьи.

1. Для чего эта статья?

Желание получить возможности Git на Windows платформе материализовало стремление повозиться с разными схемами настройки.

2. Осознание

Нужно осознать, что придется использовать программы Cygwin,SSH,GitExtenstions,Git,Gitolite

Cygwin — это программа, которая эмулирует окружение Linux.У нее есть свое черное окно, выглядящее и работающие как окно терминала Linux.
MsysGit — это программа для эмуляции git окружения, но без ssh сервера, поэтому мы не будем использовать на сервере репозитариев. Используем только для клиентов репозитария.
SSH — это программа для использования ssh подключений из ssh клиентов, доступная для всех операционных систем.
SSH сервер — это программа принимающая подключения от ssh клиентов.
Git — это набор программ, включая сам git, для работы с репозиториями файлов.
Gitolite — это программа, обертывающая git, и реализующая функции управления репозитариями: управление пользователями, их доступом и т.п.
GitExtensions — это программа для windows, обертывающая функционал как git, так прилагающегося набора программ в GUI, который также, встраивается в среду разработки Visual Studio 05/08/10.

В корпоративе придется выделить ресурсы для хостинга SSH службы, дисковое пространство для размещения репозитариев.
Человека, который будет обслуживать SSH сервер, доступ к репозиторию.
Научить пользователей использовать аналоги функций для взаимодействия с их старыми система контроля версий через GitExtensions.
Предложить им некоторые схемы работы, которые позволяет достичь Git.

UPD: 05.08.2011
UPD: 30.01.2012

Добро пожаловать в GitHub Reflog — хронику замечательных репозиториев GitHub и активности сообщества. Предыдущие выпуски доступны в Архиве Reflog, переводы выпусков в Архиве русскоязычной версии Reflog.

Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

Народ на Reddit жаловался, что мой технический язык слишком путанный, особенно потому что я придумывал новую терминологию в попытках доказательства своих положений. Они потребовали графы, с узлами, рёбрами, кружочками, стрелочками и всем прочим. Тогда я промучал графический редактор несколько часов и получил два графа, приведённые ниже, которыми я надеюсь обрисовать проблему.

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.

Если в один прекрасный момент вам ударило в голову желание насадить разумное, доброе, вечное, и пересадить всех с SVN на GIT, сразу встают три проблемы:

• Объяснить зачем это нужно разработчикам и руководству
• Ввести в обиход новую схему работы с кодом
• Научить ничего не подозревающих девелоперов новым техникам