Git *

Вот и мне посчастливилось познакомиться с 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.

Что нового?

Хотите поднять клон 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.